How to ship app changes with an AI agent and keep control

To ship app changes with an AI agent and keep control, separate three moments: deciding what to change, building it, and releasing it. Decide before any code (a plan or a prototype you approve), let the agent build on a branch and run the checks, review the screens and the diff, and keep push, merge and deploy as steps that need your explicit go-ahead, enforced by settings rather than by memory.

An agent can take a request from idea to production in one session. That speed is the point, and also the risk: every decision it makes on your behalf is one you did not review.

Where control gets lost

Control rarely disappears in one dramatic step. It leaks:

• The agent chooses for you. There were two plausible designs; it picked one and built it.
• Scope grows. A small fix arrives with a refactor and a dependency bump.
• Checks get softened. A failing test is “fixed” by relaxing the assertion.
• Release happens by momentum. “Looks good” in the chat turns into a push, a merge, a deploy.
• Instructions fade. “Don’t push yet” was said an hour ago, and long sessions compress old messages.

Each needs its own guard. None of them is solved by asking the agent to be careful.

Decide before the agent writes code

The cheapest place to keep control is before the first edit. Two tools help.

A plan. In Claude Code’s plan mode, the agent reads the code and proposes changes without editing your source. Press Shift+Tab to reach it, or start with claude --permission-mode plan. You approve the plan, or keep planning and correct it.

A prototype. For interface changes, ask the agent to show the screens before coding them: static HTML frames, one per state, or two or three variants to choose from. You decide on screens, and the agent implements the decision. From prototype to production code with a coding agent walks through that handoff.

Either way the rule is the same: the agent proposes, you choose, and only then does it build.

Build on a branch, with checks the agent must run

Give every change its own branch, so the unit you release is something you can see and revert. Keep branches short-lived: a change that waits days for review tends to pick up unrelated fixes along the way, and each one widens what you must check. For parallel work, claude --worktree <name> starts a session in its own git worktree, a separate checkout on its own branch.

Then write the checks down in the project CLAUDE.md, which Claude Code loads in every session:

## Before saying a change is done
- Run `npm run lint`, `npm run typecheck` and `npm test`. All must pass.
- Never delete or weaken a test to make it pass: stop and tell me.
- List the screens and states affected by the change.

CLAUDE.md shapes behavior, it does not enforce it. Your CI does: the same checks should run on every pull request, whatever the agent reports.

Put your own checkpoints on push and deploy

Releasing is where you want a hard stop. In auto mode, Claude Code allows pushes to any branch of the repository you are working in, and pull request creation, by default. To approve each one yourself, add ask rules to your settings: they force a prompt even in auto mode.

{
  "permissions": {
    "ask": ["Bash(git push *)", "Bash(gh pr create *)"],
    "deny": ["Bash(npm run deploy *)"]
  }
}

A deny rule blocks the command before the auto mode classifier is consulted, and nothing said in the conversation can override it. Use it for commands that should only run from your CI or by your own hand. These rules match the command as written: a push phrased another way, such as git -C <dir> push, is not caught, which is why the auto mode configuration guide suggests a hook when you need a stricter check.

Saying “don’t push until I review” in the chat also works, since the classifier treats it as a boundary. But it lives only in the conversation, and it can be lost when old messages are compacted. Rules in settings do not fade. Why an action gets blocked in auto mode covers the other side: what to do when the classifier stops a step you did want.

Review what will ship

Before you merge, review in two passes: the rendered screens in every state the change affects, then the diff for scope, reuse and tests. Ask the agent for the list of affected screens first, and check that list against the diff. How to review AI generated UI changes details both passes. If the change touches payments, authentication or data deletion, read those parts of the diff line by line, whatever the screens show.

Ask for a pull request description that lists what changed and why, in the words you used when you asked for it. If a line of the description is not something you requested, find out where it came from before merging.

Know what is live

After a few iterations it is easy to lose track of which version of a screen is in production and which is only proposed. Keep the distinction explicit: the version you chose, and the version that is implemented. For code, a release note per merge does this. For screens, keep the chosen design next to what shipped, so anyone can tell at a glance whether production matches the decision.

agentappbuilder tracks exactly this. Each frame on its canvas has an active version (the one you chose) and an implemented version (the one your agent last reported as coded in the real app). Your agent codes the active versions only when you say “apply”, runs your app’s checks and reports what it implemented. If you later make another version active on a frame that is already implemented, the platform opens a notice, and your agent asks you whether production should follow before it does anything. The platform never writes to your repository: the code, the branch and the release stay with your agent and your tools. Concepts describes versions and notices, and Security and data lists what the platform stores.

A release checklist

Step	Question	Who decides
Decide	Did I approve a plan or a prototype for this change?	You
Build	Is it on its own branch, with only what I asked for?	The agent, checked by you
Check	Do lint, types and tests pass in CI on the final commit?	CI
Review	Did I look at every affected state and read the diff?	You
Push and merge	Did I approve the push and the merge myself?	You, enforced by rules
Deploy	Is there a rollback, and do I know what is live?	You

The agent does the building. The decisions on either side of it stay yours.