Code Review When Nobody Wrote the Code

A strange thing happened to my job this year. I used to review code written by people, and my mental model for review was built on that fact. When Alex wrote a gnarly caching layer, I knew his habits, his blind spots, where he tended to cut corners on error handling. Review was partly code analysis and partly a conversation with a mind I knew.

Now a meaningful share of every diff I review was generated by an agent, guided by a colleague. The code is usually competent. It is also authorless in a way that quietly breaks the old heuristics. Competent, confident, and occasionally wrong in ways no human would be wrong. Our review culture needed a rebuild, so we rebuilt it. Here is what we landed on.

New failure modes need new eyes

Human bugs cluster in predictable places: off-by-ones, unhandled nulls, the shortcut taken at 6pm. Agent bugs cluster differently. The patterns I now actively hunt for:

• Plausible APIs that do not exist, or exist with subtly different signatures. The code reads perfectly and fails at runtime.
• Silent scope creep. Asked to fix a bug, the agent also "improved" three adjacent functions. Each improvement is defensible; the combination is untested surface area.
• Confidently wrong domain logic. An agent will implement a discount calculation beautifully and get the business rule backwards, because the business rule lived in a Slack thread it never saw.
• Tests that mirror the implementation. Generated tests often assert what the code does rather than what it should do, which makes coverage numbers lie.

That last one changed my habits the most. I now read generated tests first and ask a simple question: if the implementation were wrong, would these tests notice?

The provenance rule

The single most useful norm we adopted is boring: every pull request declares how it was made. Not for blame, for calibration. Our PR template now includes a provenance block:

## Provenance
- Generated: caching layer, retry logic (agent, reviewed line-by-line)
- Hand-written: invalidation strategy, config
- Verified: unit tests pass, manually tested against staging

Reading a diff cold, I review generated sections and hand-written sections with different alertness. The declaration takes the author thirty seconds and saves the reviewer real time. And the rule underneath it is absolute: whoever opens the PR owns every line as if they typed it. "The agent did that" is not a sentence that exists in our retros.

Review got slower, and that is correct

Leadership everywhere is celebrating how fast code gets written now, and quietly wondering why review has become the bottleneck. It has, and it should be. Writing was never the expensive part; understanding was. When generation is nearly free, review is where the actual engineering happens.

We made three structural changes to protect it. Diffs have a soft size cap, because agents make it trivially easy to open thousand-line PRs and thousand-line PRs get rubber-stamped. Review time is scheduled, on calendars, not squeezed between meetings. And once a week we do a group review of one interesting diff, because review taste needs deliberate practice now that juniors get fewer at-bats writing from scratch.

The skill that matters now

If I were advising someone earlier in their career, I would say this: the market is flooding with people who can produce code, and thinning out on people who can evaluate it. Learn to read code adversarially. Learn to ask what is missing, not just what is wrong. Learn the domain deeply enough to catch the confident nonsense.

The agents will keep getting better, and honestly, I hope they do. Every hour they save me on boilerplate is an hour I spend on the parts of engineering that were always the point.