Vibe coding workflow: a review loop for UI without chaos

A vibe coding workflow stays under control when every change goes through the same short loop: ask for a plan, look at the result as screens before any code changes, choose one version, let the agent implement it in a small batch, then check the diff and the running app before the next request. The loop adds a few minutes per change. It saves the afternoon you would otherwise spend working out which prompt broke the settings page.

Where vibe coding goes wrong on UI

Describing what you want and judging the result by trying it works well at the start of a project. It gets harder once the app has real screens and real users. The same problems keep coming back:

• Drift: each request changes a little more than you asked, and after ten prompts the layout no longer matches anything you decided.
• Lost versions: you liked the header from two prompts ago, and there is no clean way to get it back.
• Unseen states: you checked the screen with data; nobody looked at the empty or error state the agent also changed.
• Unreadable diffs: one request touched 30 files, so you accept it without reading.
• All or nothing reverts: undoing one bad change means undoing the good ones that came with it.

Better prompts alone do not fix these. A loop with checkpoints you can see does.

The loop in five steps

1. Plan: the agent says what it will change before it changes anything.
2. Prototype: you see the change as screens, state by state, before the code moves.
3. Choose: you pick one version and keep the others.
4. Apply: the agent implements the chosen version in a small batch, then runs your checks.
5. Verify: you read the diff, open the running app, and commit.

The next request then starts from a clean, committed state.

Plan before any edit

In Claude Code, plan mode has the agent research and propose changes without making them: it reads files and writes a plan, and it does not edit your source until you approve that plan. Press Shift+Tab to cycle into it, prefix a single prompt with /plan, or start the session with claude --permission-mode plan. The permission modes documentation describes each mode.

A planning prompt for a UI change:

/plan Redesign the Settings page so that billing and team members are
separate tabs. List the files you would change, the components you would
reuse, and every state of the page that changes (loading, empty team,
billing error). Do not propose changes outside Settings.

The last sentence matters. Scope is the cheapest thing to fix at the plan stage and the most expensive to fix in a diff.

Look at screens, then choose

A plan in text still leaves the look of the result open. Before any code, have the agent draw the affected states as screens; static HTML is enough. Review them one state at a time, empty and error states included, and give feedback that points at one screen and one change:

On Settings, team tab, empty state: replace the illustration with one line
("Invite your first teammate") and an Invite button. Keep everything else.

When you hesitate between directions, ask for two or three variants and pick one. Keep the versions you did not choose: if the chosen one fails in practice, you can go back to a known alternative instead of describing it again from memory. Why every prototype change should be a version explains this in more detail, and how to write a change request an AI agent gets right covers the wording of feedback.

Apply in small batches, with an undo

Implement one screen or one flow per request. Commit before each batch, so that the batch can be reverted on its own:

git switch -c settings-tabs
git add -A && git commit -m "Before settings tabs"
# ask the agent to implement the chosen version, then:
git diff --stat
git diff

git diff --stat tells you at a glance whether the batch stayed in scope: a Settings change that touches the router, the auth code and the lockfile deserves a question before anything else.

The request that starts the batch should be as narrow as the plan:

Implement the chosen version of Settings, team tab, in the app. Change only
the files listed in the plan. Run the type check, the linter and the tests,
then tell me what you changed, what you could not do, and any state you
did not implement.

Asking for what it could not do matters as much as what it did: an agent that reports gaps gives you a list to review, instead of a surprise in production.

Claude Code also keeps checkpoints of its own file edits: run /rewind, or press Esc twice with an empty prompt, to restore the code or the conversation to an earlier prompt. Checkpoints do not track files changed by shell commands and do not replace Git, as the checkpointing documentation says, so use them for quick undo within a session and commits for everything else.

Verify that what shipped is what you chose

Before you commit the batch and send the next request, check:

• Every state you approved exists in the running app and looks like the version you chose.
• The states you did not look at this time (empty, error, loading) still work.
• The diff only touches the files the plan named, or you know why it does not.
• Your checks pass: types, lint, tests, whatever the project has.
• No unrelated refactor, dependency or configuration change slipped in.
• The copy matches the prototype word for word.

Comparing the running app with the approved screens is the step most people skip. How to review UI changes made by an AI agent has a fuller checklist.

Know when to reset instead of prompting again

If three requests in a row have not fixed the same screen, stop adding prompts on top. Each attempt leaves traces in the code and in the conversation, and the agent starts fixing its own fixes. Go back to the last commit, write down in one sentence what is wrong with which state of which screen, and start that batch again from the plan. A clean restart with a precise request is almost always faster than a fourth correction.

Running the loop in agentappbuilder

agentappbuilder is built around the middle of this loop. Your agent prototypes each state as a frame on a canvas, you paste the URL of a frame into your chat with what to change, and each change becomes a new version. Versions are never overwritten and can be compared side by side, and when you want options, your agent proposes 2 to 4 variants for you to choose from. Nothing is coded until you ask: “Apply the prototypes” makes your agent code the active versions, run your app’s checks and report what it implemented. If you later make another version active on a frame that is already implemented, your agent asks you before production follows. If your app runs, your agent can also capture it with your agreement, so you can compare the real screens with the prototype.

Two limits are worth knowing. The platform tells your agent to run your checks but does not verify them, and the quality harness (specs, tests and CI that your agent installs in your repository) is coming next, not available today. Git, the diff and your own review remain your job. Working with your agent lists the prompts for each step, and the architecture page describes the review loops, today and planned.