Originally published on butterneck.com. Coding assistants can now edit a real project. Give Cursor, Claude Code, or Antigravity a clear request and a folder, and it will usually find the right file and make the change.
So the obvious next step is to let it go all the way: take the request, change the code, open the pull request, merge it, ship it. Some tools do that.
Butterneck doesn't. It lets the product team hand requests to the AI directly, and then it stops. It never merges. It never opens a pull request. It never deploys. A developer looks at the result and decides whether it goes live.
This post explains why.
Why Butterneck never merges, in short: Butterneck lets a product manager or another stakeholder ask an AI coding agent for a change, and the agent edits the project on the developer's computer with the CLI they already use (Cursor, Claude Code or Antigravity), but Butterneck never opens a pull request, merges or deploys. The person who asked checks the result on a live preview, and a developer, who checks the code the requester can't review, decides first what ships through the team's existing release process.
Human-in-the-loop for coding agents means an AI coding agent can propose and make changes, but a person approves the steps that matter before anything reaches users. The agent does the work; a human holds the decision points: the plan, risky actions, the result, and the release.
A coding agent's work has four places where a person can step in:
Butterneck puts the human at two of them. The person who asked (the requester) checks the change at the preview, on a live copy of the app. A developer decides at ship, and publishes it the usual way or leaves it. Butterneck itself never merges, opens a pull request, or deploys.
Most human-in-the-loop setups for coding agents put every gate in the developer's workflow: approving the plan, the commands, the diff, the merge. Those gates matter, but the person who asked for the change usually can't use them. Butterneck adds a gate they can use: they look at the result on a live copy of the app and say whether it's what they meant, before a developer spends time on the code.
"Human in the loop" gets used for a lot of things. In Butterneck it means one specific thing:
The AI can change files in the project you connected. Only a person on your team can make that change live.
Everything else follows from that line.
butterneck and assigned to a teammate whose Jira account is mapped to a computer that has the project starts the chat.
The case for full automation assumes the slow part is writing the code. For most small product changes, it isn't.
Take a request like "make the button say Book a call". The edit is one line. The week goes on the messages around it:
Or a Jira ticket with a description, twelve comments, a spreadsheet, and three screenshots. A developer reads all of it to work out which comment is the real request before anyone opens the project.
Butterneck goes after that part. The request is made on the live app, next to the thing it is about, or it comes straight from the ticket, files included. The AI does the reading and the edit. That is the time saved.
The last step, deciding whether the change ships, takes a minute. Automating it saves very little and removes the one check that matters.
Butterneck is built so that a product manager, a support lead, or another stakeholder can ask for a change. That is the point. But it also means the request comes from someone who can't review a diff.
If the tool merged on its own, a non-developer's sentence would become production code with no developer ever looking at it. Nobody on a product team actually wants that, even when the AI gets it right most of the time. The product manager checks that the button now says the right thing. The developer checks the things nobody asked about: did the change touch a shared component, did it break the mobile layout, is the copy now out of sync with the email template.
Both checks are needed. Butterneck puts the first one on a live preview before the pull request, where the person asking can see it, and leaves the second one with the developer.
Most teams already have a way to ship: a branch policy, CI, a review rule, a deploy step. A tool that merges for you has to either copy that process or go around it.
Butterneck does neither. The change sits in the project on the developer's computer. They commit, push, open a pull request, or run their deploy, the same way as any other change. Nothing about your pipeline changes.
When the AI gets it wrong, and sometimes it will, the wrong change is not published; the files were edited on the connected computer. It doesn't land on a shared branch, it doesn't trigger a deploy, and nobody has to revert anything in public. You can stop a turn while it is running and roll back the file changes from that turn. If the rollback can't be completed, for example because a changed file was too large to snapshot, the chat says so.
For the folder, ignore-list and undo details, see how Butterneck runs the coding agent in a sandbox on your machine. Leaving the merge to a person is the main safeguard. There are a few more, all on the developer's side:
.env rule, that's a guardrail, not an operating-system sandbox.
Putting a person in the loop doesn't guarantee that person decides. In a study published on 27 October 2026, Anthropic asked 50 professional analysts to do a realistic statistical analysis with Claude Code. A coin flip secretly set which option the agent leaned towards on each choice, and across four analytical choices the analysts went with the agent's lean 86% of the time (Anthropic). It's a study of data analysts, not code reviewers, but the lesson carries: a summary from the agent is an easy thing to agree with.
So in Butterneck the check isn't the agent's account of what it did. The person who asked looks at the change themselves on a live preview of the running app, and the developer reads the diff in their own editor before anything is committed or becomes a pull request. Both are checking the actual result, not the AI's description of it.
Code review shows the same drift. A June 2026 preprint followed 400 repeat reviewers across 11,429 reviews of AI-agent pull requests in open-source projects over seven months. As they reviewed more, their approval rate rose from 30.1% to 36.8% and their inline comments fell 22% (arXiv 2606.22721). The authors read this as habituation, though they say the agents' code may also have improved over that time. A requester checking the running app is one more check that doesn't depend on a tired reviewer.
For the one step at the end, yes, by a minute or two. For the whole request, no. Compare the two flows for "make the button say Book a call":
The usual way
With Butterneck
The developer's time goes from "find, change, send, wait" to "look and decide". That is the trade we care about.
See it before you set anything up: create a free account and try a request on a sample shop before connecting a computer. On your own project, the edit runs on your computer. Your team still decides what goes live.
It fits teams where:
It is not a fit if:
Butterneck does not ship its own model. It uses the coding assistant the developer already has signed in on their computer: Cursor, Claude Code, or Antigravity. The computer needs Node.js 22 or newer. The developer installs a small connector, points it at the project, and starts the app. Everyone else opens the live copy.
If you want the details of the sharing side, read [Share your local app with stakeholders without deploying it](https://www.butterneck.com/blog/share-local-app-without-deploying).
For the architecture behind this, layer by layer, read [Ask freely, ship deliberately: an architecture for human-in-the-loop AI product changes](https://www.butterneck.com/blog/human-in-the-loop-architecture-for-ai-product-changes).
Why ownership matters for AI-written changes, with LinearB's 2026 data on AI PR merge rates and pickup times: [AI pull requests need an owner](https://www.butterneck.com/blog/ai-prs-need-an-owner).
An AI coding agent proposes and makes changes, and a person approves the steps that matter (the plan, risky actions, the result, the release) before anything reaches users.
At two points. The person who asked checks the change on a live preview of the running app. A developer decides whether it ships, and ships it the team's usual way.
No. It never opens a pull request, never merges and never deploys. The AI edits files in the connected project on a developer's computer; the developer decides whether to commit, open a PR, or throw the change away.
For most product changes, no. Since 28 October 2026, GitHub's Agent Merge can watch a pull request, fix failing checks and merge conflicts, and, combined with auto-merge, let GitHub merge it as soon as all requirements are met. That works when a person has already decided the change is wanted and branch protection requires a human review. Butterneck puts that decision earlier: the person who asked checks the change on a live preview, and a developer decides whether it becomes a commit or a pull request at all. Butterneck itself never merges. Many cloud coding agents stop at a pull request and leave the merge to a reviewer and your branch rules. Butterneck stops earlier. It never opens a pull request, merges or deploys. The AI edits the project on the developer's computer, the person who asked checks the result on a live preview, and the developer decides whether it becomes a commit or a pull request at all.
A merge gate stops an agent's pull request at the end. Anthropic's Agent Approval Check, for example, is a GitHub Action that requires a set number of human approvals on any pull request with commits authored by an AI agent. Gates like that work in the developer's workflow, once the code is already a pull request. Butterneck adds a check before that, for the person who asked: they look at the change on a live preview, then a developer decides whether it becomes a commit or a pull request at all. If the developer does open a pull request, your existing merge gates and branch rules still apply.
They can confirm it looks right on the preview, but they can't ship it. Only a developer on your team can make the change live.
Starter is free for one developer and one person who asks for changes. Pro is USD 19 per person per month, with 20% off annual billing. See pricing, or the FAQ for who publishes and where file changes happen. A workspace owner on Starter can also try Pro free for one month.
Let them ask. You decide what goes live.