AI change requests for product teams: a practical guide

Originally published on butterneck.com.

In short: AI change requests let product managers and designers ask for a change to an existing app in plain words. An AI coding agent edits the real code, the requester checks the result on a live preview, and a developer decides what ships. In Butterneck, the agent is the Claude Code, Cursor or Antigravity CLI a developer already uses, running on the developer's computer. Butterneck does not commit, push or open a pull request; a developer decides first, and Butterneck never merges or deploys.

Every product team has a queue of small change requests. Fix this label. Move that field. Update the copy on the pricing card. Each one is minor. Together they eat a surprising amount of a team's week, mostly in handoffs.

AI change requests are a way to shorten that queue: the person asking describes the change, an AI coding agent makes it on a live copy, and a developer approves it. This post covers what that looks like in practice for product teams, what to watch out for, and how Butterneck does it.

What is an AI change request?

AI change requests let non-developers, like product managers and designers, ask for a change to an existing app in plain words. An AI coding agent edits the real code, the requester checks the result on a live preview, and a developer decides what ships.

A change request is any "can we change X to Y" on a product that already exists. An AI change request is one where an AI coding agent does the edit, not a person reading a ticket.

The useful version has four parts:

1. Ask in context. The requester points at the real screen, not a description of it.
2. AI edits real code. Not a mockup. The agent changes the project's own files.
3. Requester sees the result. On a running copy, right away.
4. Developer decides. A developer reviews and publishes, or discards.

Leave out step 3 and the requester is back to waiting. Leave out step 4 and engineering will not let it near the product. For the PM side of this, and the other ways teams handle it, see how PMs can change a live app without waiting on engineering.

What the requester checks, and what the developer checks

Both people review the change. They check different things. It is the same plan, execute, verify loop a developer runs with an AI agent: the requester plans (describes the change), the agent executes (edits the code), and the verify step is split between two people.

The requester checks the result:

• It is the change they asked for, seen on a live preview of the existing app, on the screen they asked from.
• The wording, layout and spacing look right.
• The states that matter still work: empty, error, loading, mobile width.
• Nothing else on the page moved or broke.
• If something is off, they keep asking on the same request until it is right.

The developer checks the code:

• The diff touches only what the request needed.
• The change is right beyond that one screen: shared components, translations, tests, emails that reuse the same text.
• Tests, lint and the build still pass.
• Nothing touched secrets, sign-in, billing or data.
• Whether it ships: commit and release it the usual way, or discard it.

This split isn't only ours. VirtusLab's Visdom guide on non-coder contributors via agent interfaces describes the non-coder's job as "PEV: plan, execute, verify" and says their "verification method cannot be 'read the code.' It must be: see the change in a staging environment, run the specified acceptance test, or review the change description generated by the agent in non-technical terms." It also suggests that, at first, an engineer review "every agent output before it's merged, even though the non-coder has already verified it."

For a fuller checklist, and why this check should happen before a pull request exists, see live preview before the PR.

The requester's check matters more as AI writes more code than people can review. We collected the data on the AI PR review bottleneck.

Why product teams need a process for this (and what AI automation should cover)

Without a process, AI change requests happen anyway, just badly. A PM pastes a screenshot into a chat tool and asks a developer to "just run it through Claude." The developer copies the request, runs the agent, deploys a preview, and sends a link. The AI saved five minutes of coding. The relay still took two days.

A process puts the request, the agent, and the preview in the same place.

Most AI automation for product teams moves information: routing feedback, writing release notes, syncing Jira and Slack. Change requests are the same problem with code at the end. The part worth automating is the handoff: the request, the screen it's about, and the files, delivered to a coding agent that already knows the project. The part to keep human is the decision about what ships.

How Butterneck handles AI change requests

Requests come from chat or Jira

• Chat on a live copy. A developer shares a link to the running app. The requester opens it, sees the app with a chat beside it, and types the change.
• Jira. Label a ticket butterneck and assign it to a teammate whose Jira account is mapped to a computer that has the project. The ticket becomes the request, and a note with a preview link is posted back when the AI is done. Details in Jira ticket to pull request with AI.

The agent runs on a developer's machine

The coding agent is the CLI the developer already uses: Cursor, Claude Code, or Antigravity. It runs on their computer, in a folder they choose for that private copy. Butterneck does not run its own model.

The preview is the app itself

The app runs on the developer's machine and Butterneck gives it a public share link. Hot reload works through the link, so the requester sees the change on the screen they asked from. No staging deploy. See how to share a local app without deploying.

A developer decides what goes live

Butterneck never merges, opens a PR, or deploys. The developer reads the conversation, checks the diff in their own tools, and publishes the usual way.

Who can ask, and how much

Access control matters once more than one person can send requests.

• The developer chooses who can send: a named list, or anyone with the link.
• If the link is closed, a visitor can ask for access. The developer allows or declines.
• Viewers do not need an account.
• A reply from a developer in the chat does not change any files, so developers can answer questions without triggering the AI.

Guardrails to check before you roll this out

These are the questions a CTO should ask any AI change request tool. Here are Butterneck's answers, stated plainly.

• Where does the agent write? Only in the folder tied to the private copy. Make that folder a git worktree or a fresh clone, and in-flight requests stay off the main checkout.
• Can it read secrets? .env files and team-added globs are listed as off-limits in the agent's instructions. That is a guardrail, not an enforced block. Keep production secrets off the bridge machine.
• What leaves the machine? The coding CLI sends code context to its own AI provider. Chat messages and preview traffic go through Butterneck's server.
• Can a bad change be undone? Each turn records a baseline. Stopping a turn usually rolls its file changes back; if it can't, the chat says so.
• Can it ship by itself? No. There is no code path that pushes, merges, or deploys.

Who can send a request, and what the share link exposes, are on the Security page.

The longer version is in how Butterneck runs an AI coding agent in a sandbox on your machine.

What kinds of requests fit

Good fits:

• Copy and label changes.
• Layout and spacing tweaks.
• Small UI fixes: a missing state, a wrong color, a broken link.
• Adding or removing a form field when the backend already supports it.

Poor fits:

• New features that need design and scoping.
• Changes to billing, permissions, or data models without close engineering review.
• Anything that needs production data or secrets.

For how to word a single request so the agent gets it right, see how to write a change request for an AI coding agent.

A rollout plan for product teams

• Week 1: One app, one developer, one PM. Requests limited to copy and UI.
• Week 2: Add Jira. Agree on a "small change" definition for the butterneck label.
• Week 3: Add more requesters through the named list. Keep one developer reviewing.
• After that: Decide which apps and request types are in scope, and write it down.

Track one number: time from request to reviewed change. Compare it with your normal ticket flow. If you need your engineering lead's agreement first, send them the 4-week pilot proposal: a one-page plan with the scope, guardrails, what to measure and when to stop.

FAQ

Is there an AI coding agent for product teams?

Yes. With Butterneck, a PM, designer or support lead asks for a change in a chat beside a live preview of the app, and the developer's own coding agent (Cursor, Claude Code or Antigravity) makes it on a computer that has the project. The person who asked checks the preview. A developer decides whether it ships, and Butterneck never opens a pull request, merges or deploys.

What should a product manager look for in an AI change request tool?

Four things. You ask on the real screen, not from memory. The AI edits the project's own code, not a mockup. You see the result on a running copy right away. And a developer decides what ships. Then ask the questions in the guardrails list above: where the agent writes, what it can read, what leaves the machine, and whether it can ship by itself. In Butterneck, the developer's own Cursor, Claude Code or Antigravity CLI makes the change on a computer that has the project, and Butterneck never opens a pull request, merges or deploys. For a side-by-side of tools that change an existing app, see AI tools that let non-developers change an existing app.

What are AI change requests?

They let non-developers, like product managers and designers, ask for a change to an existing app in plain words. An AI coding agent edits the real code, the requester checks the result on a live preview, and a developer decides what ships.

Do requesters need technical skills?

No. They use a share link in a browser, or a Jira label.

Is the AI allowed to deploy?

Not in Butterneck. It edits files in a folder. A developer publishes.

Which AI models are used?

Whichever model the developer's Cursor, Claude Code, or Antigravity CLI is set to use, under your team's plan for that tool (team or API plans recommended).

How much does it cost?

Starter is free for one developer and one requester. Pro is USD 19 per person per month, with 20% off annual billing and local-currency pricing, and a workspace owner on Starter can try Pro for one month. See pricing.

How is this different from tools that open pull requests?

Butterneck stops at a reviewable change on a live preview. For a comparison with a PR-generating tool, read our Itera alternative or Clogless alternative post, and for the reasoning, human-in-the-loop AI coding.

Try it

Book a 30-minute demo and bring a change request from your backlog. Or start on the free plan from pricing. Learn more at butterneck.com.