AI writes more code. Teams don't finish more work.
New 2026 data shows AI coding agents raise pull requests far faster than finished work. Why review is the new bottleneck and what to change in Sprint Planning.
More code is not more done
AI coding agents are now part of most software teams. The promise was simple: write code faster, ship more. The data from 2026 tells a more complicated story.
What the numbers say
A Harvard working paper by Fiona Chen and James Stratton, updated on November 7, 2026, looked at more than 720,000 engineers across 655 firms. Teams that adopted AI coding agents opened 35.7% more pull requests. The number of issues actually resolved rose only 13.7%, and that result was only borderline statistically significant.
An earlier version of the study also found that 14% more people were pulled into code review, which puts heavy pressure on senior engineers.
Atlassian sees the same gap in its own research: AI use among engineers grew by 65%, while developer velocity gains stayed at around 10%. Atlassian points to bottlenecks outside code generation, such as planning, review and maintenance.
The bottleneck has moved
When writing code gets cheaper, the slow part of the system moves somewhere else. For most teams it moved to:
- Code review. Every AI-generated pull request still needs a person to read it, understand it and approve it.
- Testing and QA. More changes mean more to verify.
- Rework. Code that matches the prompt but misses what the user really needed comes back as bugs or redesign.
Speeding up one step without fixing the next one doesn't increase delivery. It just moves the pile of work.
Why velocity alone is now misleading
If you compare velocity before and after AI, you may see a rise and call it a win. But velocity counts what the team says is done, and it doesn't show:
- how many hours went into reviewing AI code,
- how much work came back as bugs or rework,
- whether one or two senior engineers are carrying all the review load.
A sprint can look faster on the chart while the team feels slower and more tired.
Four changes for your next Sprint Planning
1. Reserve capacity for review. Treat code review as real work in the plan, not something that happens in the gaps. If AI doubles the number of pull requests, review time grows too.
2. Measure finished work, not activity. Track items that reached Done and stayed done. Lines of code, commits and pull requests measure activity, not delivered value.
3. Spread the review load. Check who reviews what. If the same two people approve most pull requests, they are the real limit of your sprint.
4. Track rework and bug fixing. Measure how much of each sprint goes to bugs and redoing work compared with new work. If that share grows after adopting AI, the gain is smaller than it looks.
Your turn
Has review time grown on your team since you started using AI tools? Who carries most of it? Tell us what you're seeing.
Where LazyScrum fits
LazyScrum helps you plan around the real bottleneck. With LazyScrum, you can see and follow all the activity from one place. Plan with real capacity that leaves room for review, see each person's load on a 30-minute timeline, and use the end of sprint and measure reports to see how much time went to bug fixing and rework versus new work. LazyScrum runs live Sprint Planning on top of Jira, with Estimation, and team members join planning free.
LazyScrum offers a 7-day free trial. Try it here.
Sources: Harvard study coverage, Beri.net · Forkast · Atlassian announcement
