Menschliche Kontrolle: Architektur fuer KI-Aenderungen im Loop
Coding-Agents koennen Codebasen inzwischen auf Satzwechsel veraendern, doch der direkte Weg bis zur Produktion ist laut dem Beitrag der falsche Default, wenn Auftraggeber den Diff nicht selbst pruefen koennen.

Posted on Oct 27 • Originally published at butterneck.com
Coding agents can now change a real codebase from a sentence. The industry's next move looks obvious: let the request go all the way to production. Ticket in, pull request out, merge, deploy.
I think that is the wrong default for changes requested by people who can't read the diff. Not because the models are bad. Because the slow part of a small product change was never the typing, and the last step, a person deciding, is cheap and worth keeping.
This piece lays out the argument and then the concrete architecture we use in Butterneck to keep a human in the loop without making them the bottleneck.
Take "make the button say Book a call". The edit is one line. The time goes to everything around it: which page, which button, a screenshot, someone finds the file, someone sends a link to check, a reply, another tweak.
Or a ticket with a description, a dozen comments and three attachments, where a developer has to work out which comment is the real request.
Agents are good at exactly this: reading context and making the edit. Automating the decision to ship saves maybe a minute. It also removes the one check that catches a wrong change before customers do.
If you want non-developers to ask an agent for changes, I'd argue the system needs three things.
None of these need new AI. They are plumbing decisions.
Here is how Butterneck implements those three properties. I'll keep it concrete.
A daemon (the bridge) runs on a developer's machine. The developer connects one or more project folders. Each folder can be the main checkout, a fresh clone, or a git worktree under.worktrees/ so several requests can run without touching the working copy.
When a request arrives, the bridge's chat server starts the coding CLI the developer already uses, Cursor, Claude Code, or Antigravity, as a one-shot child process scoped to that folder. Butterneck does not ship a model. The developer's existing agent and its provider terms apply.
Why local? The project already runs there, with its real dependencies, data and dev server. No cloud environment to keep in sync.
Developer replies in the thread don't trigger the agent, so the developer can talk to the requester without kicking off another edit.
The bridge starts the app and the server issues a public share URL that relays traffic over the bridge's WebSocket, including hot-reload sockets. When the agent saves a file, the dev server reloads and the requester sees it.
That gives you property 2 with no deploy step. It also means the agent is told never to run a production build mid-turn; the dev server is the preview.
An honest note on layer one and two: they are instructions to the agent plus the CLI's workspace setting, and the CLIs run with their interactive permission prompts skipped. That is not the same as an OS sandbox. If you need hard isolation, run the bridge on a machine or account that has no production secrets. We'd rather say that plainly than overclaim.
There is no push, no pull request, no merge and no deploy in the bridge or chat server. The output of a turn is edited files in a folder plus a conversation and a live preview.
The developer reviews all three, then commits and ships through the team's normal pipeline, with its tests, CI and code review intact. Or discards it.
The developer's job changes from "find, edit, send link, wait, repeat" to "look, decide". That's the trade. The expensive loop moves to the agent and the requester, who iterate on the preview until it's right. The developer sees it once, at the end.
Teams that want ticket-to-merge automation exist, and there are tools for them. This design is for teams where the person asking can't review code and someone still owns what ships.
Human-in-the-loop is often treated as a temporary crutch until the models get better. I think for product changes it's a permanent design choice: ask freely, preview instantly, ship deliberately.
If that's how you want your team to work with coding agents, Butterneck has a free Starter plan at butterneck.com.