Your Reviewers Don't Scale. Your Pipeline Does.

A follow-up to the last piece. If verification is the new bottleneck, the pipeline is the only part of it that keeps up.

Last time I wrote that AI made us much faster at producing code without making us any faster at reading it, and that the gap is where the debt lives.

The obvious response is "review harder." I don't think that works. Your team is the size it is, attention is finite, and telling people to be more careful has never once fixed a systems problem.

So here's the follow-up I actually believe: stop trying to scale the human part. Scale the machine part, and shrink what reaches the human until it's something they can genuinely do well.

The rule

Everything a machine can check should be checked before a person opens the diff.

That sounds obvious written down. Most teams don't do it. Reviewers are still manually noticing missing null checks, a dependency someone bumped, a secret that got committed, a test that was quietly skipped. Every one of those is a machine's job, and every one of them uses up attention that should have gone to the question a machine cannot answer.

What that looks like in a pipeline

The pipeline I keep building has the same shape whatever the stack is.

Build. Compiles, dependencies locked to exact versions. If a build isn't reproducible, nothing downstream of it means anything.

Tests. Unit, integration, end-to-end, running in parallel stages. The build stops here on failure — a red build never reaches an environment, and never reaches a reviewer either.

Scanners. Static analysis, secret detection, licence checks. In CI, not in a browser tab someone remembers to open on Thursdays. If a check depends on someone remembering, it isn't a check.

Dependencies. This one is newer and I've started treating it as non-negotiable. Verify every import actually resolves to a real, expected package. AI assistants suggest package names that have never existed, and attackers have started registering those names. It's a five-second automated check that closes an entire supply chain hole.

Only what survives all four gets a human.

The part that makes it worth the effort

Those gates run identically whether you're merging ten pull requests a day or a hundred.

That's the whole argument. Human review degrades under volume — quietly, without anyone deciding to let it. Automated gates don't. They're exactly as thorough on the ninetieth PR of the day as on the first, which is precisely the property you need when generation speeds up and headcount doesn't.

What's left for the human

This is the part I think gets undersold when people talk about automating review.

Once correctness is handled, the reviewer's job becomes the interesting one: is this the right approach? Does it fit how the rest of the system works? What happens at the edges nobody wrote a test for? Should we be building this at all?

That's judgement, and no pipeline does it. But it's also the work that gets squeezed out first when a reviewer is busy checking whether someone remembered to handle a null. You get better design review by giving people less to review, not by asking them for more.

The bit that changed how a team I worked with behaved

None of this lands without one more piece: a rollback that's a button, not a runbook.

We deployed blue/green, so the previous version stayed running and switching back was one click. That sounds like a minor operational nicety. It changed everything about how people behaved.

There was an unwritten rule about not deploying on Fridays. That rule is a symptom — what it actually says is "we don't trust the process and we don't have a fast way back." Once going back was cheap, going forward stopped being frightening. The Friday rule died within a couple of weeks and nobody had to argue about it.

If you're starting from nothing

Order matters more than tooling here, and most teams get it backwards.

Get the build reproducible first. Then get the tests trustworthy — a test suite people don't believe is worse than none, because it teaches them to ignore red. Then automate the deploy. Then add the gates.

Teams that automate deployment before their tests are reliable have just built a faster way to ship bugs. That's not a hypothetical; I've watched it happen.

Where this ends up

The uncomfortable truth in my last piece was that the hard part of software moved from writing to verifying. This is the practical follow-up: most of verification is mechanical, and the mechanical part is the only part that scales with the volume we're now generating.

Automate everything a machine can decide. Protect the human attention for the things it can't.

And make going backwards cheap, because that's what makes going forwards fast.

What's in your pipeline that used to be a review comment? I'd like to know which checks people have automated away — and which ones they've tried to and regretted.