“Simultaneous Exhibition” by Ed Lyons via Midjourney

Is it really possible for you to stop reading the pull requests and let the agents review the code by themselves? The surprising answer is yes, for many of them. If you are willing to work hard at your configuration, you and your team may only have to review some of your pull requests for most applications.

After more than a year of telling all developers, “You must read the code” it is unimaginable that we could stop doing this. On top of that, none of the code review tool vendors or open source review projects are claiming you can do this. And on top of that, a fascinating long-running research project that had four leading agentic code review tools look at nearly 150 PRs found that while nearly all problems were detected, each agent saw entirely different things (!!).

Despite all of that, I am still going to tell you what the most advanced agentic developers have concluded: you really don’t have to review a lot of the code anymore if you put the right orchestration and tooling in place. Letting the agents review, fix, and merge most PRs themselves dramatically reduces the biggest bottleneck left in agentic coding: the human review time.

To demonstrate how this is permissible and possible, this essay will be a deep dive covering the rationale for this, as well as tools and techniques for better agent reviews of code. Even if you still maintain all of your human PR reviews, you will learn a lot about how to improve reviews by both people and machines.

But first, as a crucial part of the argument about why this is permissible, we have to talk about how we got here. Because code review, as a software practice, has lost its way in a world of pull requests. The arrival of agents made things worse. Our initial response to agentic code is preventing many developers from seeing the way forward.

So pull up a chair.

Sections:

The Why

A 20th Century Code Review
The Pull Request Arrives
AI Becomes the Coder, Humans Review
Generated Code Becomes Very Good
The Best Agentic Developers Start to Go Rogue

The How

Taking Pressure Off The PR
Clever and Comprehensive Agent Reviews
New Human Reviews
The New Social PR

Conclusion

What should you do now?

A 20th Century Code Review

It may seem odd to start our discussion of cutting edge tech with one of my code reviews from 30 years ago. But we need to know what code reviews were for decades, and why, over the past 15 years, code reviews have slowly gone off track, leading to the quagmire we are in now.

It’s 1996. I am sitting in a windowless room for a code review. Three programmers I work with enter, each having a printed copy of the C program I am working on. We talk for about 30 minutes, while they point out the good and bad things about what I have been working on lately. I agree to make the corrections, and thank them for their time. We did this every so often. It was a bit of a social occasion as well as an engineering review.

But long periods of time passed where reviews didn’t happen. Often, code got merged into the application without a formal review. This wasn’t just where I worked. This happened everywhere.

Reviews weren’t the only way we ensured quality. We had coding standards and we wrote lots of tests. We had tools that scanned the code for problems. And there was application testing done before we released anything. A few critical or security-related applications in the organization had more rigorous, weekly reviews. But those were the exceptions.

For many years, nearly all reviews were like this. They were not always exercises in good engineering. Sometimes reviewers were wise and accurate. Sometimes they nitpicked or asked for changes that provided no value. Often they missed bugs that would arise later. Twice in my career, I had a team lead who didn’t like me, and my reviews were petty. Lots of us in those days had a few bad code review experiences.

From my perspective now, I am certain that a well-orchestrated, adversarial agentic code review would be far better than nearly all in-person reviews I received during those years. Yes, at times, the humans would have caught something today’s agents would miss. But it wouldn’t be worth it.

But if my team in 1996 would have outsourced most reviews to today’s agents, why wouldn’t we do that now? What has changed?

It’s not just that we aren’t directly writing the code anymore. We will get to that in time.

The Pull Request Arrives

It’s 2013. Git has been around for several years, but the popularity of GitHub has brought in a new process and cultural phenomenon: The Pull Request.

The pull request changed everything. It had a great interface, it was right in the browser, and crucially, it was asynchronous. It didn’t require that a few people find a time and place to meet.

It was a social mechanism where all kinds of people could talk to you about your contribution. It wasn’t seen as the only defense against coding errors.

Many organizations kept doing code reviews in addition to PRs, and were better for it. But the culture changed, more people worked remotely, and the PR became the default quality gate as code review meetings faded away. As pipelines became common, the PR became their entry point.

Other problems appeared that would worsen review quality in a world of PRs.

In many open source projects, there were often lively debates in PR reviews, which maintained their vitality. But inside the typical corporation, this was not the case. There were lots of silent PR approvals with no feedback. Sometimes they were because the code was excellent. Sometimes they were due to other things: laziness, friendship, politics, or a need for speed. For example, PRs posted near releases or to fix urgent bugs often get less scrutiny. On many occasions, we have all just said to ourselves, “We just need to get this through” and pushed the approve button. All of us.

I can’t imagine in the pre-PR world that I would have frequent code review meetings where nobody had anything to say. Or that we would review code shortly before a release when everyone was scrambling and we had to deploy.

Whenever I talk to engineering managers I know, and bring up what PR reviews really are - what actually happens on a Tuesday afternoon when everyone is busy - the response is an awkward, “Well… uh… yeah.”

How good have PRs been in stopping bugs? Imagine doing an analysis in your organization of software bugs in the pre-agent PR era (~2012 to 2024) and finding out how many of them were missed by senior developers who approved them? It would be quite a few, no? Yet here in 2026, we are somehow afraid an agent review will miss something.

The PR review is certainly not the ideal form of code quality maintenance. It was not intended to be, and we need to remember that.

AI Becomes the Coder, Humans Review

It’s spring, 2025. Using AI to generate code has gone mainstream. Tools like Cursor and Claude Code create a lot of pretty good code. Yet un-orchestrated agent code has significant problems, and is often bloated.

PR reviews suddenly become more important than ever for finding agent code problems. It is not because they were designed for this, but because it was the quality gate everyone had.

Let us not miss another brand-new motivation for the human PR review. Many developers, worried about their career prospects, immediately agreed that they were still needed to review the code.

This new framing - agent code isn’t good enough, and humans are needed to review it - was powerful and resilient.

Here is an interesting thought experiment for 2025: if a human developer carefully wrote the code by hand instead of using agents, would a well-orchestrated agent review from 2026 be enough for a PR? The answer might have been yes.

Generated Code Becomes Very Good

It’s summer, 2026. The models have improved substantially in their raw coding ability. In addition, the harnesses have improved, there are new tools, and hard-won orchestration techniques also improved the quality of code even further. Many senior developers with good agentic skills are seeing that the generated code can be very good, and often needs far less scrutiny than a year ago. Agentic code review quality has also improved significantly, due to use of specifications, adversarial agent reviews, and other new practices.

As many developers are now more productive with agents, human review has become the big bottleneck in getting features into the application. At very agentic software shops, PRs are piling up in the queues. Some start to wonder: do we really have to review all of this?

Yet the 2025 framing endures: we must review all the code.

However, some advanced developers who are good with the agents now worry less about their careers and see a prosperous future in agent orchestration and technical oversight. Though many more developers still feel threatened by the more powerful coding agents, and resist the idea that their human reviews could sometimes be skipped.

The Best Agentic Developers Start To Go Rogue

One thing we have learned is that a coding agent is not a pair programmer, but a multiplier of your skills. For junior developers who aren’t very skilled with agents, the human review bottleneck is certainly a burden, but they don’t generate that much more code with agents. Also, their agentic code has problems. They need human reviews to fix them.

But for the best developers who also have excellent agent orchestration skills, they face a different situation. They generate a ton more code than the juniors do, and the human review bottleneck is a far bigger problem. And unlike the juniors, their code is of better quality, and need less review.

It isn’t hard to see what their risk/reward calculation is going to be. The 2025 human review framing no longer works for them. They know they can orchestrate their generated code to be very good, and they can envision a coding-free future for themselves as creative orchestrators or engineering entrepreneurs.

So they go rogue.

In early January of this year, when Steve Yegge released his famous Gastown framework, he admitted that he never looked at the code at all. He became an advocate for developers to stop caring about the code. I saw a few others of his skill level saying similar things, especially if they were solo practitioners. I also started hearing about small teams of very senior engineers quietly agreeing to just push through the PRs and breathe in the intoxicating velocity.

Among elite developers, the human PR review has been deprecated. Their agents occasionally appeal to a human to resolve a problem, but most of the time, the agents fix their own problems and merge the code.

As the models and tooling get better, and as more developers become skilled at orchestrating the agents, those newly-confident developers will come to the same conclusion.

Even Addy Osmani, former Google dev tool agentic maestro, is now telling his huge audience (end of this piece here) that maybe the human reviews are no longer necessary all the time. He points out that “zero-review merges” have increased dramatically, which is a sign of surrender by human reviewers that cannot be ignored. He recommends prioritizing human review time by the risk of the components being changed, and for humans to review tests and specs more than lines of code.

Osmani is a bellwether of changing opinions, as he’s been far more conservative than maverick developers like Yegge.

The handwriting is on the wall. The human PR review is on borrowed time.

But how on Earth are some people letting go without wrecking their applications?

Taking Pressure Off the PR

We will get to the review tooling required to make agent-only reviews possible, but first, some of what makes this possible comes from outside the PR.

Automating quality checks before the PR is submitted is one way to take some of the burden off PR reviews.

Another is long-running agent tasks. You can set up cloud-based agents to run regularly to ensure compliance with standards, to improve test quality, and to do overall reviews. If you know there are good codebase reviews running regularly, it won’t all come down to the PR. This is important because while any individual merge might be OK, the overall quality of the codebase can still decline.

Finally, make a point of reviewing the specifications for the code that was generated. Many SDLC tools like Superpowers will generate both design and implementation documents. For large features, these are better review targets than the resulting PR code.

Clever and Comprehensive Agent Reviews

The basis of trusting agentic code reviews is making sure they are comprehensive and adversarial.

Many developers merely ask the agent they have been using to do a code review before they submit a PR, or have an agent run in their pipeline to examine PRs and make changes. But that isn’t enough.

The image I have in my mind - which I used to generate the image at the top of this essay - is of a simultaneous chess exhibition. Great masters often set these up at tournaments. The master stands in the middle of a room, and lots of players come to play him across many boards. The challengers aren’t all experts, but they represent many styles, and they are trying to win. The master walks from board to board, making one move at a time. If the master is very good, he can win or draw every game, even though he has far less time to think of each move as his opponents do. Often the players will make their plans ahead of time, and play tricky moves the master does not expect, hoping to force a mistake. These events are quite adversarial, but they are fun! While I have never beaten a master in these events, on rare occasions, someone does and can brag about it to their friends.

This is how you should think of your agent reviews. The best agentic developers, like hopeful players at simultaneous exhibitions, love to talk about their review strategies, and will describe their favorite review personality, and all the different ways code can be evaluated. They take the reviews seriously. They don’t just ask an agent for a code review.

There are several proven techniques that individual reviewers and agentic code review tools use.

You can warm up by looking at open source agent review files for Superpowers, Matt Pocock’s skills, and Google’s Agent Skills. Or you can look at Alibaba’s large and impressive code review agent framework.

I’ve looked at many review tools, both open and commercial. Here is a list of common patterns:

A quality scoring system: You want the output to contain a number that is actionable. The open source review skills show examples.

Review against the entire codebase, not just the diffs: You probably want to check that your changes didn’t break something elsewhere. This can use a lot of tokens, so consider using an indexing tool to let the agent trace code paths with less overhead, such as Cocoindex.

You should have more than one reviewer: As that shocking four-agent experiment showed, you need a second opinion. Perhaps more.

Adversarial reviews without shared context: You must instruct agents to be very critical, ground them in the right expertise in their instruction files, and isolate them from other agent sessions so they do not absorb bad assumptions.

A mechanism to fix code that you are comfortable with: Sophisticated agent reviews have loops to perform automatic repairs. Agents are capable of determining how difficult or risky a change would be. You should use your scoring system to determine whether the agent fixes something on its own.

Flag certain areas as requiring human review: It is a good practice to tell the agent that certain kinds of changes require human review every time, such as an important schema change, or anything to do with security.

Can junior developers participate in such a review system? Yes. As long as you have a scoring system, less accurate PRs will get lower scores and will trigger human reviews.

Before we move on, it’s well worth stopping to ponder one of the most aggressive and sophisticated open source review systems I have seen. It is ambitiously named, “No Mistakes.”

There are many interesting, artisanal hobbyist AI tools with little adoption, but this one has several thousand GitHub stars, 92 releases, 26 contributors and more than 500 forks. The creator says he no longer looks at his code.

The goal of this framework is to move rigorous review from your CI pipeline to your development environment, close to where you are doing the work. It sets up a local git proxy, and you push to that instead of directly to your repository.

It’s a robust pipeline on your machine that is meant to dramatically improve the quality of your PR by doing rigorous reviews first.

It works with several popular agent harnesses. I used Claude Code, found a sample front-end project, and did an upgrade of the core React library on a local branch. Then I pushed it into the pipeline where I could view its progress.

One great feature is that you can push your branch into the pipeline and go do something else on a different branch. You can come back to the dashboard and see if the loops and reviews resulted in an action item for you.

I really liked this pipeline, and I am going to use it when I am not employing cloud agents.

New Human Reviews

About a year ago, when I stopped writing the code by hand, I decided to create a new review practice outside of PRs. A few nights a week, I would take about an hour to look over the code in my application. Sometimes it would be agent-assisted, where I would ask questions about recent changes. Other times, it was just me poking around. I found it helped me discover things I’d overlooked. Usually a review resulted in a PR with alterations.

I highly recommend creating time to look at your code outside your SDLC. I have found it good for my psychology as well as my non-agent skill maintenance.

I also believe a team should make time to review code in critical areas.

Is there time for human reviews in a time when velocity is prized so highly?

Yes. One of the reasons I advise people to automate aggressively is not because everything should be moving at warp speed. It is because aggressive automations in most areas buy time to slow down and do careful human reviews of specifications, processes, and code.

The New Social PR

The new PR review is now less important and is focused on judging how critical the code and the problems are. It is no longer your only defense against agent code mistakes, but is the first opportunity for somebody else to weigh in. It is the social attention mechanism that GitHub intended in the first place.

Conclusion: What Should You Do Now?

We have covered a lot of ground.

There is no question that most organizations are not in a position to abandon most human PR reviews, due to uneven agentic skill levels across teams and a lack of proper orchestrations and tooling. Less-sophisticated agentic techniques to improve code quality are a better short-term investment.

However, there are things that can be done that will provide benefits even while requiring human reviews.

Taking pressure off the PR is a great place to start. Get other human reviews going. Schedule project-wide agentic code reviews using cloud-based tasks working from specifications.

Install adversarial agent reviews into your PR process, and let them see the entire codebase, not just the diffs.

Get developers to do better reviews of their own code before submitting a PR to the team. Have your most advanced agentic developers try out the ‘No Mistakes’ pipeline and discuss their experiences with others.

In general, it is time to up your game with agentic code reviews, establish new human reviews, and restore the pull request to the social opportunity it was meant to be.

It is Now Possible to Remove Humans From Many PR Reviews. A Deep Dive into When, Why, and How. By Ed Lyons