Agents write code faster than any team can read it. Review, not generation, is now the constraint.
By The Chiri Team
Who on your team actually reads the code your AI agents write, and how much of it do they honestly understand?
Ask that question honestly and the answer tends to get vague fast. Not because engineering leaders are careless. Because the volume of code being produced has outrun the number of human hours available to review it, and that gap is only going to widen from here.
Writing code was never really the bottleneck. Reviewing it was always the constraint, we just did not notice because humans wrote slowly enough that review kept pace. That is no longer true:
- 98 percent more pull requests from teams using AI coding agents.
- 91 percent increase in review time.
- AI-generated PRs sit waiting for a reviewer 4.6 times longer than human-written ones (Faros AI, 2026).
The bottleneck did not disappear. It relocated, from writing to verifying, and verifying does not parallelize the way writing does.
The volume problem is also a trust problem
This would be a manageable staffing problem if the code coming out the other end were reliably safe. It is not. AppSec Santa’s own 2026 testing of 522 AI-generated code samples found a 25.7 percent confirmed vulnerability rate, in line with the 25 to 40 percent range other researchers, including AppSec Santa and Snyk, have separately reported. CodeRabbit’s research puts AI-generated code at 1.88 times more likely to introduce a vulnerability than human-written code. (AppSec Santa, “AI Security Statistics 2026”)
Put those two facts together and you get the actual crisis. More code, reviewed less carefully, with a meaningfully higher baseline defect rate than the code it is replacing. Microservices architecture was invented in the first place to let humans compartmentalize a system small enough to hold in their heads. That compartmentalization strategy does not survive a codebase that grows faster than any individual, or any team, can build a mental model of.
Why the fix cannot be “review harder”
The instinct is to add process. More reviewers, stricter gates, mandatory second approvals. That buys time. It does not solve the underlying math, because it still assumes a human is the final check on correctness, and the volume of agent-generated code is growing faster than the supply of qualified human reviewers ever will.
The more durable answer being developed right now is formal verification: instead of asking a human to read an implementation and judge whether it is correct, you specify what the software must do in a formal language, the AI agent generates both the implementation and a machine-checkable proof that it satisfies the specification, and the proof itself is what gets verified, not the code. Recent work on agentic verification frameworks like AxDafny shows AI agents producing verified implementations through iterative, verifier-guided repair, where the verifier gives a much richer signal than a fixed test suite ever could, flagging exactly where a program violates its spec or where an edge case is unhandled. (arXiv, “Harnessing Code Agents for Automatic Software Verification,” 2026; AxDafny)
This is still early, contested territory. There are competing approaches and open questions about which formal methods will actually scale to production systems rather than research benchmarks. What is not contested is the direction: the industry needs a way to validate code that does not require a human to personally read and understand every line, because that constraint is already broken today and getting more broken every quarter.
What this means before the tooling is fully mature
You do not have to wait for a formal verification stack to be production-ready to start reducing your exposure. Teams pulling ahead in 2026 are the ones investing in review infrastructure now:
- Automated first-pass security and correctness gates.
- Risk-based triage, so human attention goes to the changes that actually warrant it.
- Explicit review SLAs.
- Disciplined PR sizing, so no single review is a black box.
None of that is glamorous. All of it buys you time while the harder problem, verifying code at the speed it is now written, gets solved properly.
In a year, a meaningful share of the code running your business will be code no one on your team personally read line by line. That is true whether or not you have a plan for it, which is exactly why it is worth an answer now rather than after an incident forces one.
This is not only an engineering question:
- The CEO owns the exposure if unreviewed code causes an outage or a breach that reaches customers or the press.
- The CFO owns the cost of the incident itself, plus a cyber insurance underwriting process that increasingly probes security practices in detail before binding a policy.
- The COO owns the operational disruption when something ships broken and nobody can say why fast enough.
- The CTO owns the actual answer to the question below, and needs one that holds up under pressure, not just in a slide.
What percentage of the code shipping to production at your company today was actually read, start to finish, by a human before it merged?
Sources cited:
- Codex Knowledge Base, “The Human Review Bottleneck: Practical Code Review Strategies for Agent Output,” May 2026. https://codex.danielvaughan.com/2026/05/24/human-review-bottleneck-code-review-strategies-agent-output/
- AppSec Santa, “AI Security Statistics 2026: 70+ Key Facts & Data,” including AppSec Santa’s own 522-sample testing, Snyk, and CodeRabbit research. https://appsecsanta.com/research/ai-security-statistics
- arXiv, “Harnessing Code Agents for Automatic Software Verification,” 2026. https://arxiv.org/pdf/2607.06341
- arXiv, “AxDafny: Agentic Verified Code Generation in Dafny,” 2026. https://arxiv.org/pdf/2606.32007