I automated almost my entire pipeline this year, and I'd fight you to keep it that way.
An agent writes the first draft of most changes now. A second agent reviews that diff — harder than I do at 5pm on a Friday, and it never gets bored on the four-hundredth one. Tests run themselves. Types, lint, a staging deploy, a smoke check against a real-ish database. By the time a change gets anywhere near me, five separate automated steps have already looked at it and said yes. It is genuinely better than the hand-cranked version I ran three years ago, and the typing was never the part I'll miss.
So one sprint I did the obvious last thing. I looked at a pull request with four green checks and a clean review already on it, and I thought: why is my hand still on the merge button? What exactly am I adding by clicking it myself that four automated yeses haven't already earned? So I gave the agents the last step too. Generate, review, test, stage, merge. Fully closed loop. For about nine days it felt like the future.
Then one of those merges locked a paying customer out of their own account at two in the morning, and I learned — expensively, in production, on a phone call — which single step in that pipeline I should never have handed over. It's not the one most people would guess. It's the one almost everybody automates first.
The change was a write path. It acknowledged the request — sent the "got it" back to the client — before it had actually persisted the row. If you've been doing this a while, your stomach just dropped, because you know this bug. It is clean. It is idiomatic. It is typed, tested, and it reads perfectly right up until the moment a retry hits at the wrong instant: the "got it" goes out, the save never lands, and the system is now confidently certain about something that never happened.
The author agent wrote it. The review agent read it and approved it — and I want to be fair to the review agent, because it's good: it caught two real things that sprint that I'd have missed. It just didn't catch this one, because this one doesn't look like a bug. It looks like finished work. The tests were green because the tests tested the happy path, which is exactly the path where this code is correct. Staging was fine because nobody retried a request at the wrong millisecond against staging. Five automated yeses, all technically honest, all looking at the diff and none of them looking at the two in the morning.
It auto-merged. It auto-deployed. And on an ordinary bad night a retry hit, the ack went out, the write didn't, and a real human who pays us money got locked out of their own account with nothing in the logs to prove they'd ever been there. I can still feel the phone call — not because the bug was exotic, but because there had been no moment, anywhere in that beautiful closed loop, where a person who would get that phone call looked at the thing and owned shipping it.
Here is the distinction it took a locked-out customer to teach me, and it's the whole article.
The first job is judging the code: is this correct, is it idiomatic, does it handle the edge case, is the naming sane. That is a skill. It's pattern-matching against a huge amount of prior code and a mental model of the system. And it is exactly the kind of skill that got cheap this year. A good review agent does it tirelessly, consistently, at 3am, on the four-hundredth diff, without the fatigue that makes a human senior wave through a Friday-afternoon PR. You should absolutely automate this. I did, and it was the right call.
The second job is owning the merge: accepting that this is going to real users now, and if it's wrong, that's on me. That is not a skill. There is no pattern to match. It's the act of a specific accountable party putting their name on an irreversible, outward-facing decision and absorbing the consequence if it goes bad.
For twenty years those two jobs were welded together, because the person reviewing the code was also the person who'd get paged, so we never had to notice they were different things. Automation ripped them apart. The machine can now do the first job better than I can. It cannot do the second one at all — not because it isn't smart enough, but because the second job isn't about intelligence. It's about accountability, and accountability requires something that can actually bear a consequence.
An agent that merges a bad diff and takes down prod cannot be paged. It can't be sorry. It can't carry the weight of that 2am call into how it makes the next decision, because it isn't making decisions it has a stake in — it's producing confident output at a scale no human can match and signing off in the same even voice whether the diff is a masterpiece or a time bomb. Infinite throughput, zero accountability. The merge is the one place in the whole pipeline where the buck is supposed to stop, and I'd handed it to the one participant that has no buck.
Now here's the part that should bother you, because once you see it you see it everywhere.
They keep a human on code review. "A person has to read every diff." They put mandatory human approvals on pull requests, they argue about review coverage, they feel safe because a human's eyes were on the lines. And then they wire up auto-merge on green and a continuous deploy to prod, and feel clever for it, because that part is just plumbing.
Code review is the reversible step. If a human misses something in review, nothing has happened yet. You can review it again. You can comment. You can catch it in staging. Nothing has crossed into the real world. It is the single most recoverable point in the entire pipeline — and it's the one we insist stays human, even though it's now the step the machine does better.
The merge to production is the irreversible, outward-facing step. It is the exact moment the change stops being a proposal and starts being something a customer can hit at 2am. It is the one point in the pipeline where a retry can lock someone out of their account. And it's the step we're the most comfortable handing to a robot, precisely because it looks like plumbing — a button, a webhook, a green check — rather than a decision.
We guard the cheap reversible step with a human and automate the expensive irreversible one. We kept our hand on the one place the machine made safe, and took it off the one place it couldn't.
There's a reason the merge button feels so automatable, and it's the same reason the "no" and the prevented outage always get undervalued: it produces nothing visible.