Ratchet: An AI Delivery Loop That Can Only Move Forward
Praveen Vijayan
SubscribeSign in
Ratchet: An AI Delivery Loop That Can Only Move Forward
Praveen Vijayan<br>Jun 14, 2026
Share
I spent most of the last decade shipping software inside banks. So when I started letting coding agents into real repositories, I didn’t reach for more autonomy. I reached for a brake. This is the workflow I built, why I built it the way I did, and where it fits.
A ratchet turns one way and locks against the other. That’s the whole idea.
The thing nobody likes to admit
Gartner thinks more than 40% of agentic AI projects will be scrapped before 2027 is out. If you’ve watched a slick “autonomous developer” demo and then turned the same tool loose on a codebase you actually care about, that number won’t shock you.<br>The demos really are good. An agent reads a ticket, writes the code, runs the tests, opens a pull request, all on its own. Then you point it at your own repo — the one with the payment flows, the audit trail, the service nobody fully remembers writing — and it does one of three things instead.<br>It drifts. You asked for one change and it quietly “improves” four others while it’s in there.<br>It stalls. A test goes red, the agent gets confused, and the work just sits there with nobody’s name on it.<br>Or, worst of all, it ships. Something lands on the main branch that no human ever properly read.<br>I’ve sat in enough release post-mortems to know that the third one is the career-ending one. In a bank, “an AI merged it and no one looked” is not a sentence you ever want to say out loud.<br>The industry’s reflex is to fix all this by making the agent smarter: a better planner, a bigger sandbox, more freedom to act. I went the other way. I decided the agent should be allowed to do less — and that the system around it should make going backwards physically impossible.<br>I called it Ratchet .
Why that name
A ratchet is the little toothed mechanism inside a socket wrench. It turns freely one way and locks hard against the other. You can tighten; you can’t accidentally loosen.<br>That’s the exact property I wanted. Work should only ever move toward shipped. And when something goes wrong — a test fails, a reviewer pushes back — the work doesn’t roll the whole machine backwards or disappear into limbo. It drops back into the queue, gets picked up, and gets pushed forward again.<br>Tighten, never loosen. Once you’ve felt a delivery process that can silently slip backwards, the appeal of one that can’t is hard to overstate.
How it works, without the jargon
Picture a conveyor belt with seven steps. Work travels along it, and every step can only hand the work forward. The agent runs the middle of the belt. GitHub handles the ends. A human owns the one gate that matters.<br>The agent picks the highest-priority unblocked task in the queue — and rework always jumps ahead of new work, because finishing beats starting.<br>It claims the task by creating its own branch off the latest code. Creating that branch is the claim, so two agents can never grab the same thing at once. No locks, no scheduler, no coordination service — just a branch name.<br>It builds , in small commits, sticking to the patterns already in the repo. If the task turns out to be bigger than it looked, it doesn’t barrel on. It stops, suggests a way to split it, and puts the pieces back in the queue.<br>It verifies by running your project’s own checks — formatting, types, tests, build. Two attempts to get them green. If it’s still red after that, the work goes back to the queue with a note saying why. Nothing broken ever leaves the bench, and red work never even reaches your CI.<br>Then it hands off : it opens a pull request and stops. That’s the end of the road for the agent.<br>If you ask for changes, it reworks the same pull request — re-runs the checks, answers your comments, points you at the commits that fixed each one. It never opens a second PR to dodge the conversation.<br>And when you merge, the system closes the loop : GitHub marks the task done, anything that was waiting on it becomes available, and any task an agent abandoned mid-flight gets swept back to the queue. The belt refills itself.<br>Underneath all of that, each step is just a plain GitHub label you can read at a glance — ready, in-progress, in-review, changes-requested, blocked. Nothing is hidden in a database somewhere. If you can open your own repo, you can see exactly where every piece of work stands.<br>There’s really only one rule that holds the whole thing together:<br>The merge is the human gate. No agent ever merges, approves, or closes anything. The pull request is the last thing it touches.
That single constraint is what lets me run this on a codebase that matters. The machine does all the dull forward motion — picking, claiming, coding, checking, opening the PR — but the decision to ship stays with a person turning the key.
What’s actually left for people to do
If the agents do the building, what’s the team for? Two things,...