Why human review stays the merge gate for AI coding agents

AI coding agents have become good enough to take a GitHub issue, write a plan, change the code, run the tests and open a pull request. That raises a fair question: if the agent can do all of that, why should a person still press the merge button? In this article I explain why I keep human review as the merge gate, and how to make that review fast instead of a bottleneck.

What an agent can and cannot check

An agent is very good at the mechanical part of a change. It reads the code, follows the patterns it finds, writes the change and runs whatever checks the repository has. When the tests pass, it can tell you so with confidence.

What it cannot check is whether the change was the right one. An issue is often a short description of a problem, written by someone who knows things that are not in the repository: what a customer actually asked for, which part of the product is about to change, what was agreed in a meeting. The agent only sees the text. When that text is ambiguous, it picks an interpretation and builds it well. A green test run then confirms that the code does what the agent intended, not what you intended.

That gap is not a flaw of one particular model. It is the nature of working from a written ticket. A junior developer has the same problem, and we solve it the same way: someone who knows the context looks at the result before it ships.

Why the author should never be the approver

In most teams, the person who writes a change is not the person who approves it. That rule exists because people are bad at spotting their own mistakes. They read what they meant to write.

The same applies to an agent, and more strongly. If one process writes the code, judges whether the code is good and then merges it, every mistake it makes in the first step can pass through the other two. An agent that misunderstood the issue will also misunderstand it while reviewing its own work.

A self-review step inside the agent is still useful. It catches missing tests, forgotten edge cases and code that does not match the plan. But it is a quality step, not an approval. The approval belongs to someone who did not write the change.

Make review cheap instead of skipping it

The usual objection is time. If the agent saves an hour of work and the review costs another hour, nothing is gained. That is true, but the answer is to make review cheap, not to skip it.

A pull request is quick to review when it has a few properties:

• It is small. One issue, one change. A pull request that touches thirty files for one ticket is hard to judge, whoever wrote it.
• It explains itself. The description says what was wrong, what changed and how it was tested.
• It shows the plan. Reading the plan first tells you in a minute whether the agent understood the problem.
• It has a test run. Green checks mean you spend your attention on intent, not on syntax.

With those in place, most reviews come down to two questions: did it solve the right problem, and is there anything here I would not want in production? That takes minutes, and it is exactly the part where your knowledge of the product is worth the most.

Three controls, not one

When you let an agent work on a real repository, it helps to think in separate controls that each stop a different failure.

Each one covers a gap the others leave open. The allowlist decides who may start work. Branch protection makes sure the agent can only push its own feature branch. The approval decides what ships. If you remove one because the other two seem enough, you are betting that the failure it covered will never happen.

In agentic-coder the allowlist and the human approval are the default. The pipeline pushes a feature branch and opens a pull request that closes the issue, and nothing merges without a person approving it. Branch protection is a setting in GitHub itself, so that one you switch on for your repository.

Where auto-merge does make sense

There are changes where a human review adds little. A dependency bump with a full test suite behind it, a typo in a help text, a generated file that follows from a schema. For those, waiting for a person mostly adds delay.

Auto-merge is reasonable there, under two conditions. First, it is a choice you make per repository, not a default that is quietly on everywhere. Second, it only applies when the checks are green and the branch is up to date with the main branch, so a merge cannot land on a base it was never tested against.

Watch out for one specific trap: tests that the agent changed. If a fix turns a failing test green by weakening or deleting the test, every automated check will pass. That is the one thing an automated gate cannot see, and the strongest reason to keep a person in the loop for anything that matters.

Conclusion

An AI coding agent can do most of the work between an issue and a pull request, and it does that work well. The merge is different: it is the moment someone decides the change is right, and that decision needs context the agent does not have. Keep the author and the approver separate, make the pull request small and self-explaining so review takes minutes, and treat auto-merge as a deliberate exception. That way you get the speed of the agent without giving up the judgement that keeps your main branch safe.