Your Best Engineer Got Faster With AI. Your Delivery Didn't.

If building is half of the time it takes to get a change in front of a customer, the most AI coding can ever do for your delivery speed is double it. Even code that writes itself can’t beat that.

It’s why a founder can hear two things at once: their engineers say AI has made them several times faster, and the roadmap doesn’t look any different. Both can be true. The arithmetic is simple enough to do in your head, and once you’ve done it for your own team, it tells you where the next pound should go.

The arithmetic

A change goes through stages before a customer sees it. Someone decides it’s worth doing and writes it up well enough to build, an engineer builds it, someone reviews and tests it, it gets released, and eventually someone checks whether it did what it was meant to. Lead time is the sum of all of them.

Here’s an example, made up to keep the sums easy rather than measured from any one team. A change takes 10 days end to end: 2 deciding, 5 building, 2 reviewing, half a day releasing and half a day finding out whether it worked.

Now make building 10 times faster. Those 5 days become half a day, and nothing else moves, so the change takes 5.5 days. The team is about 1.8x faster. It’s a real gain, but it’s a long way short of 10x.

Push it further and building takes no time at all. The change still takes 5 days, because deciding, reviewing, releasing and checking didn’t get any quicker. So 2x is the ceiling for this team, however good the tools get. This is Amdahl’s law, which computer scientists have used since the 1960s to explain why speeding up one part of a system only helps as much as that part’s share of the total.

With building at 10x, halving review, from 2 days to 1, takes the change to 4.5 days, which is about 2.2x. That’s better than the 2x you’d get if the code wrote itself. Once building stops being the longest stage, the next gain is in whichever stage is now the longest, and it isn’t in faster coding.

Where the extra speed goes

In practice it’s worse than the arithmetic, because faster building doesn’t leave the other stages alone. It sends them more work.

Faros AI, which sells engineering analytics, looked at telemetry from over 10,000 developers in its 2025 report. Developers on teams using AI heavily merged 98% more pull requests, and those pull requests were 154% larger. Review time on the same teams went up 91%. It found no improvement at company level that held up. It’s a vendor’s data and it’s observational, so I’d treat it as a pattern rather than a forecast, but the pattern matches what I’ve seen on teams.

Review is usually where it lands, because review is done by people, and often by the same few senior people. Every extra pull request is something one of them has to read. If review was already the longest stage, AI has made the queue longer. So the change waits.

That changes what the next spend should be. Say you’re weighing another engineer at around £90,000 a year all in, or another round of AI tools. If review is your longest stage, either one produces more code for the same reviewers to read. The same money spent on review capacity, smaller pull requests, or a review tool that takes the first pass off your seniors goes to the stage that’s actually holding work up.

Find your own ceiling

The 10-day example is mine, not yours. Your stages will have different lengths, and the answer changes with them, so I built a free calculator that does the sums for your team: the AI Throughput Gap calculator.

You enter how many working days each stage takes and how much faster AI makes each one. It opens with building at 3x rather than 10x, because it shouldn’t start from the most generous claim anyone has made. It gives you three things back: how much faster your team actually ships, the ceiling if code wrote itself, and the stage that now decides when work ships. Nothing you enter is stored, and it runs in your browser.

Then read the result:

• If building is still your longest stage, faster coding still pays. Spend on it, and check again once it isn’t the longest.
• If building is tied for longest, halving the other stage or doubling the AI speed-up gets you the same gain. After that, faster coding stops paying.
• If another stage is longest, that’s where the next gain is. Halving it beats doubling the AI speed-up on building every time, and the calculator shows you both numbers side by side.

Get the stage times from your tracker

Most founders don’t know how long each stage takes, and that’s fine. Start with estimates, because a rough answer still tells you which stage to look at. But it’s worth replacing the estimates with real numbers before you spend against them, and the obvious places to get them are easy to get wrong:

• Measure review from ready-for-review, not from when the pull request opened. Draft time inflates open-to-merge, and it makes review look slower than it is.
• Don’t take building time from git. Teams that squash or rebase reset commit dates, so take it from the tracker’s in-progress timestamp instead.
• Check your tracker keeps status history. Jira and Linear record when a card moved. Notion doesn’t, so switch on a status-change log now, because that history can’t be rebuilt later.
• Look at teams, never individuals, and take the 75th percentile and the count as well as the median. The slow quarter of changes is often where the stage you’re looking for shows up.

And don’t ask people how much faster they feel. In the best-known trial, developers believed AI had made them 20% faster while being measured 19% slower, so the feeling is the least reliable number you’ve got.

If you’d rather have the stage times measured than estimated, the Engineering Deep Dive includes an analysis of your delivery telemetry, which is where these numbers come from. Or book a call and we can look at your stages together.