AI Writes Code in Minutes. Why Reviews Still Take Hours.

The biggest bottleneck in software development isn't writing code anymore. It's figuring out whether the code that was generated actually works.

A few years ago, software teams worried about development velocity. Features took time to build. Engineers spent days implementing requirements, wiring up APIs, writing tests, and debugging edge cases before opening a pull request.
Today, generative AI can produce pull requests in seconds, generating code, issues, and security reports at unprecedented scale.

Yet many engineering teams are discovering an uncomfortable truth:

The time required to write code has collapsed. The time required to trust that code has not.

In fact, for many organizations, AI hasn't eliminated the bottleneck. It has simply moved it.

The New Reality: Code Is Cheap

For decades, writing code was the expensive part of software development.

If a feature required 1,000 lines of code, an engineer might spend days designing and implementing it. By the time that pull request was submitted, the author typically understood:

• Why the code existed
• How it worked
• Which tradeoffs were made
• Which edge cases had been considered
• What was still risky

The effort invested in creating the code also created understanding.

AI changes that equation.

Today, an engineer can describe a feature in a few prompts and receive a substantial implementation almost immediately. Functionality that previously required days of effort can now appear in a pull request before lunch.

At first glance, this looks like a massive productivity win.

But there's a catch.

 The Review Bottleneck  

Code generation is accelerating much faster than code review.[3] As reviewers, we're now seeing:

• More pull requests
• Larger pull requests
• More generated boilerplate
• More unfamiliar implementation patterns
• More code that "looks right" at first glance

The result is that reviewing has become harder than coding.

That pressure is already visible. GitHub reports that monthly merged pull requests grew from about 25 million in January 2023 to more than 90 million by June 2026. Maintainers from projects such as Homebrew and AutoGPT say AI has accelerated that volume and made their review queues harder to manage.

More output doesn't automatically create more confidence. Stack Overflow's 2025 Developer Survey found broad use of AI tools alongside low trust and frustration with answers that are nearly correct but still require verification.

A developer can generate 2,000 lines of code in an hour.

No reviewer can thoroughly validate 2,000 lines of business-critical code in an hour.

Not if they want to maintain quality.

Not if they want to catch defects.

And certainly not if they want to understand the architectural implications.

Before AI

Developer writes code

Developer tests code

Developer submits PR

Reviewer validates implementation

After AI

Developer prompts AI

AI generates implementation

Developer performs quick validation

Developer submits PR

Reviewer becomes architect, tester, debugger, and validator

The burden shifts.

And often, it shifts to the reviewer.

The Dangerous Part: AI Code Often Looks Correct

This is where things get interesting.

Bad code written by a human is often obviously bad.

Bad code generated by AI can be polished, well-formatted, documented, and confidently wrong.

That's a much harder problem, and the risk isn't hypothetical. In one recent study of AI-generated automation scripts, every script sampled from ChatGPT, Microsoft Copilot, and Google Gemini contained potentially exploitable vulnerabilities. Nine of the 17 vulnerability classes appeared in outputs from all three tools.

We've all encountered examples:

• Logic that fails on important edge cases
• Error handling that appears complete but misses critical scenarios
• Security implementations that are technically functional but unsafe
• Database queries that work correctly but perform terribly at scale
• Cloud architectures that ignore operational realities

The code compiles.

The tests may even pass.

Yet the implementation is still flawed.

The reviewer must work significantly harder because they're evaluating code that looks trustworthy even when it isn't.

Why "AI Reviewing AI" Isn't a Silver Bullet 

When this problem comes up, the obvious response is:

"Let's have AI review the AI-generated code."

There is certainly value in AI-assisted code reviews.

AI is very good at identifying:

• Style inconsistencies
• Missing null checks
• Basic security concerns
• Duplicate code
• Common programming mistakes
• Did we correctly interpret the requirement?
• Does this solution fit our architecture?
• What business rules are being violated?
• What happens when systems interact in unexpected ways?
• Is this maintainable six months from now?

These capabilities are useful, but they don't add up to a complete review. GitHub found that Copilot produced fewer useful review comments when it explored a codebase broadly instead of examining the specific changes in a pull request. After GitHub taught it to follow a more focused review process, average review costs fell by roughly 20% without reducing review quality.

Even then, these tools aren't answering the hardest questions in software review.

The hardest questions are often:

These questions require context.

They require experience.

They require understanding why the software exists in the first place.

An AI reviewer might flag a missing exception handler.

A senior engineer might realize the entire workflow is solving the wrong problem.

Those are very different levels of review.

When "It Works" Isn't Enough

This problem becomes even more pronounced in cloud environments. I've seen AI-generated code and infrastructure definitions that:

• Create overly permissive access controls
• Expose services unnecessarily
• Ignore identity-based security patterns
• Introduce excessive operational complexity
• Miss cost optimization opportunities
• Security risks
• Reliability issues
• Compliance concerns
• Unexpected costs

The implementation often works.

But "works" is not the same thing as "production ready."

In cloud engineering, small mistakes can become:

A reviewer isn't simply checking syntax.

They're validating architecture.

That remains a deeply human responsibility.

When No One Owns the Code 

The real risk is reduced accountability.

Historically, writing code required enough effort that engineers naturally developed a strong understanding of what they were submitting.

AI can dramatically reduce that effort.

That's wonderful when used responsibly.

But it becomes dangerous when developers stop treating generated code as their own. Code may be cheap to generate, but a change is only truly cheap when a human can confidently review and own the result.

Every engineer should still be able to answer:

• Why does this code exist?
• How does it work?
• What assumptions were made?
• What are the known limitations?

If the person opening the pull request cannot answer those questions, the reviewer is forced into a role they were never meant to fill.

What High-Performing Teams Will Do Differently 

The solution isn't to stop using AI.

Instead, teams need to adapt.

Successful organizations will:

• Prefer small, self-contained pull requests. DORA identifies small batches as a predictor of software delivery performance and warns that large AI-generated changes are difficult to review, test, and integrate safely.
• Run relevant automated tests before human review and include tests that demonstrate intended behavior and meaningful edge cases. AI can help generate those tests, but a human should confirm they are correct, sensible, useful, and valid before relying on the results.
• Keep authors responsible for understanding, validating, and explaining all submitted code, including code generated by AI.
• Use AI-assisted review to supplement human judgment, not replace it. GitHub warns that Copilot may miss problems or make mistakes and says its feedback should always be validated alongside human review.
• Seek feedback on requirements and design before implementation becomes expensive to change. Google's engineering guidance calls overall design the most important part of code review.
• Automate routine formatting and style checks, then focus human review on design, correctness, security, tests, and business behavior.

Most importantly, successful organizations will recognize that generating code and understanding code are not the same skill.

Code Is Abundant. Trust Is Not. 

The AI coding revolution is real.

AI can help engineers build faster than ever before.

But software development was never just about producing code. It was always about producing correct code that solves the right problem.

AI has made code abundant.

Trust is still scarce.

And as long as trust remains scarce, code review will remain one of the most valuable engineering activities in the software development lifecycle.
The next generation of great engineers will be the ones who combine AI's speed with genuine mastery: people who can define the architecture, articulate the requirements, and understand every line of code deeply enough to own it completely.

How is your organization navigating this shift? If the review bottleneck is slowing your team down, we'd love to help. Reach out to us at Spyglass MTG and let's talk about how to build a development process that keeps pace with AI without sacrificing quality or accountability.
.