Party of One for Code Review!

In 1976, Michael Fagan published “Design and Code Inspections to Reduce Errors in Program Development” in the IBM Systems Journal. Inspections were meticulous, rigorous, exactly what you’d expect from IBM in that era. Formal roles—moderator, reader, recorder. Checklists. Metrics. The whole apparatus.

Hardly anyone actually did it. Too much work. Too tedious.

What we got instead was something looser—code review as a general practice, borrowing Fagan’s central insight (other humans looking at your code catches problems you can’t see yourself) while quietly dropping the formality that made it feel like a tax audit. The aspiration was rigorous inspection. The reality was “hey, can you look at this before I merge it?”

Along came open source & the case for code review strengthened.

• You didn’t necessarily know the person who submitted the code.

• You couldn’t trust them not to break the system.

• You couldn’t trust them not to damage the design.

• You couldn’t count on them working at the same time as you did.

Code review became a sign of maturity, responsibility. To skip code review signaled a wild programmer, irresponsible.

The Traditional Case

The arguments for code review are:

• Knowledge sharing across the team

• Catching bugs before they affect others

• Maintaining shared ownership of the codebase

• Keeping coding standards consistent

These all assume something: multiple humans, working at a pace where review is actually feasible. You write some code, I look at it, we talk, we both learn something. The feedback loop is tight enough to catch real problems.

For decades, this worked. Mostly.

The Async Problem (Even Before AI)

Here’s another confession: even this lighter-weight code review was already breaking before AI accelerated everything.

The theory was synchronous-ish collaboration. The practice was PRs sitting for days while context decayed. Reviewers skimming because they had their own work to do. “LGTM” culture—rubber stamping dressed up as process.

I’ve been on both sides of this. I’ve rubber-stamped PRs because I didn’t have time to really understand them. I’ve had my PRs rubber-stamped and felt a mix of relief (it’s merged!) and unease (did anyone actually look at this?).

The feedback loop got too slow to catch the things it was supposed to catch. By the time someone noticed a structural problem, three more features had been built on top of it.

This isn’t a criticism of any particular team. It’s a recognition that the economics were already strained, the incentives skewed. We wanted review to do more than time allowed. Fagan’s careful inspections were too tedious; our casual alternative was too shallow. We never quite found the middle ground.

What Changed: Augmented Development

Now I’m working on a beach with a genie. The economics of review don’t just strain—they break completely.

The genie produces code at a pace no human reviewer can match. Coding isn’t the bottleneck anymore. I can explore three different implementations before lunch. I can refactor aggressively because the cost of trying something is so low.

Who has time to review all this?

Not my former colleagues—they have their own work. Not me in a reviewer role—I’m already the author. The traditional code review model assumes a resource that doesn’t exist in my current situation: another human with context and available attention.

But Maybe Review Matters More Now?

Here’s what’s interesting. As I’ve worked this way, I’ve noticed two purposes for review that actually make sense:

1. Sanity check—does this change do what I intended?

When you’re generating code fast, it’s easy to lose track of what you asked for versus what you got. The AI is helpful and confident. It produces things that look right. But “looks right” and “is right” aren’t the same.

I need something that says: “You asked for X. This code does Y. Are you sure?”

2. Structural drift—is the codebase staying manipulable?

This one is newly important.

When I’m working with a genie, the code needs to stay in a form the genie can understand & modify. For that to be true, it needs to stay in a form I can understand & modify. If the structure gets too tangled, if the coupling gets too tight, the genie starts making mistakes. It loses context. It suggests changes that break things in ways it can’t see.

I’m not just maintaining the code for future human me. I’m maintaining it for future augmented me. The codebase is a shared resource between human and genie, and it needs to stay healthy for both of us.

Structural integrity isn’t just about my future reading pleasure. It’s about whether my tools can keep helping me.

How I’ve Been Using CodeRabbit

I’ve been experimenting with CodeRabbit (this quarter’s Tidy First? sponsor—thanks folks!) for a few weeks now. Early days. Still learning.

Two features align with what I actually need right now. First, the summaries and architectural diagrams—when I’m generating code fast, I lose track of what changed. Having something that says “here’s the shape of what you just did” is the sanity check I described earlier.

Second, and this is what I’m most curious about: CodeRabbit learns from feedback. You can train it on your codebase’s patterns. In theory, this means it could get better at flagging the structural drift I worry about—if I teach it what “healthy” looks like for this particular project. I’m still early in testing this, but it’s the feature and problem I am most curious about solving.

It’s not pairing. Pairing is a conversation with someone who pushes back, who has their own ideas, who brings experience I don’t have. CodeRabbit is more like... a very thorough checklist that can read code.

But pairing isn’t available on this beach. And “very thorough checklist that can read code” is better than nothing.

Where I’m At

I’d rather be pairing.

I miss the back-and-forth with another human who cares about the code. I miss being surprised by someone else’s solution. I miss the social pressure to explain my thinking out loud, which always makes the thinking better.

But I’m not pairing right now. I’m working solo, generating code fast, trying to maintain quality in a situation the old tools weren’t designed for.

Code review meant “another human looks at your code before it ships.” Maybe now it means “something helps you maintain awareness of what you’re building and whether the structure is staying healthy.”

That’s less satisfying. It’s also where I’m at.

The why shifted. I’m still figuring out what to do about it.