This is the second article in the AI Contradictions series and follows the opening argument on ownership: once AI makes code cheaper to produce, the next constraint is whether anyone still has the capacity to judge it properly. It shifts the focus from who owns the change to whether qualified reviews can keep pace with it.
| Audience: | CIO đźž„ CTO / VP Engineering đźž„Director of Engineering/Head of Platform Engineering |
| Primary Sectors: | Cross Sector |
| Decision Horizon: | Before the next AI coding license expansion, agent-permission increase, or delivery commitment tied to AI productivity. |
Executive Summary
AI coding can make individual changes faster to produce. It does not make them faster to understand, challenge, test in context, or approve for production.
Decision Posture: Do not scale agentic coding by seat count, generated pull requests, or claims of developer speed. Expand it only where the team can prove that qualified review capacity, independent verification, and rollback readiness remain ahead of AI-generated change demand. Where that proof does not exist, restrict AI use to bounded, readily testable work rather than broad, cross-system change.
The bottleneck has moved. The scarce resource is no longer keystrokes. It is experienced technical judgment with enough time to be useful.
Our Analysis
The market narrative says better agents will progressively remove development friction by generating the code, writing the tests, fixing the errors, and letting engineers focus on higher-value work. That is directionally plausible. It is also incomplete.
The Narrative vs The Reality
AI coding tools are improving quickly, and teams are increasingly willing to delegate larger units of work. Some agents can now generate implementations, tests, explanations, and proposed fixes in one workflow.1 The does not make operational reality any easier:
- Generated change volume can rise faster than review capacity. At Coinbase, automation lower in the engineering stack was creating renewed pressure higher up, as mid-level staff struggled to review the growing volume of changes.1
- A passing implementation is not necessarily production-ready. Agents could often create functionally correct code that still could not be used as-is because of testing, formatting, or broader code-quality problems.2
- Review quality depends on participation and expertise, not merely approval completion. Empirical research on large software systems found that low review participation, absent subject-matter expertise, and insufficient review discussion were associated with higher post-release defect counts.3
- Automated review can help, but it does not make contextual judgment disappear. A 2025 industry field study found benefits in AI-assisted summaries and review support, while also identifying false positives, trust problems, insufficient context, and the continued importance of reviewer familiarity with the codebase and the severity of the change.4
- The useful role for AI review is workload reduction, not self-certification. An ICSE 2026 evaluation at Atlassian found that a context-aware, quality-checked review tool could shorten pull-request cycles and reduce human-written comments. That result supports AI as a screening and triage layer; it does not establish that generated code and generated review evidence should certify one another.5
Meanwhile, the teams most visibly “accelerated” by AI may simply be borrowing more senior attention from architecture, reliability, security, and production support.
The Signal in the Noise
AI does not eliminate the software-delivery bottleneck; it moves it into the finite pool of people who can independently judge whether a change is safe to ship. The organizations that scale code generation before they measure review saturation will not move faster, they will simply hide more risk inside the release queue.
What Changes the Decision
Treat AI coding licenses as a demand shock to the review system.
A developer seat increases output capacity. An agentic coding workflow can increase the number, breadth, and ambiguity of changes awaiting technical interpretation. Those are not equivalent. The relevant scale question is whether the organization can absorb the added verification demand without converting experienced reviewers into a permanent release queue. The answer cannot be inferred from code volume, closed pull requests, or automated-test pass rates.
Why This Matters Now
Agentic workflows increasingly combine implementation, test generation, self-correction, and pull-request preparation.1 That can remove mechanical work, but it can also create a closed assurance loop when the same model chain produces the code, the explanation, the tests, and the review commentary.4,5
The immediate decision is cross-sector: can the team sustain independent technical review as generated-change demand rises? That question becomes more urgent as agents receive broader repository access, take on multi-file changes, and prepare work for production with less direct human intervention.1
Sector changes the default review lane, not the underlying argument. In regulated, clinical, citizen-service, or operational-technology environments, changes affecting identity, consequential decisions, sensitive data, continuity, or safety should enter the restricted lane by default. Low-blast-radius internal tooling can scale faster where automated testing and rollback are genuinely strong.
What to Watch for Next
Watch for self-directed multi-file changes, automated pull-request creation, and claims that agents can validate or repair their own work. Treat those capabilities as a reason to test review capacity more rigorously, not as evidence that independent review has become optional.6
Recommended Actions
Do This
- Make review saturation a scale-funding gate. Before approving additional agent permissions, enterprise licenses, or AI-linked delivery targets, require a monthly Review Capacity Ledger from the VP Engineering. The ledger should show AI-assisted material changes awaiting review, qualified reviewer availability, P90 time to first independent review, reviewer concentration, high-risk changes reviewed by a relevant subject-matter expert, and post-merge rework or rollback signals. Pause further expansion when two or more indicators worsen against the team’s trailing two-release-cycle baseline. This is a management threshold, not an industry benchmark.
- Classify reviewability before generation begins. The service owner and engineering lead should place work into one of three lanes at intake: scale-eligible, restricted, or exception-only. Isolated boilerplate, bounded refactoring, and internal tooling with reliable tests and straightforward rollback may scale. Cross-service workflow changes, identity and access changes, regulated decision logic, patient-impacting functions, payment flows, and operational-technology interfaces should be restricted unless a named domain reviewer accepts the change before work begins.
- Separate mechanical checks from independent evidence. Allow AI to summarize pull requests, identify likely defects, generate test candidates, and reduce reviewer search time. But where the same model workflow generates implementation, tests, explanations, and review comments, none of those outputs should count as independent production assurance. For material changes, require an affected-service view, independently run validation evidence, a named human reviewer, and a rollback path. The service owner, not the tool owner, accepts the residual risk.
Avoid This
- Using AI adoption or pull-request counts as a proxy for delivery capacity. More generated changes can mean more work arriving at the least scalable part of the engineering system.
- Imposing identical review rules on every AI-assisted change. Blanket four-eyes review for low-risk boilerplate wastes the scarce attention required for cross-service, high-consequence work. The point is not more reviews. It is more discriminating reviews.
- Reducing experienced engineering capacity before the Review Capacity Ledger has held steady through at least two release cycles. Savings assumed from faster generation are fictional until review demand, corrective work, and release reliability show otherwise.
Bottom Line
AI can accelerate the creation of software changes, but it cannot yet make contextual technical judgment abundant. Scale AI coding only where review capacity is demonstrably ahead of generated demand. Otherwise, the organization has not removed a bottleneck; it has hidden one inside the release process.
Evidence and Sources
- Edd Gent, “AI Coding Is Now Everywhere. But Not Everyone Is Convinced,” MIT Technology Review, December 15, 2025; Will Douglas Heaven, “Anthropic’s Code with Claude Showed Off Coding’s Future—Whether You Like It or Not,” MIT Technology Review, May 21, 2026.
- Beth Barnes et al., “Research Update: Algorithmic vs. Holistic Evaluation,” METR, August 12, 2025; Joel Becker et al., “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity,” METR, July 10, 2025.
- Shane McIntosh, Yasutaka Kamei, Bram Adams, and Ahmed E. Hassan, “An Empirical Study of the Impact of Modern Code Review Practices on Software Quality,” Empirical Software Engineering 21, no. 5 (2016): 2146–2189.
- Fannar Steinn Aðalsteinsson et al., “Rethinking Code Review Workflows with LLM Assistance: An Empirical Study,” arXiv, 2025.
- Kla Tantithamthavorn et al., “RovoDev Code Reviewer: A Large-Scale Online Evaluation of LLM-Based Code Review Automation at Atlassian,” Proceedings of the 48th International Conference on Software Engineering, Software Engineering in Practice Track, 2026.
- Hayley Booth et al., “Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile,” NIST Special Publication 800-218A, July 2024.