AI Can Write Code Faster Than We Can Review It — And That’s Becoming the Real Bottleneck

For most of software development history, writing code was expensive.

A developer might spend hours implementing a feature, fixing edge cases, writing tests, and preparing a pull request.

AI coding agents changed that equation.

Today, tools such as Claude Code, GitHub Copilot, Cursor, Codex, and other coding agents can generate surprisingly large changes in minutes.

That sounds like an enormous productivity improvement.

And it is.

But it creates another problem:

What happens when we can generate code faster than we can understand, review, and verify it?

I think this is becoming one of the biggest bottlenecks in AI-assisted software development.

---

Writing Code Is Getting Cheap

Imagine a developer receives this task:

Add role-based access control to the admin dashboard.

Without AI, the process might look like:

Understand requirements
        ↓
Explore codebase
        ↓
Design solution
        ↓
Write code
        ↓
Write tests
        ↓
Debug
        ↓
Open pull request

That might take hours or days.

A modern coding agent can compress parts of that workflow dramatically.

You can give it the task and potentially receive:

• database changes
• middleware
• API updates
• UI changes
• tests
• documentation

within a relatively short time.

Great.

But now imagine the agent changes 27 files and generates 1,800 lines of code.

The coding took minutes.

The review might still take an hour.

And that creates a strange new equation:

Code Generation
      ↓
    FAST

Code Verification
      ↓
    SLOW

We removed one bottleneck and created another.

---

GitHub Is Already Responding to This

This isn't only a theoretical problem.

GitHub has been expanding Copilot Code Review so AI can participate more deeply in the review process.

Recent updates allow Copilot Code Review to use additional tools for analysis, including running builds, tests, and targeted checks.

GitHub has also experimented with an ensemble of specialized agents during code review.

In its reported experiments, GitHub said the approach increased the rate at which developers addressed high-severity review comments by 47%.

That tells us something interesting.

AI isn't only being asked to:

Write the code.

It's increasingly being asked to:

Review the code written by AI.

And that creates a much bigger question.

---

What Happens When AI Writes the Code and AI Reviews It?

Imagine this workflow:

Human describes feature
        ↓
AI writes implementation
        ↓
AI writes tests
        ↓
AI reviews implementation
        ↓
AI suggests fixes
        ↓
AI fixes its own issues
        ↓
Human clicks Approve

At first glance, this looks incredibly efficient.

But there's a danger.

The human developer can slowly become the least informed person in the workflow.

You might approve a pull request containing code you didn't write, tests you didn't design, and a review generated by another AI system.

Everything may be green.

That doesn't necessarily mean everything is correct.

---

Passing Tests Doesn't Mean the Feature Is Right

Suppose the requirement is:

Only account owners can permanently delete a workspace.

The AI generates:

DELETE /workspace/:id

It writes a test.

The test passes.

The AI reviewer checks the implementation.

No problems found.

But perhaps the real business rule was:

Owner       → Delete
Admin       → Cannot Delete
Member      → Cannot Delete
Suspended   → Cannot Delete

If the original requirement was misunderstood, the implementation and tests can agree with each other while still being wrong.

This is an important distinction:

AI can verify that code matches its interpretation without proving that its interpretation matches reality.

That is where human judgment still matters enormously.

---

Welcome to AI Technical Debt

Traditional technical debt often comes from developers knowingly taking shortcuts.

AI introduces another possibility:

Code that works today but that nobody on the team properly understands.

Imagine a codebase after one year of aggressive agent usage.

Feature A → AI generated

Feature B → AI generated

Refactor → AI generated

Migration → AI generated

Tests → AI generated

Documentation → AI generated

Now production breaks.

Who understands the system deeply enough to debug the interaction between those pieces?

This is why the conversation around AI technical debt is becoming important.

Sonar describes it as the rework and risk created when AI-generated code arrives faster than teams can properly verify, understand, and maintain it.

Generating more code is not automatically increasing productivity.

Sometimes you're simply generating future work faster.

---

The Metric We Should Care About Is Changing

Developers have traditionally measured productivity through things like:

• tickets completed
• pull requests merged
• features shipped
• lines changed
• deployment frequency

AI can dramatically increase many of those numbers.

But imagine this team:

Before AI

10 PRs/week
2 bugs
Developers understand changes

Now:

With AI

35 PRs/week
11 bugs
Nobody understands half the changes

Did productivity really improve?

Probably not.

Maybe we need a better metric:

How much verified, maintainable value did we ship?

That's much harder to measure than lines of code.

But it is much closer to what actually matters.

---

Code Review Has to Change

Traditional review often focuses on lines:

- old code
+ new code

That becomes increasingly difficult when agents can generate huge changes quickly.

Instead of only asking:

"Is this line correct?"

I think developers increasingly need to review at several levels.

---

Level 1: Requirement

Before reviewing code, ask:

What problem are we solving?

If the agent misunderstood the requirement, everything after that may be technically correct and still useless.

---

Level 2: Architecture

Ask:

Is this the right way to solve it?

AI may generate a perfectly functioning implementation that introduces unnecessary:

• dependencies
• abstractions
• database tables
• background jobs
• services
• complexity

Working code isn't necessarily good architecture.

---

Level 3: Blast Radius

Ask:

What can this change break?

Pay special attention to:

• authentication
• authorization
• payments
• migrations
• production data
• caching
• concurrency
• infrastructure

A 20-line authentication change may deserve more attention than 500 lines of UI code.

---

Level 4: Failure Modes

Ask:

What happens when this fails?

What happens when:

• the API times out?
• the database is unavailable?
• two requests happen simultaneously?
• the user refreshes?
• payment succeeds but the webhook fails?
• the AI API returns garbage?
• an unauthorized user calls the endpoint directly?

AI is often very good at the happy path.

Production systems live in the unhappy paths too.

---

Level 5: Maintainability

Finally ask:

Could another developer understand this six months from now?

A clever AI-generated abstraction may save 20 lines today and cost hours of debugging later.

Simple code still has enormous value.

---

The Human Developer Is Moving Up a Layer

I don't think this means developers become less important.

I think the responsibility is shifting.

The old workflow was often:

Understand
   ↓
Design
   ↓
Write
   ↓
Test
   ↓
Review

The emerging workflow may become:

Define
   ↓
Constrain
   ↓
Delegate
   ↓
Verify
   ↓
Review Decisions
   ↓
Approve

AI handles more implementation.

Humans become increasingly responsible for:

Requirements

Architecture

Security boundaries

Business rules

Failure modes

Trade-offs

Final accountability

Those are much harder problems than writing another CRUD endpoint.

---

What I Do When Reviewing AI-Generated Code

I've started thinking about AI code review differently.

Instead of immediately reading every line, I first ask five questions.

1. What changed?

Get the high-level picture before reading implementation details.

2. Why did it change?

Every file should have a reason to exist in the diff.

3. What assumptions did the AI make?

This is where many bugs hide.

4. What happens when something fails?

Look beyond the happy path.

5. Could I maintain this without the AI?

If the answer is no, I probably shouldn't merge it yet.

Then I inspect the code.

This makes reviewing large AI-generated changes much easier.

---

AI Reviewing AI Isn't Necessarily Bad

There is an important point here.

Using AI to review AI-generated code isn't automatically dangerous.

It can actually be extremely useful.

One agent might generate the implementation.

Another can search for:

• security vulnerabilities
• missing tests
• race conditions
• performance issues
• broken edge cases

Automated tools can then run:

• static analysis
• type checking
• unit tests
• integration tests
• dependency scanning

Then the human reviews the overall result.

The ideal workflow may become:

AI generates
     ↓
AI reviews
     ↓
Automated tools verify
     ↓
Human evaluates
     ↓
Merge

The important part is the final step.

Human review shouldn't disappear just because AI review becomes better.

It should become more focused.

---

The Real Bottleneck Is Trust

The problem isn't that AI cannot generate enough code.

It can generate more code than most teams need.

The real question is:

How quickly can we turn generated code into trusted code?

That requires more than another model benchmark.

It requires:

better tests

better specifications

better observability

better security

better review tools

better architecture

and developers who understand the systems they're approving.

---

Final Thought

For decades, software engineering had a simple constraint:

Humans could only write code so fast.

AI is removing that constraint.

But software still has to be:

• correct
• secure
• understandable
• maintainable
• aligned with real requirements

So the next productivity revolution may not come from generating code even faster.

It may come from answering a harder question:

How do we verify machine-generated software at machine-generated speed without losing human understanding?

Because when AI can write thousands of lines before you've finished your coffee, writing code isn't necessarily the hard part anymore.

Knowing which code deserves to reach production is.

---

Sources

GitHub — Copilot Code Review Updates, September 2026
Recent improvements to AI-assisted code review, including deeper analysis, builds, tests, and agent-based review.

GitHub — Copilot Pull Request Review, September 2026
Updates around AI-assisted pull request evaluation and approval workflows.

Sonar — AI Technical Debt
Research and guidance around maintainability and verification risks from rapidly generated AI code.

Software Improvement Group — State of Software 2026
Industry analysis covering software quality, AI-generated code, review capacity, and security risk.

Comments

[Pushpendra Agrawal]

same blind spot shows up one step later. a team can review 1800 lines of ai code carefully and still break prod because nobody checked the new env var or the migration order. review catches logic bugs, not the deploy step. that gap is just as expensive and way quieter.

[Robert Adamson]

That’s a great point. We can spend a lot of time reviewing the code and still miss the things around it, like env changes, migrations, or deployment configuration.

AI can help with those checks too, but someone still needs to understand the full deployment path and make sure all the pieces line up.

[infracore]

A useful Level 1 step for those 27-file PRs is to review the contract before the code.

For API changes, generate openapi.json from the base branch and the PR head, then diff that first. If the change around DELETE /workspace/:id does not match the requirement that only account owners can permanently delete a workspace, there is no point reviewing the 1,800 lines yet. It turns "does this look right?" into a concrete requirement check.

[Robert Adamson]

That’s a really practical approach. Checking the contract first can save a lot of time, especially when AI-generated PRs touch so many files. It also makes the review more about whether we built the right thing, not just whether the code looks correct.

[Denis Sazonov]

writing a code never was an issue before. implementing feature - was.

It in general includes many things - tools, integrations, proper architecture, code, tests and of course code review, remember how many times it took us sometimes to approve the PR finally???
now every part of this system improved (including PR reviews) with a help of AI.
the problem now - we have to deal with much bigger cognitive load. mean we now should be X times more actively thinking about the same things.
shiping 1 feature a week before and shipping 10 features now! compare the diff!

[Robert Adamson]

Exactly. The interesting part is that AI didn’t just make coding faster — it accelerated almost every step around implementation too.

But shipping 10 features instead of 1 also means we have 10x more changes to understand. The real challenge now may be keeping up with the cognitive load, not the coding speed.

[Mateo Ruiz]

The most important distinction here is that verification can be perfectly correct and still validate the wrong thing. If the requirement is misunderstood, the implementation, tests, and AI review can all agree while the feature remains wrong from a business perspective.

That suggests a useful shift in review: don’t make the AI reviewer the final authority on whether the change is correct. Let it handle mechanical and code-level verification, while the human focuses on intent, invariants, and whether the changed behavior actually matches the product contract.

I’d also track review surface area, not just lines changed. Twenty small isolated changes may be easier to reason about than a 200-line change that crosses authentication, data access, and billing boundaries. As agents get faster, understanding the dependency and blast-radius structure of a change may become more valuable than simply reducing review time.

[Robert Adamson]

Yes, exactly. I really like the idea of measuring review surface area instead of just lines changed. A small change that touches auth, billing, and data access can be much harder to reason about than a larger isolated change.

As AI gets better at generating and verifying code, understanding intent and blast radius may become an even bigger part of the developer’s job.

[arun rajkumar]

The load-bearing move here is separating review from verification, and I would push it further. They are different jobs and only one of them scales.

Review is a human reading a diff and forming a belief. That is bounded by attention, and agents have already outrun it. Verification is asking whether what the diff does is permitted, and that does not have to be done by reading. It can be done by making whole classes of change unrepresentable.

In payments the pattern that works is narrowing the surface rather than speeding up the reading. Anything that moves money goes through one interface, and that interface gets reviewed as though it were the only code in the repo. A two-thousand-line agent diff that does not touch it gets a much cheaper look than a twenty-line one that does.

One worry about "verified, maintainable value shipped" as the metric: it is not measurable, and unmeasurable metrics lose to measurable ones every time. PRs merged will win. Something like "how much surface must a human read to believe this is safe" is at least countable, and it goes down when you do the right thing.

[Robert Adamson]

Exactly. I especially like the distinction between review and verification. If agents are already outrunning human attention, the answer probably isn't making humans read faster—it’s designing systems where dangerous changes have fewer places to hide.

And “how much surface must a human read to believe this is safe” is a much more practical metric than a vague productivity score. That shifts the goal from reviewing more code to making less code require deep human review.

[Nazmul Himel]

This is a really important point. AI has made code generation much faster, but review hasn’t accelerated at the same rate.

The bottleneck is shifting from “How fast can we write code?” to “How fast can we understand and validate code?” And reviewing AI-generated code properly still requires strong knowledge of architecture, edge cases, security, and the actual business requirements.

AI can increase our output, but without improving the review process, it can just increase the amount of code we need to maintain.

[Robert Adamson]

Exactly. The scary part is that AI can make the codebase grow faster than the team’s understanding of it. At some point, more output stops being productivity and starts becoming maintenance debt. I think the next big gains will come from making verification smarter, not just generation faster.