AI can turn a coding task into minutes, then turn the saved time into more review, verification and coordination. That is not less work. It is a workload transfer.
Faster code can make the workday denser
The claim that AI makes every developer 10x faster is not a useful way to run a team. A task can be quicker to start while the team still spends more time checking its output, deciding what to merge, explaining it to others and recovering after interruptions. The calendar feels the whole system, not the first draft.
I separate measurements, correlations, my experience and the inference I draw from them. Blending those categories would make a clean story, but a false one.
Higher visible throughput can consume the slack that made work sustainable. If only closed tickets or merged pull requests count, the new capacity will fill quickly. That is a reading of the incentives, not the result of one study.
William Jevons noticed a version of this problem in 1865: when steam engines used coal more efficiently, coal use rose because the engines became more useful and more widely used. The analogy is not a law of engineering management, but it is a good warning. Efficiency does not automatically create rest. It can make demand expand.
My own observation is less dramatic but more useful: the calendar looks worse in 2026 than it did in 2024. Not because typing got harder, but because the day now contains more tiny decisions. The Jevons analogy explains a possible mechanism. It does not prove my experience is universal.
The evidence points to rework and review capacity
These sources studied different teams, tools and outcomes. Their figures do not add up to one verdict. They do indicate where to look for work displaced by cheaper code generation.
What the cited quality studies measured
- GitClear reported 5.7% code churn, up from 3.3%, in its analysis of 211 million lines of code. Churn means code that is quickly rewritten or deleted. The comparison is evidence of a changing codebase pattern, not proof that an assistant caused every edit.
- CodeRabbit reported 1.7x more issues in the AI-written pull requests it compared with human-written ones. Treat that as a result from its own sample and methodology, not a universal defect rate.
- Veracode reported that 45% of AI-generated code in its testing failed security checks. The useful team question is not whether the percentage transfers exactly to your repository; it is whether generated changes receive the same security review as any other change.
- LinearB reported an AI-generated PR acceptance rate of 32.7%, compared with 84.4% for manual PRs in its benchmark. A lower acceptance rate is a potential rework signal, not a measure of every team's code quality.
Review is where the queue can move
- Faros AI reported 91% longer PR review time in its analysis.
- The same source reported 154% larger average PRs. Larger changes do not automatically mean worse changes, but they demand more reader attention.
- LinearB reported that AI pull requests waited 4.6x longer before review began in its benchmark.
Taken together, these are correlations from separate sources, not a controlled experiment. Still, they describe a believable operational failure mode: generation speeds up, while review remains scarce. The bottleneck has not disappeared. It has moved to the people who must decide whether the change is safe, coherent and worth keeping.
The hidden work is cognitive, not just technical
Repository metrics do not tell you how the workday ends.
I can finish what feels like a light afternoon and then notice it is 7 PM and I have been going since 9. It did not feel like grinding. It felt like prompts, diffs, comments, small fixes and answers to questions. But I am fried. That is my experience, not a measurement.
One study measures a related effect in a narrower setting.
Zhang et al. studied 58 undergraduate design students with no formal programming experience during a two-day creative coding task. The AI-assisted group reported roughly 16% higher mental demand and 27% higher frustration on NASA-TLX. These are self-reports from novice learners, not evidence of the same effect in professional developers. Study and methods.
The workload may have changed shape: prompt, read, test, catch a subtle error, then switch between creating and reviewing. Each action looks too small to justify a break. Their sum does not.
Fragmented attention turns speed into a tax
The estimate predates today's assistants, and I am not claiming AI created interruptions. The practical pattern is familiar: a suggested refactor pulls you out of an implementation, a large pull request needs review, a teammate needs help validating an output, and notifications keep arriving. None is catastrophic on its own. Together they puncture the time required for difficult work.
Uplevel reported an association between 90 minutes of fragmented meetings and more than four hours of lost deep work. That finding is about meetings, not AI. The inference here is that teams should treat AI-related review and verification interruptions as a capacity cost too, rather than as free background activity.
In Stack Overflow's 2025 survey, 66% of respondents said AI solutions were "almost right", while 45% said debugging AI output took longer than writing the code themselves. Those are self-reports, not causal measurements. They still describe why verification needs real time on a delivery plan.
Teams can lose the feedback loop faster
There is a quieter risk behind the throughput numbers. A senior engineer walking a new teammate through an architecture does more than solve the immediate ticket. They explain why a boundary exists, which tradeoff failed before, and where the danger is. Faster first drafts can reduce those conversations if teams let them.
That creates a practical risk rather than a proven universal effect: juniors may finish a task without learning why the system is shaped that way. Teams can counter it by preserving design walkthroughs, asking for explanations during review, and treating an AI-assisted change as something its author must still be able to defend.
The Harvard/BCG "Jagged Frontier" study makes a related point more precisely. Participants were 25.1% faster and produced 40% higher-quality work on tasks within the AI's capability range. On tasks outside that range, they were 19 percentage points less likely to get the right answer than people without AI. That is not an argument against assistance. It is an argument for teaching people when to distrust it.
What the cited studies actually measured
1. Codebase and quality signals
| Metric | Source | Impact |
|---|---|---|
| Code churn: 5.7% | GitClear, Feb 2025 | Reported vs 3.3% comparison period |
| AI PRs: ~1.7x more issues | CodeRabbit, Dec 2025 | Reported comparison within its sample |
| 45% security failures | Veracode, Jul 2025 | Result from its AI-code security testing |
| Refactoring: 25% → 9.5% | GitClear, Feb 2025 | Reported codebase pattern to monitor |
2. Review-capacity signals
| Metric | Source | Impact |
|---|---|---|
| Review time: +91% | Faros AI, Jul 2025 | Reported review-time change |
| PR size: +154% | Faros AI, Jul 2025 | Reported average change size |
| AI PRs wait 4.6x longer | LinearB, 2026 | Reported time before review began |
| AI PR acceptance: 32.7% | LinearB, 2026 | Compared with 84.4% manual PRs |
3. Workload and attention signals
| Metric | Source | Impact |
|---|---|---|
| Mental demand: ≈+16% | Zhang et al., May 2025 | NASA-TLX; 58 design students, no formal programming experience |
| Frustration: ≈+27% | Zhang et al., May 2025 | Same novice sample; not a study of professional developers |
| Context recovery: 30–45 min | Duke University | Cited estimate; recovery varies by task |
| 90 min meetings = 4+ hrs lost | Uplevel, Apr 2025 | Association reported for fragmented meetings |
Measure the work that moved
This is not a reject-AI argument. I use it every day. The job is to stop treating the time saved at generation as proof that the whole system has more capacity. A team needs a view of the full loop: request, generation, review, verification, rework and recovery.
If you lead an engineering team: do not use PR count as the definition of productivity. Track review cycle time, change size, churn, escaped defects and the concentration of review work. Protect slack deliberately. If output rises while review capacity and attention do not, you have not created capacity. You have borrowed it from the people doing the verification.
If you are a developer: count prompting, checking and context switching as work. Protect breaks and ask for smaller, reviewable changes. "Almost right" output can consume more focus than a blank file, especially when it looks finished.
At organisation level, plan review capacity, set an acceptable verification effort and treat attention as a delivery constraint. Faster generation removes none of those decisions.
References
- GitClear. (2025, Feb). AI Copilot Code Quality: Evaluating 2024's Increased Defect Rate via Code Quality Metrics.
- Coderabbit. (2025, Dec 17). State of AI vs Human Code Generation Report.
- Veracode. (2025, Jul 30). 2025 GenAI Code Security Report.
- Faros AI. (2025, Jul 23). The AI Productivity Paradox Research Report.
- LinearB. (2026). 2026 Software Engineering Benchmarks Report.
- Zhang, H., et al. (2025, May 25). The Neurophysiological Paradox of AI-Induced Frustration. PMC.
- Shah, M. (2025, Sep 30). AI vs Time Tools: 5 Ways to Cut Developer Context Switching. AugmentCode.
- Uplevel. (2025, Apr 28). How to Reduce Developer Interruptions (+ Increase Deep Work).
- Stack Overflow. (2025). 2025 Developer Survey: AI tools, accuracy and developer frustrations.
- Dell'Acqua, F., et al. (2023). Navigating the Jagged Technological Frontier: Field Experimental Evidence of the Effects of AI on Knowledge Worker Productivity and Quality. Harvard Business School and BCG.