# Why the agent that wrote the code should not be its only reviewer

> Separation of duties, shared blind spots and auditability in AI-assisted development, and why code from coding agents still needs an independent review.

Coding agents now write a meaningful share of the code in many pull requests. Most of them can also review: ask the agent to check its work and it will read the diff, run the tests and report that everything looks fine.

That self-check is useful. It is not a review. This guide explains why an independent reviewer still matters when an agent writes the code, and how MergeHarbor fits into an agent-driven workflow without slowing it down.

## Separation of duties

Engineering organizations have long separated the person who writes a change from the person who approves it. The reason is not that authors are careless. It is that the author is the person least able to see what they did not think of.

The same principle applies when the author is an agent. An agent that wrote a function has already decided what the function is for, which inputs matter and which cases can be ignored. When it reviews its own work, it reviews against those same decisions. A second reviewer that starts from the code rather than from the author's plan is more likely to notice that one of those decisions was wrong.

Separation also matters for accountability. When something breaks, "the agent wrote it and the agent approved it" is not an answer an incident review, an auditor or a customer will accept.

## Shared blind spots

An agent reviewing its own change shares its blind spots in several concrete ways:

- **The same context.** The agent loaded certain files while writing the change. If it never opened the caller in another package, its review will not open it either.
- **The same assumptions.** If the agent assumed a list is never empty, its tests will use non-empty lists, and the tests will pass.
- **The same goal.** The agent's task was to make the change work. A reviewer's task is to find where it does not. Those produce different questions.
- **Tests written to match the code.** Tests generated alongside an implementation tend to confirm what the implementation does, rather than what it should do.

Here is a small example. An agent is asked to make a lookup tolerant of missing users:

```ts
// users.ts (changed by the agent)
export async function findUser(id: string): Promise<User | undefined> {
  const row = await db.users.get(id);
  return row ?? undefined; // previously: throw new NotFoundError(id)
}
```

The agent updates the one caller it was looking at and writes a test for the new behaviour. Both pass. But another file it never opened still relies on the old contract:

```ts
// billing/invoice.ts (not in the diff)
const user = await findUser(invoice.userId);
sendReceipt(user.email); // was safe when findUser threw; now a TypeError
```

The author's review checks the change against the author's understanding. An independent reviewer that follows the callers of `findUser` finds the second file. The guide on [diff-only versus codebase-aware review](https://mergeharbor.com/guides/diff-only-vs-codebase-aware-review) goes into more examples like this one.

## Auditability

Regulated teams need to show that every change was reviewed, by whom, against which controls, and what happened to each problem found. An agent's self-review usually leaves no record beyond a chat transcript on one developer's machine.

An independent review leaves a record on the pull request and in a system of record. With MergeHarbor's [compliance evidence](https://mergeharbor.com/docs/compliance) on the Advanced and Enterprise plans, each merged pull request gets a sealed record of who opened, approved and merged it, every review with the models and rules in force, each finding and how it was resolved, and the result of each of your policies. The records are chained by hash, so a changed or removed record breaks the chain.

## A pull request cannot change its own review

When an agent can edit any file in the repository, it can also edit the reviewer's configuration. A reviewer that reads its settings from the pull request's own branch could be quietly weakened by the change it is reviewing.

MergeHarbor reads configuration and rules from the pull request's merge base, so a pull request [cannot change how it is reviewed](https://mergeharbor.com/docs/repository-config). Edits to `.mergeharbor.yml` or `.mergeharbor/` folders apply only after they merge. Organization administrators can also lock settings so repositories cannot weaken them.

## How MergeHarbor works alongside coding agents

Independent review does not have to mean a slower loop. MergeHarbor connects to coding agents at three points: before a push, on the pull request, and while fixing findings.

### Before the push

The [`mh` command line](https://mergeharbor.com/features/cli) reviews local changes with the same rules, configuration and codebase context as pull request reviews, without posting anything to the code host. An agent can run it as a step before it pushes:

```sh
mh review --staged          # review what is about to be committed
mh review --fail-on major   # exit 1 when a major finding turns up
```

`mh hook install` runs a review on every `git push` and stops when a major finding turns up. IDE and agent plugins add commands that review local changes and skills that review before a push, as described in [IDE and agent plugins](https://mergeharbor.com/docs/ide-and-agents).

### On the pull request

Every pull request gets the full review: [deterministic checks](https://mergeharbor.com/features/security-review), codebase-aware investigation, and a [verification pass](https://mergeharbor.com/product#verify) that tries to disprove each finding before it is posted. The [merge gate](https://mergeharbor.com/features/merge-gate) combines findings, tests, change risk and approvals into one verdict, so a required human approval stays required no matter who wrote the code.

### Handing findings back

Each review comment carries **Send to …** buttons for the coding agents your organization uses, and the review summary can hand over every open finding at once, grouped by file and ordered by severity. The buttons are signed links to the MergeHarbor console; the prompt loads only after the console checks that you can read the pull request, and nothing runs until you send it. See [Hand off fixes to coding agents](https://mergeharbor.com/docs/agent-handoff).

Agents can also work through MergeHarbor's [MCP server](https://mergeharbor.com/docs/integrations#coding-agents-mcp). The tools include:

| Tool               | What it does                                                           |
| ------------------ | ---------------------------------------------------------------------- |
| `list_unaddressed` | Open findings on a pull request, found from your repository and branch |
| `fix_all_plan`     | Every open finding in one ordered plan, grouped by file                |
| `apply_fix`        | A patch for a suggested change, re-anchored onto your copy of the file |
| `mark_addressed`   | Marks the findings you fixed as addressed                              |
| `get_change_risk`  | A pull request's change risk: score, level and the reasons behind it   |
| `list_rules`       | Read your team's rules, so the agent writes code that follows them     |

Each agent signs in as you and works with your permissions.

### Fix until clean, with a limit

A plugin command can collect the findings on a branch, fix them most severe first, run your tests and review again. It stops after three rounds by default, since each review uses credits. When a push applies a suggested change or removes the reported code, MergeHarbor marks the finding resolved with the fixing commit. A finding someone reopens is never resolved automatically again.

### Measure the loop

Every hand-off is recorded: which finding went to which agent, and whether it was resolved afterwards. **Agent hand-off outcomes** in analytics shows, per agent, how many findings were sent and how many were fixed.

## Putting it together

A workflow that keeps the speed of coding agents and the safety of independent review looks like this:

1. The agent writes the change and runs a local review before pushing.
2. MergeHarbor reviews the pull request with codebase context and verifies each finding.
3. Findings go back to the agent in one click or over MCP, and are resolved by the fixing commit.
4. The merge gate reports one verdict, and a person approves the merge.
5. The record of all of it stays with the pull request.

The agent does more of the typing. The review stays independent, and a person still decides what ships.

## Further reading

- [Coding agents and MCP](https://mergeharbor.com/features/coding-agents)
- [Merge gate](https://mergeharbor.com/features/merge-gate) and [compliance evidence](https://mergeharbor.com/compliance)
- [A code review checklist](https://mergeharbor.com/guides/code-review-checklist)