Code review and ownership when agents write the code

When agents write a growing share of the code, two things quietly break. Authors stop feeling responsible for code they didn’t type. Reviewers get more pull requests, bigger ones, and start rubber-stamping.

Both problems have the same root: nobody decided who owns agent-written code. So decide it.

One rule: whoever opens the PR owns it

I use a single rule on every team I work with. The person who opens the pull request owns every line in it, exactly as if they had typed it. “The agent wrote that” is never an answer in review.

1. 📝Author briefsScope and acceptance criteria
2. ↓→
3. 🤖Agent buildsCode, tests, summary
4. ↓→
5. 🔍Author reviewsFull self-review first
6. ↓→
7. 📬PR with contextBrief, map, open questions
8. ↓→
9. 👥Peer reviewHuman judgment, not a rerun

↺ Review findings go back to the author, who re-briefs the agent or fixes by hand

The middle step is where teams cut corners. If the author hasn’t read the diff, the reviewer is doing the author’s job, and doing it with less context.

Make agent involvement visible

Hiding that an agent wrote the code helps nobody. Reviewers read differently when they know: they look harder at tests, edge cases and invented dependencies.

## What and why
Adds CSV export to the invoices page. Closes the ticket linked below.

## How this was built
Agent-assisted. I wrote the brief (linked) and reviewed every file.
Agent wrote: export service, tests. I rewrote: the date formatting.

## Where to look
- core logic: services/export.ts (column mapping, escaping)
- tests: export.test.ts, includes quotes and commas in fields
- mechanical: route registration, imports

## Not verified
- Exports over 10k rows (no fixture that large yet)

The “Where to look” block comes straight from the review guide you ask the agent for, covered in Module 4. The author checks it, then passes it on.

Who owns what: check yourself

🧠 Ownership scenarios

Score: 0 / 4

1. 1. A bug ships in code an agent wrote and the author only skimmed. Who owns the fix?

   The reviewer who approved itThe author who opened the PRWhoever configured the agentNobody, it's a tooling issue

   The author owns every line they submit. The reviewer shares responsibility for the approval, but the code is the author's.

2. 2. An AI review bot approves a PR with no comments. What should happen?

   Merge it, the bot found nothingA human still reviews it, using the bot's pass as a head startAsk the bot again with a stricter promptSkip tests since review passed

   Automated review catches some issues cheaply. It doesn't replace a person who understands why the change exists.

3. 3. A reviewer asks why the agent picked a new library. The author doesn't know. Best move?

   Reply that the agent chose itApprove and open a follow-up ticketFind out, then justify it or remove it before mergingAsk the reviewer to check the library

   If the author can't defend a decision, the PR isn't ready. Dependencies especially outlive the task.

4. 4. An agent run produced a 2,000-line PR touching three features. What do you do?

   Request review from three people at onceSplit it into smaller PRs, one concern eachMerge behind a flag to save timeAsk the reviewer to focus on the tests

   Large mixed PRs get skimmed. Splitting restores real review, and it's cheap: you can ask the agent to help carve the branches.

↺ Try again

Before you move on

✅ Key takeaways

0 / 5 completed

• Whoever opens the PR owns every line in it, whoever typed it.
• I self-review agent code before anyone else sees it.
• Our PR template makes agent involvement and unverified areas visible.
• PRs stay small enough for a human to review in one sitting.
• AI review is a first pass; a human approves.

↺ Reset