I merge PRs I never read

On September 29 I clicked merge on a pull request of about 15,000 lines. 271 files. It was the new Trove CLI, the one every one of our users updates to automatically.

I did not read a single line of it.

It is some of the best code I have ever merged. And the reason it was safe has nothing to do with the agent that wrote it. It has to do with who owns what on our team.

Own the knowledge, not the code

For years we split teams by code. This person owns billing. That person owns the search service. Big companies wrote it into the repository: Google keeps an OWNERS file in each directory, so every change is approved by someone who knows that part of the code.

Even there, ownership was never about possession. Software Engineering at Google says owners are really stewards, people who hold the knowledge and the responsibility for a part of the system. In the same book: "Documents without owners become stale and difficult to maintain."

Now agents write the code, in every corner of the codebase, at a speed no owner can follow line by line. The lines a person wrote matter less every month. What they know matters more. And knowledge travels in a way code never did. The reason billing retries carry an idempotency key helps the team building exports. A trap one team found in the auth service saves another team a week. A line of code stays in one file. A lesson can protect every repository you have, if it is written somewhere an agent can read.

So I ask teams to give knowledge owners instead of code owners:

• The architect owns the architecture knowledge. Where the boundaries are, why the services are split the way they are, and what must never call what.
• The tech lead owns the review knowledge. The document that says what every change on this team is checked for.
• The engineer who built a service owns the knowledge of that service. How it works, where it breaks, and why that one module looks strange.

An owner does not write every line. Anyone on the team, and any agent, can propose one. The owner decides what goes in and keeps it true. The rest of this post is about one of those three, the review knowledge, because that is where I saw teams get stuck first.

The bottleneck moves

For the last two and a half years I have been going into companies and helping them bring AI into how they build software. It starts the same way every time. We teach the team to work well with agents. And very quickly we reach the first point where it breaks: the bottleneck just moves down the line.

Code gets written several times faster. But code review, QA, approvals and DevOps keep the same pace. The team burns tokens and money, and the product ships at the same speed as before.

So I tried to teach teams to do code review for agents. Define your standards. Describe where the codebase is today. Tell the agent where you want it to go. In some companies this worked. In others it just got stuck. I was pretty frustrated.

A thought experiment

Then I ran a thought experiment with one team.

"Say you did the product work right, and you defined exactly what done means. Say an agent went over the change with a code review document that all of you agree on, and the change meets everything in it. And say another agent ran QA end to end, and put screenshots of the frontend and sample calls to the backend on the PR. What is left for you to read?"

Here is what that looks like on a real ticket. Users can export their invoices as a CSV file. Done means: the button is on the invoices page, the file has the agreed columns, a month with no invoices gives a file with headers only, and a user can never export someone else's invoices.

The review agent reads the diff against the team's document and reports what it found, line by line. The QA agent signs in as two different users. It clicks the button, downloads both files, opens them and attaches screenshots to the PR. Then it calls the export endpoint as the first user with the second user's account id and shows the refusal.

You open the PR. What do you still need to read?

That team got it in about a minute. They have a written process. When you ask them how they do code review, the answer is clear.

Most teams I ask give me a mix of answers. "Someone else on the team goes over it." "If we don't trust them, someone checks them too." And how do people learn to review? They do a lot of reviews and get comments on them.

A document that lists what to look for? There isn't one.

This is not an agent problem

It is knowledge that was never written down, and nobody owns it. We trust people to remember every scar in the codebase and, on a good day, to bring it up in the right review.

Review has always been how this knowledge moved around a team. In Best Kept Secrets of Peer Code Review, Jason Cohen describes learning more as the reviewer than the author did, and says his team's insights "were spread around quickly," faster than any other technique they could have invented. That worked while the knowledge passed from person to person, one review at a time. An agent was never in those reviews. It only knows what someone wrote down.

So with these teams I focus on one thing. Write down your code review process. And who owns it? The tech lead.

What goes in a team's review document

A review document is not a style guide. The linter already handles style. It is the list of things your team checks because it got burned once, or because your product cannot afford the mistake.

Here is the kind of line that belongs in it:

• Every query that reads customer data filters by the current account. Admin screens too.
• A migration that drops or renames a column ships in two steps. First the code stops using it. The column goes in a later release.
• Money is an integer number of cents. Never a float.
• Every new endpoint says who may call it, and a test shows that the wrong user gets refused.
• A retry on a payment or an email carries an idempotency key, so it can never happen twice.
• No new dependency without one line in the PR on why it is needed.
• An error a user sees never includes a stack trace or an internal id.
• A change to the public API changes the docs in the same PR.

Each line says what to check and why. It also says how bad a miss is, because the agent has to know which findings block the merge and which are a note for later.

Look at that list again. Most of it is about things that are missing: the filter nobody added, the test nobody wrote. Cohen found the same with human reviewers. A checklist is best at catching omissions, the errors that are hardest to see, because "if the author forgot it, the reviewer is likely to forget it as well."

Half of that list also only makes sense for one product. That is why I don't believe in one review agent for the whole company. I have seen companies build exactly that. They all failed or will fail. Every team has its own product and its own scars, and only the team knows what really needs checking.

And even the best document will miss things. Bugs reached production when humans did the review too. The difference is that now every bug becomes a new line in the document, and the owner decides how it is worded and how bad a miss is.

You do not have to start from a blank page, though. The general part, the part every team shares, is already written.

What every team must check

Two areas show up on almost every team's list, and they are where a miss costs the most: data and security. They are also the two that QA alone will not catch.

Data first. A migration that locks a large table in the middle of the day. A query with no index that is fast on the test database and slow on the real one. A transaction that reads, decides and then writes, and lets two requests both win. None of these show up in a screenshot. The QA agent can pass and the bug is still there, waiting for real traffic.

Then security. A user who can read another user's record by changing an id in the URL. An admin route that checks that you are signed in but not that you are an admin. Input that ends up in a query or on a page without being escaped. An agent will write all of these without a second thought if nobody told it to look.

Putting it inside your Claude Code sessions

Ownership only works if the knowledge reaches the session where the code is written. Here is how that looks in practice.

On your own. You wear all three hats. Keep the rules that always apply in your CLAUDE.md. Keep the review document as a file in the repository, and give your review agent one instruction: read it before you look at the diff, and report every finding with its severity. Then add one habit. When a session hits a bug, a trap or a decision worth keeping, ask the agent to propose a new line for the right document before the session ends. You approve it or you don't. Within a few weeks the document is full of your own scars, and every new session starts with them.

As a team. Files in one repository stop working the moment the knowledge has to cross to another repository or another team. And a file anyone can edit soon has no owner at all. This is the part we built Trove for. Each owner keeps a living book in the team library: the architect keeps the architecture book, the tech lead keeps the review guide, the engineer who built a service keeps the book for that service. Each book says when an agent should add to it. Our review guide says: log a rule when the tech lead states a review guideline specific to our codebase, with its severity. Before a task, every teammate's Claude Code session reads the books that matter for it. When a session learns something that matches a book, the agent proposes the line, and a person approves it before it lands. A lesson found at 1am in one service is in every session on the team the next morning.

How we work at Trove

This is how I worked at Trove. In the 30 days up to October 18 we merged 193 PRs to production, with real users and very few bugs. By my estimate, that is work that would have taken 12 engineers several months.

That is why I could merge the new CLI without reading it. I did not trust the agent that wrote it. I trusted what the change had to pass before it reached me, and every line of that had an owner.

The real question

We thought the question was whether you can trust an agent that writes code. The real question is whether your team can write down what good code means for them, and who keeps it true.

To help you start, I built three code review books for agents: code, data and security. They bring together the principles of Robert C. Martin, Martin Fowler, Steve McConnell, Michael Nygard, Martin Kleppmann and OWASP. On top of them I added the scars we collected along the way.

Add them to your library, point your review agent at them, and then start writing your own lines on top. You can find all three in the Trove marketplace.

Code review is the first of three stages in the software production line. The other two are for the next posts.