Skip to content
· Ronny Schueritz

Code Review Doesn't Scale with AI

When AI generates code faster than humans can review it, the bottleneck isn't generation. It's approval.

AI Enterprise Governance Code Review
Code Review Doesn't Scale with AI — generation accelerates while the review queue becomes the constraint

Every engineering team has the same ritual. Developer writes code. Reviewer reads it. Comments go back and forth. Code ships. The cycle takes hours or days, depending on the team, the backlog, and whether the reviewer had coffee.

Now add AI. A model generates 500 lines in seconds. The reviewer still takes the same hours. Except now there are ten pull requests instead of one, and the reviewer is reading code they didn’t write, don’t fully understand, and can’t verify by reading alone.

This is measurable. Faros AI analyzed telemetry from more than 10,000 developers across 1,255 teams. Teams with high AI adoption completed 21% more tasks and merged 98% more pull requests. In the same dataset, PR review time rose 91% and average PR size grew 154%. Organizational delivery metrics — deployment frequency, lead time, change failure rate — stayed flat.1

Individual output nearly doubled. Nothing reached users faster.

The bottleneck in AI-assisted development isn’t generation. It’s approval.

Why the review model breaks

Traditional code review rests on an assumption: the reviewer can understand the author’s intent by reading the code. That assumption holds when the author is a human developer who follows team conventions, names variables meaningfully, and structures changes around a single concern.

AI doesn’t do this. It produces working code without architectural awareness. It introduces packages the team hasn’t vetted. It reimplements logic that already exists elsewhere in the codebase. It drifts. One enterprise engineering team we interviewed described exactly this: they want AI assistance within small, well-defined contexts while keeping explicit architectural control, tests, and traceability. What they get is unconstrained output that requires more review effort than writing the code manually.

The most revealing data on this comes from Apiiro, which ran deep code analysis across tens of thousands of repositories at Fortune 50 enterprises between December 2024 and June 2025. In AI-assisted commits, syntax errors fell 76% and logic bugs fell 60%. Over the same period, privilege escalation paths rose 322% and architectural design flaws rose 153%.2

Read those two trend lines together. The defect classes that automated tooling is built to catch got better. The defect classes that automated tooling cannot catch got dramatically worse.

What tooling catches versus what AI actually breaks: syntax errors down 76% and logic bugs down 60%, while privilege escalation paths rose 322% and architectural design flaws rose 153%

That asymmetry is the whole problem. Linters catch syntax issues. They don’t catch intent drift. Static analysis finds known vulnerability patterns — and MITRE’s own guidance states plainly that automated static analysis tools have difficulty detecting custom authorization schemes, rating automated detection for that weakness class as limited. No scanner verifies that the AI chose the right abstraction, respected the module boundary, or preserved the data flow contract. The tools enterprises rely on for governance were built for human-authored code with predictable patterns. AI-generated code breaks those assumptions.

Nor is the residual risk small. Veracode tested 100+ LLMs across 80 coding tasks in 2025: 45% of generated samples failed security tests against OWASP Top 10 categories, with Java at a 72% failure rate.3 CodeRabbit’s analysis of 470 real-world pull requests found AI-coauthored PRs carried 10.83 issues apiece against 6.45 for human-only ones — 75% more logic and correctness errors, and roughly triple the readability and maintainability problems.4

The models produce valid syntax. They don’t produce governed output. The gap between “it compiles” and “it’s safe to deploy” is where enterprises get stuck.

The review tax

Consider what a thorough review of AI-generated code requires: verify the logic matches the business requirement, check for regressions against existing behavior, validate dependency choices, confirm authorization rules are respected, ensure audit logging is present, test edge cases the model may not have considered.

For a 500-line pull request, that’s 30–60 minutes of focused work. For ten AI-generated PRs per day, it’s a full-time job. And it scales linearly. Double the AI output, double the review burden.

It is also getting worse, not better. Faros’s follow-up telemetry across 22,000 developers found median time in PR review up 441%, bugs per developer up 54%, and incidents per PR up 243%.5 A year of better models and better tooling did not relieve the review queue. It deepened it.

Teams facing this have two options within the current model: slow down to maintain governance, or skip reviews to maintain velocity. Neither outcome works.

Review intent, not syntax

There’s a structural alternative: don’t review code. Review intent.

Instead of asking a reviewer to verify 500 lines of generated JavaScript, reduce the change to a three-line declarative modification. “Add a column to this table. Bind it to this data field. Restrict edit access to the manager role.” The reviewer sees what changed at the business level, not at the syntax level.

Schema validation handles the rest. A declarative framework with enforced governance rules rejects invalid changes at write time. Field naming conventions, component dependencies, access control constraints, data flow policies — all validated automatically before the change reaches a reviewer. The human reviews intent. The machine validates compliance.

This is the principle behind Blueprint-based architectures. Measured against our own production stack, the change surface per feature shrinks by 3–5x. The governance rules are structural: not applied after the fact, but enforced by the data model. An AI agent building within this framework cannot produce an ungoverned output. Not because a linter catches it later. Because the architecture rejects it at the point of creation.

Note what this does to the Apiiro asymmetry. Privilege escalation paths and architectural design flaws are hard for scanners precisely because they depend on knowing the application’s own rules. In a declarative architecture, those rules aren’t tribal knowledge a scanner has to infer. They’re part of the definition the system validates against.

What production taught us

Running governed enterprise applications at scale reveals a consistent pattern: opinionated constraints beat flexible code. Field-naming rules prevent the majority of component-level bugs. Inheritance patterns reduce copy-paste duplication across screens. Schema validation catches errors that would survive weeks in a code-based system.

One deployment of the B1 Developer Framework serves 1,300+ users across 1,000+ screens managing 25 million documents. Governance isn’t an add-on. It’s the architecture. Every mutation is logged. Every change traces to its author. Every Blueprint modification passes schema validation before it persists.

The result: AI agents that build within the system produce governed output by default. Not because someone remembered to run the audit. Because the system won’t accept unaudited changes.

The shift

The AI governance conversation today centers on reviewing AI output: better linters, smarter static analysis, mandatory human review. All of these scale linearly with AI output volume. None of them solve the structural problem — and the Apiiro data suggests the sharpest risks are migrating into exactly the category those tools cannot see.

The alternative: constrain the input surface instead of auditing the output. Give AI a bounded, schema-validated representation to work within. Let governance rules enforce compliance at write time. Review intent, not syntax.

The teams doing this ship faster without sacrificing governance. The teams reviewing AI-generated code line by line are falling behind. Not because they lack discipline. Because they’re applying a human-era process to a machine-era problem.

Footnotes

  1. Faros AI, “The AI Productivity Paradox,” July 2025. Telemetry from 10,000+ developers across 1,255 teams: +21% tasks completed, +98% pull requests merged, +91% PR review time, +154% PR size, +9% bugs per developer, with organizational DORA metrics flat. faros.ai ↩

  2. Apiiro, “AI Code Assistants and Security Risk,” 2025. Deep Code Analysis across tens of thousands of repositories at Fortune 50 enterprises, December 2024 to June 2025: syntax errors −76%, logic bugs −60%, privilege escalation paths +322%, architectural design flaws +153%, with monthly security findings rising roughly tenfold. MITRE’s CWE-862 guidance rates automated detection of custom authorization schemes as limited. apiiro.com ↩

  3. Veracode, “2025 GenAI Code Security Report.” 100+ LLMs tested across 80 coding tasks in Java, Python, C#, and JavaScript. 45% of samples failed security tests against OWASP Top 10 categories; Java failed at 72%. Failure rate did not improve with model size. veracode.com ↩

  4. CodeRabbit, “State of AI vs Human Code Generation,” December 2025. Analysis of 470 real-world GitHub pull requests: AI-coauthored PRs averaged 10.83 issues versus 6.45 for human-only PRs, with 75% more logic and correctness errors and roughly 3x more readability and maintainability issues. ↩

  5. Faros AI, 2026 telemetry across 22,000 developers: median time in PR review +441%, bugs per developer +54%, incidents per PR +243%. faros.ai ↩