Everyone talks about AI writing code. Nobody talks about the bit where you become the human "continue" button, pressing away, wondering when exactly this became your job.
So I built Loopify. I'm not breaking any new ground here, you'll see and hear from influencers talking about /goal or /loop but I wanted something a little different. It's a small kit that turns Claude Code from something you babysit into something closer to a vending machine. A one line feature request goes in. A finished, tested, independently reviewed pull request comes out. My total involvement per feature is about thirty seconds at the start, one merge at the end, and a Kanban board I check when it suits me.
The name isn't clever. loopify is literally the one word command that installs it into a project.
"Done" is a contract, not a feeling.
The reason AI coding sessions drift is that "done" is usually a vibe. The model feels finished, declares victory, and you find out the tests don't pass and half the feature is a comment saying // TODO.
The fix is embarrassingly old fashioned. Before anything gets built, a spec gets written, and every item on its Definition of Done has to be a command that either passes or fails. Not "code looks good". Nothing subjective survives contact with the spec stage.
Three commands. Each one passes or it doesn't. There's nowhere for "I think that's finished" to hide.
That contract is what everything else hangs off.
Meet the team. There are four of them and they're all Claude.
The team is basically a tiny delivery pod living in a folder. Each one is a set of instructions Claude loads on command, and between them they cover the whole life of a feature.
The BA
Takes my one line request and writes the brief. What's being built, what it assumed on my behalf, what's out of scope, and that machine checkable Definition of Done. Then it stops and shows me.
The developer
Works the task list in order, test first. Failing test, code until green, full suite plus lint and typecheck, tick the box, move on. If it gets properly stuck it writes up why and stops cleanly rather than thrashing about.
The QA
A completely separate AI with a fresh memory and read only access. It didn't write the code so it has no ego about it. It re-runs every check itself and issues a verdict. Three rounds max, so they can't argue forever.
The release manager
Won't run unless the review passed. Squashes everything into one clean commit and opens a pull request. Forbidden from merging. That's mine, always.
The QA is my favourite bit. It doesn't take the developer's word for anything, it re-runs the lot. Fixes go back on the task list as new tasks. On the feature I use as a demo, the reviewer caught that search matched the name but not the email address, which the spec had asked for. The developer had ticked its own box and moved on. The reviewer sent it back.
The two bouncers.
None of that works on politeness. It works because of two boring little scripts, hooks, that fire at fixed moments and can't be talked out of anything.
The first is a bouncer on the exit door. Every time Claude tries to say "done", the script checks the task list. Unticked boxes? Back inside you go, with a note saying which task is still open. All ticked but not reviewed? Go and get reviewed first. This single dumb script is the entire secret of the loop, because the AI physically cannot down tools early.
The second is a bouncer on the danger door. Force pushes, pushing straight to main, rm -rf disasters, hard resets, Claude merging its own pull request. All hard blocked by deterministic code before the command ever runs.
I think that's the actual lesson here, and not just for development. Anywhere you're handing work to something that occasionally makes things up, the guardrails need to be made of something firmer than good intentions.
The Kanban twist.
Here's the part I'm most pleased with.
The one thing that used to drag me back to the keyboard was the AI needing a decision. Not a technical detail, a genuine judgement call where two reasonable people could disagree. In the old world the session just stalls until I show up.
Now it writes the question as a card on a Kanban board in my Obsidian vault. Context, options, and its own recommendation. It parks only the work that question affects and carries on with everything else. I sweep the board when it suits me, morning coffee or end of day. I type my answer onto the card, drag it to "Decided", and the next build run picks it up, acts on it, and files the card as applied with a note of what changed.
And the release manager won't ship anything with undecided cards outstanding, so I can't accidentally merge around my own homework.
It's a stand up I attend on my own schedule. The loop never waits for me, I catch up with it.
What it actually feels like.
A feature now goes like this. Type /spec. Skim the assumptions, because that's where the wrong turns hide. Type /build. Go and walk the dogs.
One request, "add rate limiting", travelling the whole way through. The spotlight is wherever the work is. You only step in at the two You stations.
Come back to either a reviewed feature ready to ship, or a couple of cards on the board and a clear note about what's parked. Read the pull request over a coffee. Merge.
The first feature in any project should be small and boring, something you don't yet get to touch or play with. Sometimes it gets stuck and tells you so, which is the good failure mode. And an empty decision board doesn't mean it's broken. The skills are told not to bother me with routine technical choices, so silence usually means nothing needed me.
Why I think this is the shape of it.
What everyone reaches for is that AI will replace developers. I think the truer and less shouty version is that AI development is becoming a management problem, and most of us are still doing it as an operator problem.
Single shot prompting treats the model like a very confident autocomplete. What actually works is what works with any capable team. A clear contract. Verification gates it can't skip. An independent reviewer. Guardrails written in something firmer than good intentions. And a human who holds the decisions and the merge button, and nothing else.
The best code review I do now is often in the cooler evenings, wearing headphones, listening to some Armin Van Buuren and walking Mabel and Max (my two dogs) after a busy day doing my day job.
Loopify, a self-driving delivery loop for Claude Code.
A spec skill, a build skill, an independent reviewer and a release manager, plus two hooks that make the rules real. It lives in a folder in your repo. You approve the spec and you press merge.