DEV Community: Butterneck

AI pull requests need an owner: what LinearB's 2026 data says about the AI code review bottleneck

Butterneck — Tue, 27 Oct 2026 18:38:41 +0000

Originally published on butterneck.com.

AI coding agents can now open pull requests faster than teams can review them. Plenty of engineering leads have said this for a while. LinearB's 2026 Software Engineering Benchmarks Report now puts numbers on it, and the report's own explanation is not "the code is bad". It is that nobody owns the PR.

This post goes through what the report found, what it does and doesn't show, and one practical response: make sure every AI-written change has a human owner before it reaches review. We build Butterneck, so we say how it fits near the end. The idea applies whatever tools you use.

Update, 28 October 2026: On 26 October, Entire, the company led by former GitHub CEO Thomas Dohmke, launched Trails, a replacement for the pull request built around the same review bottleneck. Its answer runs the other way from ours: agents generate evals on every push, so line-by-line human review becomes optional, while repositories can still require human approvals and other checks through Gates. Butterneck moves the human decision earlier instead: the person who asked sees the change on a live preview, and a developer decides before any PR exists.

What LinearB measured

The 2026 Software Engineering Benchmarks Report covers 8,109,244 pull requests from 4,813 teams and 163,820 active contributors. Most of its benchmarks are aggregated at the 75th percentile (P75). This year it splits PRs into three types: Agentic AI PRs, AI-Assisted PRs, and Unassisted PRs.

Two findings stand out for anyone thinking about the AI code review bottleneck.

AI PRs merge far less often. The report's new Acceptance Rate benchmark is the share of PRs merged within 30 days of being created (or moved out of draft). Manual PRs merged at 84.4%. AI PRs merged at 32.7%.

Agentic AI PRs wait much longer to be picked up. At P75, Agentic AI PRs sat for 1,055 minutes (about 17.6 hours) before a reviewer opened them. For Unassisted PRs it was 201 minutes (about 3.4 hours). The report calls that a pickup time "5.3x longer". Once review starts, the gap mostly closes. The report says the review itself is "only somewhat slower".

So the problem isn't mainly that reviews of AI code drag on. It's that AI PRs sit unopened, and most of them never merge.

"A natural human owner"

LinearB gives several reasons for the gap. AI PRs tend to be larger. Agentic flows are often pointed at low-priority backlog work. Reviewers are more hesitant. The reason that interested us most is ownership:

"Some of this gap likely stems from unclear ownership: the AI PRs don't typically have a natural human owner whose goal is to get them approved and merged. Without this push, they tend to get ignored and left to rot."

On pickup time, the report also says "there is often no clear owner for the PR who will push to finalize the review and get the PR accepted."

That matches how review works in practice. A PR from a teammate comes with a person who answers questions, nudges the reviewer, fixes the nit and gets it over the line. A PR opened by a bot comes with nobody. Reviewers can tell, and it goes to the bottom of the pile.

Correlation, not causation

LinearB is careful here, and so should we be. The report says plainly that correlation does not indicate causation, and its benchmarks page asks anyone citing the data to "Frame every AI finding as correlation rather than causation."

So the data does not prove that missing ownership causes low merge rates. Size, task priority and reviewer trust all play a part, and the report names each one. What the data does show is a large, consistent gap between AI and manual PRs, and LinearB's own reading that unclear ownership is likely part of it.

That's enough to act on, as long as nobody promises a number.

Other data on the AI PR review bottleneck

LinearB isn't the only source pointing at review and merge rather than writing. Two independent data sets, measured in different ways, show a similar shape.

CircleCI: more work on branches, less reaching main. CircleCI's 2026 State of Software Delivery report analysed more than 28 million CI/CD workflows. For the median team, feature-branch throughput rose 15% year over year, while throughput on the main branch fell 7%. CircleCI's reading: "Writing code is no longer the constraint. Review, validation, integration, recovery." This is pipeline data, not PR authorship, so it doesn't separate AI-written changes from human ones.

MSR 2026 study: AI-only review merges less often. A study presented at MSR 2026 (Chowdhury, Banik, Ferdous and Shamim) looked at 3,109 pull requests from the AIDev dataset of agent-authored PRs on GitHub. Among PRs whose reviews only left comments, without an approval or a change request, those reviewed only by code review agents merged 45.20% of the time (127 of 281). Those reviewed only by humans merged 68.37% (804 of 1,176). The agent-only group was also closed unmerged more often: 34.88% against 21.60%.

Both come with the same caveat as LinearB. The study's authors note that correlation does not imply causation, and their data comes from open-source repositories. CircleCI's numbers describe pipelines, not who wrote the code. Read together, they point the same way: the slow part is getting a change reviewed, trusted and merged, not writing it. None of them measured Butterneck.

What "giving AI PRs an owner" can look like

You don't need a new tool to start. Some options teams use:

Assign a human at creation. Every agent-opened PR gets a named owner who is expected to drive it to merge or close it.
Keep AI changes small. The report links AI PRs to larger diffs. Small, scoped requests are easier to own and easier to review.
Close what nobody wants. An AI PR with no one pushing for it is a signal. Close it rather than let it rot.
Agree on what AI should be asked for. We wrote a policy template for AI change requests that says who can ask, for what, and who decides what ships.

How Butterneck handles ownership

Butterneck takes a different route: there is no bot PR to own.

A PM, designer or support lead asks for a change on a live preview of the app, or labels a Jira ticket butterneck and assigns it to a developer whose computer has the project. A coding agent the developer already uses (Cursor, Claude Code or Antigravity) runs on that developer's computer and edits the connected folder. A preview link comes back on the ticket, and the requester can keep refining the change in plain words. See the Jira integration for the full flow.

Butterneck never opens a pull request, never merges and never deploys. The developer who checked the preview commits the change as their own work and ships it through the team's normal process. So the change has an owner from the start: a named developer who has already looked at it.

To be clear about what we are and aren't claiming:

We have no data showing that Butterneck changes merge rates or pickup times, and we're not claiming it does.
The code is still AI-written. The developer still has to review it properly. Ownership doesn't replace review.
What changes is who is on the hook. It's a person on your team, not a bot account.

The reasoning behind keeping a human at the end is in why Butterneck never merges. If PMs are the ones asking, should product managers ship code? covers the review-load side.

Why a connected computer instead of a cloud sandbox

Many AI coding tools run each task in a cloud sandbox. Butterneck runs the agent on a developer's computer that is connected to your workspace. Both are reasonable choices. Here's the trade-off as we see it.

What you get:

No environment setup per ticket. There's no base image, service list or secrets store to configure for each task. The project already runs on that computer.
The real dev setup. The agent works with the same dependencies, local data and dev server the developer uses every day, and the preview is that running app.
The coding agent that's already signed in. Butterneck doesn't ship its own model. It uses the Cursor, Claude Code or Antigravity CLI your team already pays for (team or API plans recommended), under that tool's own provider terms.

What it costs:

The computer has to be on. If the connected computer is off or asleep, requests wait and the preview link doesn't load. A cloud sandbox doesn't have that problem.
.env handling is a guardrail, not a hard block. .env files and any paths you add are on an ignore list the agent is told to stay out of. That's an instruction to the agent, not an operating-system lock, so keep production secrets off that computer.
Code still goes to your AI provider. The coding CLI sends code context to its provider, the same as when the developer uses it directly. Chat messages and preview traffic go through Butterneck's server so the share link works.

More detail in how Butterneck runs an AI coding agent in a sandbox on your machine.

FAQ

Why do AI pull requests take longer to review?

In LinearB's 2026 data, most of the delay is before review starts. At P75, Agentic AI PRs waited about 17.6 hours to be picked up against about 3.4 hours for Unassisted PRs, while the review itself was only somewhat slower. The report links this to larger diffs, reviewer hesitation and unclear ownership, and it frames these findings as correlation, not causation.

What is the AI PR merge rate in LinearB's benchmarks?

LinearB measures Acceptance Rate as the share of PRs merged within 30 days. In the 2026 report, manual PRs merged at 84.4% and AI PRs at 32.7%.

Does Butterneck improve merge rates or pickup time?

We don't have data on that and don't claim it. What Butterneck changes is ownership. It never opens a PR. The developer who checked the preview commits the change as their own work, so the change has a human owner from the start.

Does Butterneck open pull requests?

No. Butterneck never opens pull requests, never merges and never deploys. The AI edits files in the connected folder. The developer decides whether to commit, open a PR, or throw the change away.

Why does Butterneck use a connected computer instead of a cloud sandbox?

So there's no environment to set up per ticket, and the agent uses the developer's real dev setup and already-signed-in coding CLI. The trade-off is that the computer has to be on, and .env handling is a guardrail, not a hard block.

Try it

Starter is free for one developer and one requester. Pro is $19 per person per month. See pricing, or book a 30-minute demo and bring a small change that has been waiting on review.

Source: LinearB, 2026 Software Engineering Benchmarks Report (PDF) and benchmarks page, read on 27 Oct 2026. Figures are as published by LinearB. CircleCI, 5 key takeaways from the 2026 State of Software Delivery, and Chowdhury et al., From Industry Claims to Empirical Reality: An Empirical Study of Code Review Agents in Pull Requests (MSR 2026), both read on 28 Oct 2026.

Should product managers ship code? A better middle ground

Butterneck — Tue, 27 Oct 2026 15:40:22 +0000

Originally published on butterneck.com.

AI coding tools have made a new question very real: should product managers ship code? Some teams are already trying it. Others are watching nervously. And engineers are asking who will review all of it.

This post looks at what the current debate is actually about, what recent data says about the review side, and a middle ground that gets PMs their small changes without handing them commit access.

The debate, in plain terms

Guy Mor at H&B described on LinkedIn how his team is starting to let PMs use tools like Codex to make small changes to production systems. Their flow is careful: the PM identifies a simple change, uses AI to create a technical plan, an engineer reviews the plan, the PM uses AI to implement it, an engineer reviews the merge request, and then it goes to production.

He is honest that it is not simple. Two questions stood out:

What exactly is a "simple change"? A PM may see a small UI tweak. An engineer may know it touches three other things.
Are engineers being freed up, or turned into "people who review an endless stream of AI-generated merge requests"?

Jeff Gothelf comes at it from the other side in How to manage the inevitable mess of running a company where everyone is a builder. His first suggestion: "Keep the right to build separate from the right to ship." Anyone can build and show a prototype. Getting it in front of customers follows a path with evidence at each step.

Both pieces land in a similar place. Building is getting cheap. Deciding what ships is still the hard, valuable part.

What the data says about review

The engineers' worry has numbers behind it now. A Harvard study by Fiona Chen and James Stratton ("Artificial Intelligence in the Firm: Bottlenecks in Software Production", version of 4 Aug 2026) looked at 718 firms using data from the Jellyfish platform; InfoQ covered it on 22 Oct. According to the paper:

AI agents increased lines of code by 30%, commits by 20% and pull requests by 23%.
Jira issues resolved per worker showed no statistically significant change with agents; the paper's estimates rule out an increase larger than 12%.
Average PR time to review went up 49%, review comments per PR rose 35%, and the share of PRs with changes requested nearly doubled.

The authors' explanation is that writing code is only part of the job. Engineers spend 30â€“40% of their time writing code; the rest is planning, review, testing and deployment. Speed up the writing and the other steps become the bottleneck.

So if PMs start producing merge requests on top of what AI agents already produce, the review queue is where it will hurt. That is the AI code review bottleneck in one sentence.

Why "PMs opening PRs" is the wrong unit

When a PM asks for a small product change, they rarely care about the code. They care that the button says the right thing, the empty state is useful, or the form stops asking for a field nobody needs.

Turning that into a PM-authored pull request adds work in the wrong places:

The PM needs a dev setup, git, and enough context to not break things they cannot see.
The engineer still has to review the code, and now also has to check whether it matches what the PM meant.
The "is this what you meant?" loop happens inside code review, which is the slowest and most expensive place for it.

Gergely Orosz makes a related point in What is happening with code reviews?: automated tests are great at verifying business logic, but "they don't do a good job at verifying whether a UI looks and feels good." The small changes PMs ask for are mostly in that look-and-feel category. The best person to check them is the person who asked, looking at the running app.

The middle ground: ask on a live preview, ship through engineering

Here is the split we think works for small, visible changes:

The PM asks, in plain words, on a live copy of the app. Not a mockup. The real app, running from the real code.
A coding agent makes the edit. The PM sees the result on the same screen and keeps going ("a bit shorter", "the other button") until it is right.
An engineer decides what ships. They read the conversation, check the diff in their own tools, and publish it the usual way. Or they discard it.

This separates asking from shipping, which is Gothelf's build-versus-ship idea applied to everyday product tweaks. The PM never needs commit access, an IDE, or a merge request. Engineering keeps every release decision.

It also changes what lands on the engineer's desk. Instead of a ticket plus three screenshots, or a PM's pull request of unknown intent, they get a change the requester has already seen working, with the full conversation attached. We cannot promise that makes review faster, and we have no data on it. But the intent question has been answered before the review starts.

Where to draw the line

The H&B question, "where do you draw the line?", deserves a direct answer. A reasonable starting line:

Good for PM requests: copy, labels, layout, spacing, empty states, small UI fixes.
Needs an engineer from the start: pricing logic, permissions, data models, anything touching auth or payments. A preview can look right and still be wrong.
Not a chat request at all: big features. Those need design and scoping first.

Agree the list with your engineering lead before anyone starts. It is much easier than arguing about each request later.

How Butterneck does this

Butterneck is one way to set up the middle ground. A developer connects a project folder on their own computer. The app gets a share link to a private live copy. A PM or other stakeholder opens the link and types the change in a chat beside the app. Or they label a Jira ticket butterneck and assign it, and a preview link is posted back on the ticket.

The developer's own coding agent (Cursor, Claude Code or Antigravity) edits the project locally on their machine. The developer reviews and publishes the usual way. Butterneck never merges, never opens a pull request and never deploys.

A few honest details. .env files are on an ignore list the agent is told to stay out of. That is a guardrail, an instruction to the agent, not a hard block, so keep production secrets off that computer. Chat messages and preview traffic go through Butterneck's server, and the coding CLI sends code context to its provider as it does in normal use. More in how Butterneck runs an AI coding agent in a sandbox on your machine.

When it is not a fit

You want AI to open pull requests or merge on its own. Butterneck deliberately does neither.
There is no developer with a local project folder to connect.
You are looking for a cloud IDE or a replacement for engineers.

FAQ

Should product managers write code?

Some technical PMs do, and it can work. But most PMs do not need to write code to get small changes made. What they need is to describe the change where they see it, see the result on the real app, and hand it to an engineer who decides whether it ships.

Is it safe to let PMs ship code to production?

Teams trying it, like H&B, keep engineers reviewing both the plan and the merge request. If you want PMs involved without that overhead, let them ask on a live preview and keep the release with engineering.

Does AI make code review the bottleneck?

The Harvard study suggests it can: pull requests went up 23% with AI agents, while average PR time to review rose 49%. Adding PM-authored PRs to that queue makes it bigger.

Does Butterneck open pull requests for PMs?

No. Butterneck never opens a pull request, never merges and never deploys. The developer reviews the change and publishes it the usual way.

Try it

Book a 30-minute demo and bring a small change your PMs have been waiting on. Or check pricing: Starter is free for one developer and one requester, and Pro is $19 per person per month. Learn more at butterneck.com.

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

Butterneck — Tue, 27 Oct 2026 11:10:23 +0000

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.

Where a small change actually spends its time

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.

Three properties worth designing for

If you want non-developers to ask an agent for changes, I'd argue the system needs three things.

The request happens next to the thing. The person asking should be looking at the running product, not describing it from memory.
The change is visible before it's real. They should see the result on the same screen, immediately, without anyone deploying.
A developer is the only path to production. The agent can edit files. Only a person can make them live.

None of these need new AI. They are plumbing decisions.

The architecture

Here is how Butterneck implements those three properties. I'll keep it concrete.

1. The agent runs where the code already is

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.

2. Requests come in where people already are

There are two entry points:

A chat widget embedded on the live preview. It sends the page URL along with the message, so "this button" has a referent.
A Jira Cloud ticket with a butterneck label. Title, description, comments and attachments become the request. A note with the preview link is posted back to the ticket.

Developer replies in the thread don't trigger the agent, so the developer can talk to the requester without kicking off another edit.

3. 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. 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.

4. Guardrails in layers

Scope. The system prompt has a mandatory file-access section: only the attached folders, nothing outside.
Secrets. A built-in ignore list (.env, .env.*, and the same in any subfolder) is always merged with team-defined globs and included in that section. The agent is told to refuse any part of a request that needs those paths.
Undo. Before each turn, the workspace is snapshotted (via git when available, file copy otherwise). Stopping a turn kills the agent and restores the snapshot.
Confidence. The agent ends each change with a hidden confidence level (very low to very high), shown to the team as a tag, so reviewers know where to look harder.
Access. The developer chooses who may send requests: a named list or anyone with the link.

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.

5. The merge button doesn't exist

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.

"Isn't the human the bottleneck now?"

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.

What this doesn't solve

It needs a local project folder. Teams living only in cloud IDEs aren't a fit.
It doesn't replace developers. It assumes one is there and decides.
Your code context still goes to whichever AI provider your coding CLI uses, and preview traffic passes through Butterneck's relay. "Local" means the edits and the runtime are local, not that nothing leaves the machine.

Closing

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.

How Butterneck runs an AI coding agent in a sandbox on your own machine

Butterneck — Tue, 27 Oct 2026 11:06:26 +0000

Butterneck lets a product manager ask for a change on a live copy of an app, and a coding agent makes the edit. The agent does not run on our servers. It runs on a developer's own computer, using the coding CLI that developer already has signed in: Cursor (agent), Claude Code (claude), or Antigravity (agy).

This post walks through how that works and what the guardrails actually are. Where a guardrail is a prompt instruction rather than a hard block, we say so.

The pieces

The bridge. A small Node.js daemon (Node 22 or newer) that the developer pairs with their account. It watches the project folders the developer connects, starts the app, and keeps a WebSocket open to the Butterneck server.
The chat server. Runs in-process with the bridge for each connected folder. When a request arrives, it builds a prompt and starts the coding CLI as a child process.
The chat widget. A script embedded on the live preview, so the person asking types next to the screen they mean.

The coding CLI is invoked in non-interactive print mode, one turn at a time. For example, Cursor's agent is started with --print, --trust, --force, and --workspace <folder>. Claude Code gets --print and its own --system-prompt. Antigravity runs with --mode accept-edits and --add-dir <folder>.

Those flags matter. The CLIs run with their own permission prompts skipped, because nobody is at the terminal to click "allow". So the boundaries below are what keep a turn in its lane.

Isolation: one folder per request stream

Each private copy (we call it a sandbox) is tied to a folder on the developer's machine. The developer chooses it. It can be:

an existing project folder,
a fresh clone of a repository, or
a git worktree named after the sandbox, created under .worktrees/ inside the chosen repo (the bridge adds .worktrees/ to .gitignore).

Worktrees are the useful option when a team wants several requests in flight. Each one gets its own checkout and branch, and none of them touch the main working copy.

The agent's working directory is set to that folder. The system prompt includes a mandatory "File access boundaries" section: read and edit only inside the attached folders; never write, move, or delete anything outside them.

To be precise: that boundary is an instruction to the agent, plus the CLI's own workspace setting. It is not an OS-level sandbox like a container or a separate user account. The process runs as the developer.

Secrets: `.env` is always on the ignore list

There is a built-in ignore list that cannot be turned off:

.env
.env.*
**/.env
**/.env.*

Teams can add their own globs on top (for example config/secrets/ or *.pem). The bridge merges the two, drops anything absolute or containing .., and stores the result next to the sandbox data, not in your project.

The merged list goes into the system prompt: never touch these paths, and refuse the part of a request that needs them. The same matcher (isPathAllowed) is exported by the CLI package for checks in code.

Same caveat as above: the agent is told not to touch those files. If you need a hard guarantee, keep production secrets off the machine that runs the bridge. That is good practice anyway.

Every turn can be undone

Before a turn starts, the chat handler captures a baseline of the folder. In a git repo it uses git; otherwise it copies files (skipping node_modules, .git, build output, and very large files).

If the person asking or the developer stops the turn, the agent process is aborted and the files are put back to that baseline. A bad turn does not leave a half-edited project behind.

Never merges, never opens a PR, never deploys

There is no code path in the bridge or chat server that pushes, opens a pull request, merges, or deploys. The agent edits files in the folder. That's it.

The system prompt also tells the agent not to run production builds during a chat turn. The dev server is already running and hot-reloads the edit, and a production build can break the running preview.

What ships is up to the developer. They read the conversation, look at the running app, check the diff in their own tools, and commit and publish the way the team already does. Or they throw it away.

Preview links without a deploy

The bridge starts the app (it detects the dev command and the port) and the Butterneck server gives it a public share URL. Requests to that URL are relayed over the bridge's WebSocket to the app on the developer's machine. The relay handles hot-reload WebSockets, event streams, and binary files such as office documents.

So the person asking sees the change appear on the same screen they asked from, without a VPN, a staging deploy, or a localhost link. The developer controls who can send requests: a named list, or anyone with the link. Viewers do not need an account.

What leaves your machine

Worth being exact here, because "runs locally" is easy to over-read:

Your source files are edited on your machine. Butterneck does not run its own model.
The coding CLI sends prompts and code context to its own AI provider, the same as when you use it directly. That is governed by your agreement with Cursor, Anthropic, or Google.
Preview traffic (the rendered app) passes through the Butterneck server so the share link works.
Chat messages travel through the Butterneck server to reach the bridge.

Try it

Butterneck has a free Starter plan for one developer and one person asking for changes. If your team spends more time relaying small requests than making them, take a look at butterneck.com.

DEV Community: Butterneck

AI pull requests need an owner: what LinearB's 2026 data says about the AI code review bottleneck

What LinearB measured

"A natural human owner"

Correlation, not causation

Other data on the AI PR review bottleneck

What "giving AI PRs an owner" can look like

How Butterneck handles ownership

Why a connected computer instead of a cloud sandbox

FAQ

Why do AI pull requests take longer to review?

What is the AI PR merge rate in LinearB's benchmarks?

Does Butterneck improve merge rates or pickup time?

Does Butterneck open pull requests?

Why does Butterneck use a connected computer instead of a cloud sandbox?

Try it

Should product managers ship code? A better middle ground

The debate, in plain terms

What the data says about review

Why "PMs opening PRs" is the wrong unit

The middle ground: ask on a live preview, ship through engineering

Where to draw the line

How Butterneck does this

When it is not a fit

FAQ

Should product managers write code?

Is it safe to let PMs ship code to production?

Does AI make code review the bottleneck?

Does Butterneck open pull requests for PMs?

Try it

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

Where a small change actually spends its time

Three properties worth designing for

The architecture

1. The agent runs where the code already is

2. Requests come in where people already are

3. The preview is the running dev server

4. Guardrails in layers

5. The merge button doesn't exist

"Isn't the human the bottleneck now?"

What this doesn't solve

Closing

How Butterneck runs an AI coding agent in a sandbox on your own machine

The pieces

Isolation: one folder per request stream

Secrets: .env is always on the ignore list

Every turn can be undone

Never merges, never opens a PR, never deploys

Preview links without a deploy

What leaves your machine

Try it

Secrets: `.env` is always on the ignore list