# The code review crisis and how you should rebuild review models > Source: > Published: 2026-08-11 09:00:00+00:00 “We’re generating more code than ever. My senior engineers are drowning in review,” a VP of engineering at a mid-sized software company told me. I hear this from engineering leaders almost every week. AI was supposed to fix delivery, but it just moved the bottleneck. If you feel the same way, you’re neither wrong nor alone: in [CloudBees’ 2026 State of Code Abundance report,](https://www.cloudbees.com/blog/2026-state-of-code-abundance-report) 81% of enterprise technology leaders reported a rise in production issues tied to AI-generated code, while 92% said they were confident the code was production-ready before it shipped. That gap between confidence and production reality is the warning. We spent two years putting AI assistants in front of every developer and almost none rebuilding the workflow behind them. When a company is dropping GitHub Copilot or Cursor into the existing lifecycle and waiting for speed, have no doubts they are treating AI as a productivity patch. And it won’t last long. Before AI coding tools, companies struggled to get enough good code. But today they create more code than ever before. [GitHub’s Octoverse 2025](https://octoverse.github.com/) reported 43.2 million pull requests merged per month, up 23% year over year. Today, the bottleneck is deciding what code should be merged or redesigned, and what risk is slipping into production. You [improve delivery throughput, but degrade delivery stability](https://dora.dev/research/2025/) through AI adoption. Since AI-authored changes are larger, touching more files per diff, each review decision carries more uncertainty and, therefore, more risk. Simply speaking, you ship faster and also break more. The review quality drops when senior engineers skim 400-line diffs, focusing on style. They lose focus on the vital security and correctness questions. Treat AI as a coding patch, and your best engineers end up spending Fridays reviewing diffs instead of designing systems. You can’t afford not to rebuild the underlying operating model. The trust developers are ready to give AI has dropped from 40% a year earlier to 29%, according to [Stack Overflow’s 2025 Developer Survey.](https://stackoverflow.blog/2025/12/29/developers-remain-willing-but-reluctant-to-use-ai-the-2025-developer-survey-results-are-here/) 66% of them describe AI output as “almost right, but not quite.” In review terms, “almost right” means dangerous. For example, take a pull request for a discount feature. From a technical perspective, the pull request builds a discount endpoint, validates the input, returns clean JSON and passes the unit tests the AI agent wrote for it. But the logic applies the discount before the eligibility check, not after, reversing the rule in the ticket. In other words, the system gives discounts to customers who should not receive them. Why would that happen? Companies are used to relying on a single reviewer, human or AI, to answer every question, even when those questions carry different levels of risk. But code review is no longer a single job, and mixing all review questions in a single task creates noise and more “almost right” output. The answer is in splitting the review job. You need a single connected review process with clear roles. One coordinator agent finds every open pull request linked to a ticket and pulls the right context for review. Two AI review checks run inside the same process. The first agent checks requirements, running once across all related pull requests, reading the ticket’s solution notes and acceptance criteria. It asks only one question: did we build what was asked? The second checks quality, running on each pull request in parallel and looking for critical issues, including security, error handling, architecture and missing or stale tests. It uses best-practice rules for that specific service type before the review runs. Their findings merge into one consolidated comment on the ticket, sorted into “requirements” and “quality.” A human reviewer can see instantly whether the issue is about scope or code quality. Human engineers do not leave the loop. They still define what “critical” means for a given stack, tune the rules when the same violation keeps recurring and, importantly, own the merge decision on any high-blast-radius change. They decide what to ship when a mistake could cause severe damage. The agent needs something concrete to check against. Before an AI agent reviews anything, it needs an explanation of the type of service it is looking at and a precise request in the ticket. You will need a catalog that maps each repo to its service type and architect-written solution notes for each ticket, including contracts, schema details and also scope limits. In early pilots, review agents flagged old problems in untouched code. While some comments were technically right, they were useless. When you scope every finding to the lines that the change actually touched, you could avoid such behavior. The more autonomy you give AI, the more boundaries you have to set. “AI review” can mean different levels of AI responsibility, and the governance question changes at each step. Yet, on any high-blast-radius path, that last step stays human — full stop. Don’t give AI more freedom just because the pilot looks good on a slide. Give it more freedom only when the results prove it’s safe and useful. In the pilots I’ve run, agent findings start with an acceptance rate around 35-40% and climb past 60% as context improves. Even that early number matters. It means the agent is catching real issues instead of parroting the linter. But acceptance rate alone isn’t enough to justify expanding scope. I only expand scope when acceptance rate is climbing and the post-merge defect rate is holding flat or falling. One signal moving without the other is a red flag. I keep telling technology leaders to let AI handle routine checks and keep senior engineers focused on the risky merge decisions, unless they are ready to pay it back in incidents. In an AI-native environment, senior engineers become verification strategists. But you should expect resistance. Teams don’t trust AI enough, and they also resist changing their review habits. Once teams break free from the gravity of old habits, senior engineers start getting genuine capacity back and spend it on architecture and risk instead of line-by-line code review. The same pattern—stop doing the repetitive verification and start designing it—repeats itself in QA. Teams move from re-running obvious checks to validation design, deciding what must run in a sandbox, what stays human-only and what evidence belongs in the audit trail. Sometimes AI review takes root fast, sometimes harder. Small teams adopt it quickly on greenfield work with a modern stack and fast feedback. Unlike the brownfield work, where you face legacy services, complex frontends and years of tribal knowledge. There, one incident is enough to convince the team that AI review won’t work. You should always start by piloting a real feature and see which AI findings engineers accept and which defects appear after the merge. You will use the findings later to add meaningful guardrails and extend AI-assisted review to more services. Companies should split the review job before [CloudBees’ 81%](https://www.cloudbees.com/blog/2026-state-of-code-abundance-report) becomes a number on the quarterly slide. Without that change, they will be impressively good at shipping code they never fully check.