Does AI make custom software cheaper and faster? What to expect when you are paying for it

Does AI make custom software cheaper?#

AI makes writing code faster, but writing is 30 to 40% of software engineers' time in Chen and Stratton's November 2026 paper, so the fall in hours is a fraction of what the speed-up suggests. Fiona Chen and James Stratton of Harvard University studied 720,542 workers at 655 firms. Their data comes from clients of the analytics firm Jellyfish who agreed to take part. Their November 2026 paper estimates the share two ways. About 41% comes from work records in that data, and about 31% from a survey of 100 software engineers. The paper's chart labels both as before AI tools. The rest goes to review and to management, meaning meetings and planning.

Since theirs is a working paper, treat its estimates as strong evidence and not as settled fact. Also, earlier versions, still quoted online, had smaller figures, and we use the 1 November version. However, it measures firms and their software teams, not client invoices. So applying it to your quote is our inference, and we say so where it happens.

The useful question is not whether a team uses AI. Instead, ask how many hours fell, at which stage, and who kept them.

How much lower should your quote be?#

As a worked example, if writing code is 40% of the hours and gets 73.7% more productive, about 17.0% of the hours go, on our arithmetic, with all else held still. That 73.7% is Fiona Chen and James Stratton's November 2026 estimate, from a model fitted to their data. It says how far agents raise coding productivity on top of AI assistants. An agent is an AI tool that writes and changes code by itself. An assistant suggests code as a person types.

Take an illustrative 1,000-hour quote. At a 40% share, writing code is 400 hours, and at the higher productivity those hours shrink to about 230. So about 170 hours go and 600 stay as they were. But that assumes every other hour holds still and the team writes the same amount of code. The firms in this paper did not do that.

Which baseline applies depends on what you compare. If your firm already used AI code assistants, the step to agents gives 12.7 to 17.0% on our sum from Chen and Stratton's November 2026 paper. Measured from before any AI tools, the paper's combined factor of 2.34 gives 17.2 to 22.9%. The share was measured before AI tools, so it is an approximation for a team already using them.

This is a rough estimate and not a limit. At a 40% share, our arithmetic on the standard error, the measure of uncertainty in Chen and Stratton's November 2026 paper, gives the step to agents alone a 95% range of about 10% to 22%. Also, the estimate averages across firms with uneven take-up, so a team that fully uses agents can exceed it.

Each assumption can push the figure either way. More code written or more review lowers the fall, while help with tests and documents or fuller take-up raises it. Also, your own share may differ in either direction. For example, design and project management on the quote lower it, while a quote that leaves out internal meetings and planning raises it. So ask for the split.

On mature code the gain can be small or even negative, so measure a small pilot before using this sum. In a 2025 trial by the research group METR, described in the legacy guide, tasks took experienced developers 19% longer with AI. METR's February 2026 update points the other way: tasks took an estimated 18% less time for returning developers (confidence interval 38% less to 9% more) and 4% less for new recruits (15% less to 9% more). METR calls that later data "an unreliable signal", mainly because developers unwilling to work without AI left the study, which likely understates the speed-up. The calculator starts at no gain, so it does not cover a negative one.

The review default, about 1.3% of all hours, is our arithmetic too: Chen and Stratton's 7.0% fall in review productivity, an imprecise figure, applied to their 17.7% review share, with the same amount of code. If the team writes more code, review grows much faster. The firms in Chen and Stratton's paper moved about 23% of coding labour and added 43.4% to review labour. Their model holds total labour fixed over that period, so the hours moved rather than fell, with more output. For example, a factor of 2.34 means a speed-up of 134%, so enter 134 to compare from before AI tools.

GoodFirms is a ratings site for software firms. In its late 2025 survey of over 100 firms, 61% believe AI will trim costs by 10 to 25%. However, that survey asks about costs, not hours. Still, on our same-code sum 10% is well within reach and 25% is at or beyond the top of the range.

A firm quoting a larger cut may be right. So treat it as a reason to ask which stages paid for it, not as evidence that it is false. A note on our position: we sell this kind of work, so a smaller expected discount suits us. That is why the sum is here for you to run yourself.

Why does more code not mean more finished work?#

Twelve months after adoption, Chen and Stratton estimate agents added 36.0% more commits, while issues resolved rose 13.7%, an imprecise figure, in their November 2026 paper. A commit is one saved change to the code. In Fiona Chen and James Stratton's data, an issue is a tracked piece of work, counted once the code reaches production. So it is the closest measure of finished work.

In Chen and Stratton's November 2026 paper, the 44.0% on lines of code, the 13.7% on issues and the 18.0% on epics all fall just short of statistical significance. Their firmer results are commits and pull requests. Their summary is blunt: "Code review becomes the bottleneck."

As a result, code volume is a poor thing to buy. A weekly report that counts lines written or changes opened says little about what you can use. So ask for progress as features accepted against a test you agreed in advance.

Should your delivery date move?#

Move it less than the demo suggests: an NBER paper revised in September 2026 estimates AI coding tools, up to autonomous agents, lifted commits 240% and releases 30%. NBER is the National Bureau of Economic Research. The September 2026 paper by Mert Demirer, Leon Musolff and Liyuan Yang follows more than 500,000 developers, on public open-source projects. A release is a version that people can use, which makes it the step nearest to your date.

Also, the authors say effects in company software are considerably smaller, so the step to your delivery date is our inference. These are counts of activity, not durations. So they suggest the direction and not the size of any change to your date. Therefore an earlier date is fair to ask for, and a proportionally earlier date is not.

In particular, Demirer and colleagues put most of that shrinkage from commits to releases down to experimentation, meaning code that is written and then discarded. For the phases a schedule passes through and where it tends to slip, see the timeline guide.

Which part of the schedule did not speed up?#

Review did not speed up: Chen and Stratton estimate time from submission to approval rose 56.1% after agents, and they name review as the bottleneck. In their November 2026 paper, among changes that drew a comment, code waited 59.9% longer in the backlog and spent 58.5% longer in active review. Comments on each code change rose 38.6%. Chen and Stratton read that as consistent with a fall in the quality of what was submitted.

So you wait on a queue as well as pay for the work: in Chen and Stratton's November 2026 data, about two more days per code change. Those are days on the calendar, not hours on an invoice. So they show up first in your date and not your bill.

Meanwhile, DX, which sells developer measurement tools, reports the same pressure in an October 2026 summary of its report on more than 500 companies: firms with the most AI code waited 82 minutes for a first review against 40 at the lowest reported tier, a comparison between firms and not proof of cause. DX says this has not yet slowed overall delivery, with its own output measure up 75.5% over four quarters.

For your own review hours, the agentic delivery guide has a calculator. That guide's worked example uses a different May 2026 study with larger rises, which would more than use up the saving above. So put your own figures in.

Did software firms lower their rates?#

Mostly not by early 2026: Techreviewer's survey of 127 software firms has 4.72% lowering rates, 48% holding them and 41.7% raising them slightly. In Techreviewer's March 2026 report, that 4.72% is 6 firms. But Techreviewer's sample leans small, with 70% of respondents at firms of up to 100 people. And these are firms describing themselves.

However, other firms read the market differently. Accelerance, which sells outsourcing, wrote in November 2025 that rates fell in 2025 by 7.1% in Latin America, nearly 8% in Asia and 4.4% in Europe. That comes from its survey of 60 partners. It credits competition and automation together, so AI cannot claim the whole fall. The same article quotes its chief executive saying "Rates are stable."

In addition, a rate says nothing about hours. Since the saving lives in the hours, our view is that a lower rate is the wrong signal to wait for. Instead, a firm can hold its rate and bill you fewer hours, and that is the outcome to ask for.

What did not get cheaper?#

Checking still costs people's time: 44.1% of companies in Techreviewer's August 2026 survey say AI increased their code review work, and about 90% report some downside. Those answers come from 127 companies in Techreviewer's network, surveyed in July 2026. Techreviewer ranks software firms, and it warns these answers come mostly from senior leaders and marketing staff, not developers. Also, the margin in that July 2026 survey is about 9 points.

Fiona Chen and James Stratton's November 2026 model shows where the hours may go. It has firms moving people from writing to review, with coding labour down 22.7% and review labour up 43.4%. Meanwhile, firms' total employment shows no detectable change. In short, on that model the hours mostly moved. However, the paper cannot observe the split directly, and its employment estimate is noisy.

What does a prototype built in days actually prove?#

A prototype built in days proves the idea can be shown and wanted; it does not prove the software survives real data, real permissions or real load. That line is our judgment. In Chen and Stratton's November 2026 paper, writing code is 30 to 40% of software engineers' time. In our judgment a fast prototype is mostly writing, though that share was not measured on prototypes. So much of the work is likely still ahead of you.

So use a prototype for what it settles: whether people want this and whether the flow makes sense. Settling that early is a real gain.

Before anyone quotes the rest, list what it leaves open:

• What happens with your messy real records instead of tidy sample data?
• Who may see and change what, and is that enforced?
• Does it hold up with your real number of people using it at once?
• How does it connect to the systems you already run?
• Who can change it safely a year from now?

Also decide early whether the prototype is a sketch or a foundation. A sketch can be thrown away, so its code quality does not matter. A foundation needs the same review as everything else.

What does unreviewed AI code leave you to pay for later?#

It can leave code that is harder to change: He and colleagues measured a lasting rise in warnings and complexity after open-source projects adopted an AI agent. Hao He and colleagues' paper, published at the 2026 Mining Software Repositories conference, puts warnings from automatic code checkers up 30.3% and code complexity up 41.6%. The speed gain faded while that rise did not, and they link the rise to slower work later. Other methods in the same 2026 paper gave smaller rises or none. All read open-source projects using one tool, so hold the size loosely.

But the paper does not separate reviewed code from unreviewed code, so the step to your bill is our inference. In practice, the firm is paid when the build ends, while you pay for every later change. If the code got harder to change, part of the saving moved out of the build and into your future bills.

For the checks that catch this, see how to trust AI-generated code. And if the code you already own is old, the legacy guide deals with that case.

What should change in how you scope and contract the work?#

Write down what finished means, who reviews the code and who keeps any saved hours, because AI makes extra scope cheap to start and costly to own. In GoodFirms's survey of over 100 firms, run in late 2025, 65.6% said scope creep, work growing past what was agreed, typically adds 10 to 25% to project cost.

These are our suggestions, and the exact wording belongs to your lawyer:

Then ask how the firm itself works with these tools. The vendor guide has the questions to ask about its use of AI.

When is pressing for an AI discount the wrong fit?#

Pressing for a discount is the wrong fit when a defect costs more than the hours saved, as in regulated work, payments or old systems with few tests. This is our judgment. Hao He and colleagues' 2026 paper shows quality costs can outlast the speed gain, but it does not study regulated work or payments. In those cases, you get more by paying for checking than by asking for fewer hours.

• Regulated work. A failed audit can cost more than the writing hours. So keep the hours, and ask for a named reviewer and a record of who approved what.
• Payments. One wrong calculation can repeat across every transaction. So put any saving into tests around the money paths.
• Old systems with few tests. When a change breaks something, you may not see it until later. So pay for tests around current behaviour first, and talk about speed afterwards.

When the software is a short-lived internal tool or a throwaway test of an idea, heavy process is the wrong spend. There, a fast and cheap build is right.

Where should you take this next?#

Take the sum you worked out to your next quote, and ask the firm to show the hours behind it stage by stage. To put a first budget on the work, start with the cost guide.

Saving

is the rough fall in total hours, with every other hour and the amount of code held still, on our arithmetic.

Share

is the part of the hours spent writing code, about 30 to 40% in Fiona Chen and James Stratton's 1 November 2026 paper.

(1 - 1/speed-up)

is the part of the writing hours that go, with the 73.7% gain added to 1 to make the speed-up.

To see how we work, read about building custom software. If you want AI features in your own product, that is a separate service. The questions below say how we use AI in delivery. But you do not need us to do any of this. The sum and the questions above work with any firm you choose.