An AI agent can produce a patch while a developer is still thinking through the request. That is an impressive change in the speed of writing code. Whether it changes the speed of shipping useful software is a harder question.
AI coding productivity should be measured at the point where work becomes usable, not only where text appears in a repository. Otherwise a team can look dramatically busier while its customers wait just as long.
What the research found
Fiona Chen and James Stratton's working paper, Artificial Intelligence in the Firm: Bottlenecks in Software Production, examines software work across 718 firms. Its August 2026 version estimates that AI agents increased lines of code by 30%, commits by 20% and pull requests by 23%.
Effects on issue and epic resolution were positive but not statistically significant. Review time rose by 49%. These findings concern the paper's historical sample and methodology; they are not proof that every current tool or team will have the same experience.
The contrast is useful because the paper examines several stages of production. A gain at one stage can be absorbed by a constraint elsewhere. That is a more informative discussion than simply calling AI coding either a miracle or a failure.
The reviewer inherits the extra output
Imagine a small team where three developers prepare changes and one senior engineer reviews them. If preparation becomes faster but review capacity stays fixed, the queue can grow. The team has accelerated a part of the process without necessarily accelerating the whole process.
This is an illustrative example, not a result measured in the study. It shows why more generated code can create additional checking, explanation and coordination work. Someone still has to determine whether the change solves the intended problem and preserves existing behaviour.
The obvious management error would be rewarding the larger queue as a productivity success. That encourages more submissions while making the actual delivery constraint harder to see.
Better measurements for an AI coding pilot
Start with work your team already recognises as valuable. Define the acceptance conditions before the tool writes anything. Then track the time and cost from request to an accepted, functioning change.
| Measurement | Question it helps answer |
|---|---|
| Time to accepted change | Did the complete task finish sooner? |
| Review and repair time | Where did the saved effort move? |
| Regressions after release | Did speed create later work? |
| Completed user-facing tasks | Did customers receive more useful improvements? |
| Tool spending per accepted task | Was the improvement worth the cost? |
Use comparable task types when assessing results. A documentation fix and a complex migration should not be treated as interchangeable simply because both create pull requests. Record enough context to explain unusually easy or difficult weeks.
Make smaller changes, not bigger claims
A practical response is to ask agents for bounded changes with explicit acceptance criteria. A reviewer can assess a focused patch more easily than a sprawling rewrite justified by a vague instruction to improve everything.
Require the author to explain the change and show how it was checked. Decide who owns follow-up repairs before delegating more work. If review is already the bottleneck, increasing automatic submissions may be a worse experiment than improving the review process first.
The paper does not establish that AI cannot improve software delivery. It challenges a shortcut in the sales story: more code does not automatically mean more finished software. Teams should make vendors and managers defend the outcome that matters to customers.
