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.
Here's what shipped itself.
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.
We use one word, "review," for two completely different jobs.
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. You can automate judgment. You cannot automate accountability.
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.
Watch what teams instinctively keep manual versus what they happily automate.
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.
That is exactly backwards.
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.
A merge that goes fine is invisible. Nothing happens. No artifact, no graph that goes up, no line of code with your name on it — the author agent wrote the code, the review agent found the bugs, and all you did was click a button that four green checks already justified. It looks like the most deletable job in the building.
A merge that goes bad is a countable event with a name on it: an incident, a postmortem, a locked-out customer, a phone call. So the person on the merge button is sitting in a pure-downside seat — all of the blame when it breaks, none of the credit when it doesn't. By every productivity metric you could point at, that person is doing nothing. Which is exactly why the job can't be automated away: the thing they're actually providing isn't throughput, it's a place for the consequence to land. You don't keep a human on the merge because they're faster or because they read the diff better than the agent did. You keep them there because when it goes wrong at 2am, "the pipeline did it" is not an answer you can give a customer, a regulator, or yourself.
The lazy version of this piece is "see, you always need a human watching the AI," and that's the cope that kills teams, so let me kill it first.
Keeping a human on every step is theater. A human babysitting every generated diff, re-reading what the review agent already read, approving what the tests already proved — that's not safety, it's a slow person pretending to add value by being in the way. The machine reads diffs better than a tired senior now; making a human rubber-stamp each one just launders the robot's judgment through someone who's no longer actually looking. I automated the generation. I automated the review, and then I made the review harder than I used to, because the agent doesn't get tired of being thorough. I'd never go back. Output is table stakes and judgment-on-the-code is now something you can buy by the thousand.
The claim is narrow, and I think it's hard to argue with once the two jobs come apart: exactly one step in the pipeline has to stay human, and it's the merge — not because the human does it better, but because the human is the only participant who can be held to it. Everything upstream of that button is a skill, and skills got cheap. The button itself isn't a skill. It's a signature.
I didn't rip out the automation. I re-pointed the human at the one seat that needed one:
One level down, this is the entire architecture of the agent platform I work on, and now you know why.
There's an author — the thing that generates the diff. Cheap, fast, endless, the abundant thing. Automate it all the way.
There's a separate skeptic — whose only job is to try to break what the author made, not admire it. The "no," given its own seat, tireless where a human reviewer gets tired. Automate this too, and make it mean, because the machine is better at being consistently skeptical than a person at 5pm.
And there's a human on the merge. Not reviewing the lines — the skeptic did that harder than the human could. Owning the call. Seeing the blast radius. Being the place the consequence lands when a retry hits at 2am. The author has infinite throughput and I let it run. The skeptic has infinite patience and I let it run. The human has neither — and is the only one of the three who can be held to the outcome. That's the one seat I will never automate again.
That's the shape of xenition, and it's also what it does for you: you describe what you want in one chat — a doc, a tracker, a whole working app — and it builds the thing, runs the skeptic over it, and then stops for your approval before anything goes live. The two cheap jobs run themselves; you keep the one click that can't be undone. Automate the skills, keep a human on the signature.
I closed the loop all the way once. It cost a customer their account at 2am and me a phone call I can still hear. The lesson wasn't "don't trust the agents" — I trust them more than ever to write and to check. It was that there's exactly one button in the pipeline that was never a skill in the first place, and it's the one I was most eager to automate because it looked like the easiest.