The Build-Review-Iterate Loop

Vibe coding has a rhythm. It's not "prompt once, ship." It's a loop: you ask the AI to build something, you review what it produced, you tell it what to fix or improve, and you repeat until it's right.

This loop is the core workflow of vibe coding. Getting good at it is the single most impactful skill you can develop.

The Loop

Every vibe coding session follows this pattern:

1. BUILD  — Prompt the AI to create or modify code
2. REVIEW — Look at what it produced
3. DECIDE — Accept, reject, or redirect
4. ITERATE — Refine with a follow-up prompt
5. Repeat until done

Simple in concept. The skill is in each step.

Step 1: Build — The Initial Prompt

You've already learned how to write good prompts. The Build step is where you apply those skills. But there's one additional principle specific to the loop: start broader than you think you need to.

For the first generation, give the AI room to work. You can always narrow things down in later iterations. If you over-constrain the first prompt, you might miss a good approach the AI would have suggested.

First prompt (good):
Build a notification component that shows toast messages at the
bottom-right of the screen. Support success, error, warning, and
info types. Auto-dismiss after 5 seconds with a progress bar.
 
First prompt (too constrained):
Build a notification component. Use position: fixed, bottom: 16px,
right: 16px, z-index: 50. Each toast should be a div with role="alert",
using these exact Tailwind classes: bg-white rounded-lg shadow-lg p-4
max-w-sm. The progress bar should be a 2px div at the bottom...

The second prompt micromanages the implementation. It tells the AI how to build instead of what to build. The first prompt describes the desired behavior and lets the AI apply its expertise to the implementation.

Step 2: Review — The Critical Read

This is where most vibe coders fall short. The temptation is to glance at the output, see that it looks reasonable, and accept it. Resist that temptation.

A good review doesn't require understanding every line of code. It requires answering these questions:

Does it do what I asked?

Run the code. Click through the feature. Does it actually work the way you described? Does clicking the button do what you said it should? Does the data display correctly?

Does it handle edge cases?

What happens when:

The data is empty? (No notifications to display)
There are many items? (20 notifications at once)
The user does something unexpected? (Closes the browser mid-action)
The input is unusual? (Very long text, special characters)

Does the structure make sense?

Even without deep code knowledge, you can assess:

Are there too many files? Too few?
Are file names descriptive?
Is the code organized logically?
Are there obvious redundancies (the same logic repeated in multiple places)?

Are there red flags?

Watch for:

Hardcoded values that should be configurable (const MAX_ITEMS = 100 buried in logic)
Console.log statements left in the code
Commented-out code with no explanation
Overly complex solutions to simple problems
Dependencies you didn't ask for

Step 3: Decide — Accept, Reject, or Redirect

After reviewing, you have three options:

Accept

The code does what you want. Accept the changes, move on to the next feature. This should happen about 30-40% of the time on the first attempt for complex features.

Reject

The approach is fundamentally wrong. The AI misunderstood what you wanted, chose the wrong architecture, or produced something too far from your needs. Reject and try a completely different prompt.

This is important: rejecting is not failure. It's data. A rejected attempt tells you something about how the AI interpreted your prompt, which helps you write a better one.

Redirect

The approach is right, but the details need work. This is the most common outcome. You accept the general direction and guide the AI to fix specific issues.

Good redirect:
The notification component is mostly right, but:
1. The notifications should stack from bottom to top, not top to bottom
2. Add a close button (X) to each notification
3. The progress bar should animate smoothly, not jump
Keep everything else the same.

Step 4: Iterate — The Follow-Up Prompt

Iteration prompts are different from initial prompts. They should:

Reference what exists

In the NotificationToast component you just created...

Be specific about changes

Change the animation from fade-in to slide-in-from-right.

State what to preserve

Keep the auto-dismiss timing and progress bar. Only change the
entrance animation.

Focus on one to three changes at a time

Don't dump ten changes into one iteration prompt. Three is usually the sweet spot. More than that and the AI starts breaking things that were already working.

The Iteration Budget

Here's a practical framework for managing iterations:

| Iteration | Expected State | |-----------|---------------| | 1 (Build) | Core structure and ~70% of functionality right | | 2 | Major issues fixed, ~85% right | | 3 | Minor refinements, ~95% right | | 4 | Final polish, edge cases | | 5+ | If you're still iterating, something is wrong |

If you're past five iterations on the same feature, one of these is happening:

Your initial prompt was too vague (start over with a better prompt)
The feature is too complex for one prompt (decompose it)
You're chasing perfection instead of shipping (good enough is good enough)
The AI can't do what you're asking (consider a different approach or manual coding)

Common Iteration Patterns

The Narrowing Pattern

Start broad, then narrow:

Iteration 1: Build the settings page with all sections
Iteration 2: Fix the notification preferences section — the toggle states aren't saving
Iteration 3: Add validation to the email change field — require confirmation

The Layering Pattern

Add complexity in layers:

Iteration 1: Build the basic form
Iteration 2: Add validation
Iteration 3: Add loading and error states
Iteration 4: Add optimistic UI updates

The Fix-and-Extend Pattern

Fix problems, then add features:

Iteration 1: Build the chart component
Iteration 2: Fix — the Y axis labels are overlapping when values are large
Iteration 3: Extend — add a tooltip that shows exact values on hover

When the Loop Stalls

Sometimes the AI keeps producing the same wrong result no matter how you rephrase. When this happens:

Try a Different Angle

Instead of rewording the same request, change the approach:

Instead of trying to fix the animation with CSS, let's use Framer Motion
for the entrance and exit animations.

Show What's Wrong

Instead of describing the problem, show it:

When I click "Save," the form submits but the UI doesn't update.
I expect the save button to show a spinner, then change to a checkmark
for 2 seconds, then return to normal. Currently it just stays as "Save"
the whole time. The console shows the API call succeeding.

Start Fresh

If the code has accumulated too many patches from iterations, it might be cleaner to scrap the component and regenerate it with everything you've learned:

Let's start the NotificationToast component over. Here's exactly
what I need, based on what we've learned from the previous attempts:
[comprehensive prompt incorporating all the lessons from earlier iterations]

Switch Tools

If one AI tool is struggling with a task, try another. Generate in v0, refine in Cursor. Ask Claude for the approach, implement in Bolt. Different tools have different strengths.

The Review Checklist

Keep this mental checklist during the review step:

[ ] I ran the code and tested the feature manually
[ ] The happy path works (the main use case)
[ ] I tested at least one edge case (empty data, too much data, unusual input)
[ ] The code structure is reasonable (not over-engineered, not a single 500-line file)
[ ] No hardcoded values that should be configurable
[ ] No console.log or debugging artifacts left in
[ ] The change only affects what I asked for (no surprise modifications to other files)

The Speed Trap

As you get comfortable with the loop, you'll be tempted to go faster — accept more, review less. This works until it doesn't. And when it doesn't, you end up with a codebase full of accumulated small issues that are much harder to fix than they would have been individually.

The review step is not overhead. It's the step that makes the whole process work. A two-minute review catches a ten-minute bug.

Try this now

Pick one small feature and deliberately run the full loop: build, review, decide, iterate.
Keep the first prompt broad enough to get a working slice, then use follow-up prompts to correct specifics.
Stop after each response and explicitly choose: accept, reject, or redirect.

Prompt to give your agent

"I want to work in a build-review-iterate loop for this feature. Start with the smallest reviewable slice that proves the approach. After you propose or implement that slice, stop and show me:

what you changed

what assumptions you made

what could still go wrong

what the next iteration should focus on

Keep each iteration scoped to one to three concrete changes. If we pass five iterations on one feature, tell me to step back and reassess instead of patching blindly."

What you must review yourself

Whether each iteration is actually smaller and clearer than the last
Whether the AI is preserving working behavior while fixing the current issue
Whether you are reviewing the output before sending the next prompt
Whether you have crossed from productive iteration into patch-on-patch confusion

Common Mistakes to Avoid

Treating the first output as the final answer. The loop only works if you actually review and redirect.
Changing too many things per iteration. Small iterations make it obvious what helped and what broke.
Skipping the decision step. "Let's see what happens next" is not a workflow.
Pushing past the iteration budget without resetting. If the loop stalls, stop and rethink instead of piling on patches.

Key takeaways

Vibe coding is a loop: Build, Review, Decide, Iterate
Start broad on the first prompt, narrow through iterations
Review critically — does it work, handle edge cases, and make structural sense?
Accept, reject, or redirect after each review — redirecting is the most common and useful option
Keep iterations focused on one to three changes at a time
If you're past five iterations on one feature, step back and reassess your approach
The review step is not optional — skipping it creates compounding problems

What's Next

Next up: Code Review With AI — Using a Second AI as Your Senior Engineer. Use a second AI to review code generated by your first AI, catching bugs and improving quality. This builds directly on what you learned here, so carry the same discipline forward: define the constraints first, then use your AI agent to implement against them.