PR Reviews in the Agentic Era: Who Reviews Agent-Written Code?

The weirdest PR I reviewed this month, I didn't write a single line of.

An agent scaffolded it, broke the tests twice, fixed them, pushed 600+ lines, and left me a neat little summary: "All done! Ready to merge."

It was not ready to merge.

Not because the code was bad. Most of it was fine. It wasn't ready because I had no idea why half of it existed, what it had tried and discarded, or what I was actually approving. The diff was clean. The context was missing.

That's PR review in the agentic era: the typing is free, the understanding is scarce.

What I shipped today

I stopped reviewing diffs and started reviewing briefs.

For one agent-built feature on this blog (social image generation plus the dispatch pipeline), I forced a rule: no PR over 400 lines, every push updates the PR body, every claim needs a command I can re-run.

That last one changed my whole workflow.

So… are PR reviews still necessary?

Honest answer: both sides are right.

The case for "skip it, it's ritual":

Old-style review assumed a human wrote the code slowly and another human catches typos. Agents don't make typos. They make confident architectural mistakes at 40x speed. Asking a tired human to catch a wrong auth boundary buried in 900 green lines on a Friday evening is theater, not safety. If your review is just "LGTM, formatting looks good," the agent already did that better than you.

Plus, agents can self-review now: lint, typecheck, run tests, even critique their own diff against your guidelines. For low-risk scaffolding, docs, or codemods, a full human ceremony costs more than it saves.

The case for "more necessary than ever":

Agents have no skin in the game. They don't get paged at 2am. They will happily:

• solve the prompt instead of the problem
• gold-plate a helper you'll maintain forever
• pick a plausible-but-wrong abstraction because it looked good in training data
• delete the edge case you actually needed because "simplified logic"

I rejected two agent implementations this week that passed all tests and were still wrong. One optimized for the happy path and quietly broke empty states. One introduced a new state store when the existing one already handled it. Tests green. Product wrong. Only a human who understood intent would catch that.

So the synthesis I'm landing on: stop reviewing syntax, start reviewing intent. The question isn't "is this code clean?" The model already answered that. The questions are: "is this the right change, is it the smallest change, and how do I know it works?"

How reviews actually work now

Here's the loop that's working for me on agent-written code:

1. The review starts before the diff

I don't let agents open a PR from a vague brief anymore. The PR starts as a plan:

• What problem, in one sentence
• What "done" looks like, including what not to touch
• How we'll verify: which command, which route, which test

If the plan is fuzzy, the diff will be fuzzy, just longer. I comment on the plan, not the 800 lines after the fact. It's 10x cheaper.

Think of it like Episode 1's rule: brief like you'd brief a sharp junior. A sharp junior with infinite typing speed and zero production trauma.

2. Small diffs or it didn't happen

This is the non-negotiable. Agents love big-bang PRs. Humans can't review them.

My rule now:

• One intent per PR. No "auth + refactor + copy tweaks."
• Under ~400 lines, or split into a stack
• Agent must say what it didn't do and why

If the agent hands me 1,200 lines, I don't review harder. I send it back: "Split into migration, UI, and copy. Stack them." The agent does in 3 minutes what used to take an afternoon of arguing about scope.

# what I ask for instead of one mega-PR
feat/auth-migration      # data + API only, no UI
feat/auth-ui             # stacked on top, UI only
feat/auth-copy           # stacked on top, strings only

Small diffs are a kindness to future-you, human or agent, doing git blame at midnight.

3. Keep the PR alive throughout

This is the part everyone skips, and it's the whole game.

In the old world, the PR description was written once and rotted. In the agentic world, the agent pushes 5 times after you last looked. The description says "WIP" while the diff now touches auth. You're reviewing a ghost.

My template now, and I make the agent update it on every push:

## Intent
One sentence: what user problem does this solve?
 
## What changed (current)
- Bullet per intent, not per file. Update on every push.
 
## Decisions + tradeoffs
- Chose X over Y because… (link to discussion / plan)
 
## Test evidence (paste output, not promises)
Run: `bun test` + `bunx tsc --noEmit`
- Pasted real output from latest push
 
## How to verify in 2 min
1. Go to /route
2. Do X, expect Y
 
## Risk + rollback
- Blast radius: …
- Rollback: revert this PR / flag: …

Three habits that make it stick:

1. PR body is the source of truth, not the first commit message. Stale description = not review-ready. I close without reading the diff.
2. Every agent push rewrites "What changed." I have it in AGENTS.md so agents do it automatically, not when I nag.
3. Decisions live in the PR, not in chat. Chat scrolls away. The merged PR is what the next agent (or human) will read in 6 months during git blame.

If you can't re-verify the PR in 2 minutes from the description alone, it's not ready, no matter how green CI is.

4. Let agents do the boring half

I let AI reviewers do what they're actually good at:

• style, dead code, missing tests, obvious perf traps
• "this file already has a helper for that"
• summarizing the diff into 5 bullets so I orient faster

I don't let them do what they're bad at: judging product intent, data-model fit, or "should this exist at all." That's my job. Human approves intent. Agent checks implementation.

Division of labor taped to my monitor: agents check correctness, humans check rightness.

5. Humans do the skeptical half

My actual review now takes 15 minutes and looks like this:

1. Read Intent + Decisions first. If I disagree, stop. Don't read code yet.
2. Skim the agent's summary, then ignore it and read the critical paths myself: auth, data flow, error states, migrations.
3. Run it. Click the unhappy path. Expire the token mid-request. Empty the list. Break it on purpose.
4. Ask one question the agent can't answer with confidence: "What happens at 1,000 users? What did you choose not to handle?"

From Episode 2: code is cheap, clarity is scarce. Review is where you enforce clarity.

The model note

Reviewing agent diffs made model differences painfully obvious. Writing code is commoditized. Explaining why it wrote the code is not.

The meta-lesson: pick the reviewer the way you pick the author. Fast model writes the boilerplate PR, strong model reviews the risky one, human reviews the intent. Always.

Future signal

Your README is already a system prompt (Episode 1). Your PR is about to become a lab notebook. Write it for the agent who will git blame this in 2027 and ask "why did they do it this way?" Because that agent might be yours.

You don't need to kill PR review. You need to kill the part where a human pretends to verify 900 lines they didn't watch being written.

Day 003 of building in the agentic era. Tomorrow: the guardrails that let me let agents touch production without losing sleep: required checks, scoped permissions, and the one rollback that saved me. If this resonated, share it. It keeps the streak honest.