Ask freely, ship deliberately: an architecture for human-in-the-loop AI product changes

Description and use

Butterneck’s architecture lets non‑developers request code changes that are automatically applied locally, instantly previewed, and only committed to production by a developer.

Problem

Non‑developers request code changes but lack the ability to review diffs, risking incorrect or unsafe deployments.

Outcome

Butterneck’s architecture keeps the developer as the sole gatekeeper to production while allowing non‑developers to request changes that are previewed instantly, reducing manual effort and preventing accidental deployments.

Workflow

• 1. Developer runs the bridge daemon and connects project folders.
• 2. Requester submits a change via chat widget or Jira ticket with a Butterneck label.
• 3. Bridge starts the coding CLI (Cursor, Claude Code, etc.) as a child process in the target folder.
• 4. Agent edits files locally; the dev server reloads and shows the preview to the requester.
• 5. Agent tags the change with a confidence level.
• 6. Developer reviews the preview, conversation, and edited files.
• 7. Developer commits and merges through the normal pipeline or discards the change.

Evidence

Coding agents can now change a real codebase from a sentence.

Source

The request happens next to the thing. The person asking should be looking at the running product, not describing it from memory.

Source

The preview is the running dev server. 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.

Source

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.

Source