The TLDR: faster coding only shortens a project when coding is what's holding it up. Once work is delivered faster than people can review, test, accept, or make decisions about it, the waiting starts setting the schedule. More output can leave the same people with more work waiting for their attention. Ask how long work waits at each stage and who can move it forward. A report showing more code written or more tasks completed won't tell you whether usable software is reaching your users any sooner.
What the measurements say
The numbers help explain why this happens, provided we keep a realistic view of what they measure. Faros AI's research, based on telemetry from more than 10,000 developers across 1,255 teams, found that developers on teams with high AI adoption merged 98% more pull requests, the proposed code changes submitted for review. Review time increased 91%. Faros found no corresponding improvement in company-level delivery metrics. Those are an engineering analytics company's observational findings, rather than proof that AI caused the outcomes.
LinearB's 2026 benchmark covers 8.1 million pull requests across more than 4,800 development teams. It puts the wait before review for agentic changes at 17.6 hours, compared with 3.4 hours for unassisted changes, at the 75th percentile. DORA's 2025 research also found higher AI adoption associated with both greater delivery throughput and greater delivery instability.
And, passing tests doesn't settle the question of whether code is ready. In METR's March 2026 study, maintainers would have declined roughly half of the test-passing SWE-bench Verified changes from the agents studied, after adjustment for noise in human review decisions. The agents didn't get to revise their work in response to feedback, so this shouldn't be read as a rejection rate for every AI-assisted team.
These are different measurements, but they give us good reasons to look beyond coding speed. DORA's guidance on making work visible recommends measuring the full flow from idea to customer and warns against putting effort into stages that aren't the bottleneck. For your team, the useful question is where work is waiting and what it needs to move forward. More coding speed only helps if that waiting is for code.
Where do the weeks go?
Think about what happens after a piece of work passes its automated tests and evals. Someone still has to read the PR with enough context to judge whether it belongs in the system. On a small development team, that might be the same senior engineer who now has a queue of things to review twice as long. Then the work needs a test environment and someone who can try it and say whether it does the job.
And, sometimes trying it raises a question the code can't answer. "Should returns after 30 days, waived by override, still carry the restocking fee?" The person testing the change may know the process without having authority to change the rule. So the question goes to someone else, who has a day job and a calendar full of things that were urgent way before your software project arrived.
And there goes yet another week.
Those processes usually exist for a reason. Approval chains protect decisions that matter, your people have other responsibilities, and a senior engineer can only review so much code with real attention. When coding took longer, some of the waiting could happen while the build was still underway. Faster builds with higher volume output make that waiting harder to hide.
Try this on one of your current projects. Count the unanswered questions more than a week old, then count how many need a decision rather than more code. You might find that the weekly status reports have been telling you plenty about completed tasks and very little about the decision backlog keeping downstream work from finishing.
Planning for the whole team
A plan that talks about story points and sprints should also explain how work gets through post-coding stages. Agree on these practices as a team:
- Time measured by stage. How long does work spend in build, review, testing, business acceptance, and decisions? A promise to deliver in 6 weeks needs to account for where those weeks go. The breakdown gives you somewhere to act when the schedule starts slipping.
- Small increments. A change a reviewer can understand in one sitting is easier to assess than a bundle of unrelated work. Smaller deliveries also give your team a manageable amount to try and accept, instead of a large handoff competing with everything else on their desks.
- An agreed definition of done. Write down the expected behavior before building it, including checks the team can run. Automated evaluations can settle the repeatable questions; business acceptance still needs someone who can judge whether the result meets the need.
- Clear decision ownership. Name the people who can settle questions/disagreements about requirements, business rules, and access, and give them time to do it. Different questions may need different owners. A name without authority or room on the calendar won't help much when the work is waiting.
The trade-off is fairly plain. Smaller changes and earlier acceptance work require up-front discipline, but they can reduce the time spent untangling a large chunk of work later. More coding capacity helps when the build is the constraint. When review or acceptance is holding up delivery, adding more finished work just gives already stretched people an even longer queue.
What belongs in the weekly status
Ask for 3 numbers and a list.
- Time to first review. How long does a review-ready change wait before someone picks it up? This helps show whether the team's review capacity is keeping pace with what it produces.
- Age of the oldest open decision. How long has the oldest unanswered question been waiting? Name the decision owner and make clear what they need to answer it.
- The acceptance backlog. How much reviewed work is ready to try but hasn't been accepted yet?
- Blocked work and its owners. What can't move forward, what does it need, and who can provide it? Include decisions, access requests, and approvals alongside technical blockers.
"Shouldn't faster coding let us do more with the same team?"
It can, if the rest of the work can keep up. Review, testing, and business decisions all need time and attention. The person who can judge a code change may not be the person who can approve a pricing rule, grant access to the ERP, or decide whether an exception in claims still belongs in the process. Bring those people into the delivery plan and make their responsibilities visible. Otherwise the team gets more code to process with the same unanswered questions.
FAQ
Does this mean AI isn't actually helping? It can help with the work it touches. The project gets shorter when that saved time affects the path to delivery. If completed work spends the saved time waiting for review or a decision, your release date may barely move.
Should we expect project costs to fall? Possibly, but coding is only part of the cost. The team still spends time defining the work, reviewing it, testing it, and correcting mistakes. AI tools have a cost too. Track the cost of delivered, accepted work alongside the time it takes to reach users. That gives you a better view of the savings than counting how much code the team can produce.
What's a reasonable review turnaround? Prompt enough that the work doesn't sit until everyone has to reconstruct its context. The useful target depends on the project and the consequence of the change. Measure the current wait before agreeing on a turnaround; a promised number won't create review capacity by itself.
What can we do this month? Name the decision owners and protect a recurring hour each week for project questions. Bring the measures above into the team's weekly review. Count the old unanswered questions today, then use that list to decide which waiting you can shorten first.
More on how we approach software delivery at Made In Tandem is on our how we work page.