AI Can Write Code Faster Than We Can Review It

Coding agents are getting very good at producing code.

Maybe too good.

One engineer working with agents can now generate multiple meaningful pull requests in the time it previously took to implement a single feature.

That sounds like a massive productivity win.

Until you look at the review queue.

More agent throughput
        ↓
More code
        ↓
More pull requests
        ↓
Same number of experienced reviewers
        ↓
Review becomes the bottleneck

We didn't eliminate the bottleneck.

We moved it.

---

Why not let another agent review it?

That's the obvious next step.

Agent A
   ↓
writes code
   ↓
Agent B
   ↓
reviews code
   ↓
CI passes
   ↓
merge

And I absolutely think agent review will become an important part of modern engineering pipelines.

But there is an uncomfortable question hiding behind this model:

Who takes responsibility for code that no human has ever reviewed?

This matters a lot more when you're building systems where failures have consequences.

I've worked on cybersecurity products deployed in environments where security and reliability are not abstract quality metrics.

They matter operationally.

In that kind of environment, telling engineers:

"The agents reviewed each other's work."

is not necessarily enough.

Agents can independently catch bugs.

But they can also independently misunderstand the same requirement.

---

Code generation isn't the same as delivery throughput

There's another problem.

Imagine your agents create ten PRs today.

Your team can realistically review three.

Tomorrow the agents create ten more.

You haven't increased delivery throughput.

You've created 17 pieces of unfinished inventory.

This is basically a queueing problem.

And once you start looking at agentic development through that lens, the optimization target changes.

The question stops being:

How do we make agents generate even more code?

and becomes:

How do we safely move agent-generated changes through the engineering system?

---

I think the review pipeline needs to change

The answer probably isn't "humans review everything exactly as before."

That doesn't scale.

But I also don't think the answer is "agents approve agents and humans disappear."

A more realistic agent-native pipeline might look something like:

Agent implementation
        ↓
Deterministic verification
        ↓
Independent agent review
        ↓
Risk classification
        ↓
┌───────────────────────────────┐
│ Low risk → automated pipeline │
│ Medium   → targeted review    │
│ High     → deep human review  │
└───────────────────────────────┘
        ↓
Merge queue

The important part is risk.

Changing a typo in documentation isn't the same as changing authentication logic.

Updating a test helper isn't the same as touching authorization, cryptography, persistence, financial calculations, or safety-critical behavior.

Yet most PR workflows still treat them remarkably similarly.

---

Human attention becomes the scarce resource

Agents make implementation cheaper.

That means something else becomes relatively more expensive:

experienced human judgment.

We should probably stop spending that judgment on things machines can verify reliably.

Humans shouldn't be hunting for:

• formatting mistakes
• lint violations
• missing imports
• obvious null errors
• trivial test failures
• mechanical style inconsistencies

Machines are better suited for those.

Human reviewers should spend their limited attention asking questions such as:

• Does this architecture still make sense?
• Is the requirement interpreted correctly?
• What happens when a dependency fails?
• Did we introduce a security boundary violation?
• Does this change create an operational risk?
• Are there domain assumptions hidden in this implementation?
• Is this actually the right solution?

That's where engineering judgment matters.

---

And sometimes agents should simply stop coding

This may be one of the stranger consequences of agentic development.

If your review queue is already overloaded...

generating more code may have negative value.

That means agent orchestration systems may eventually need WIP limits just like mature manufacturing and Kanban systems.

if review_queue > threshold:
    stop_starting_new_work()

The most productive coding agent might occasionally be the one that decides:

Don't write another PR yet.

---

This is becoming a real engineering problem

I've been discussing this with people from other companies dealing with variations of the same problem.

The interesting part is that the conversation is already moving beyond:

"How can we use AI to write code?"

toward:

"How do we redesign the SDLC when producing code is no longer the expensive part?"

I've also been experimenting with some of these ideas while building Vincent, particularly around controlled agent workflows, deterministic steps, explicit states, human gates, and workflows that know when they should stop rather than blindly continuing.

I wrote a longer article exploring the problem, possible review architectures, and the parts I still don't think we have good answers for.

👉 When Agents Write Faster Than Humans Can Review

---

I'm curious how other teams are handling this

If you're already using coding agents heavily:

Has code generation started outpacing your team's review capacity?

And if it has, what did you change?

• More automated verification?
• Agent reviewers?
• Smaller PRs?
• Risk-based reviews?
• Merge queues?
• WIP limits?
• Something completely different?

I'd especially love to hear from teams using agents in security-sensitive or high-reliability systems.

Because I suspect the next major problem in agentic software development isn't going to be writing code.

It's going to be deciding what code we can trust.