Skip to content
zero2vibecodelearn vibe coding
Level 4 · Ship something 8 min Reviewed by the author · Aug 4, 2026

Building it, turn by turn

A project is not one enormous prompt. It is a sequence of small turns, each one ending in a working state you committed.

Level 4 · 0 / 4 lessons0%

You have a folder, a README with one sentence, and a CLAUDE.md. Now you build, and the whole technique is rhythm.

Set up the safety net first

Before the first turn, put the project in Git and commit what you have. Do it in the terminal below.

From here on, every turn you are happy with ends in a commit. That is what makes the next turn safe to attempt.

This is not optional here

Everything in this lesson — try things, throw away bad turns, experiment — depends on being able to get back to a known-good state instantly. Without commits, every risky turn is a gamble with the whole project.

Get the ugly version working end to end

The instinct is to build it properly, piece by beautiful piece. Do the opposite. Get something that runs, start to finish, as ugly as it likes.

Make the button take whatever is in the textarea, shuffle the lines, and put them back in the textarea. No styling, no error handling yet.

Now you have a working thing. Everything after this is improvement on something real, and you can run it after every single turn to check you have not broken it.

Quick check

What is the advantage of a working ugly version first?

One turn, one change

Turns that work look like this:

Empty input should show “Add some names first” instead of doing nothing.

Ignore blank lines when shuffling.

Add a Copy button that puts the result on the clipboard.

Turns that do not work look like this:

Add error handling, a copy button, some styling, and make it work on mobile.

Same total work, but the second one fails in four places at once and you cannot tell which change caused what.

After each turn

Three things, and they take a minute:

  1. Run it. Actually click the button. Not a mental simulation.
  2. Read the diff. Especially the parts you did not ask about.
  3. Commit it, with a message that says what changed.

If a turn made things worse, do not patch it. Throw it away — git restore or a checkout of your last commit — and ask again, differently. That is level 2 applied to your own project.

Keep a running list

Keep the next three things in a file, not in your head. When the agent suggests something interesting mid-session, it goes on the list instead of into this turn. The list is also where you look when you sit down tomorrow and cannot remember where you were.

When it starts feeling heavy

Long build sessions drift — the agent forgets a decision you made an hour ago, or suggests something your not-doing list rules out. That is the context lesson from level 1 showing up in real work.

The fix is the same: finish the current turn, commit, clear the session, and start the next piece fresh. Your README and CLAUDE.md carry the state forward, which is exactly why you wrote them.

How many turns should a small project take?
Should I write any of it myself?

Check your understanding

Answered 0/3
Mode:

What should a single turn produce?

Why commit after every turn you are happy with?

The agent suggests a feature you did not ask for. What do you do?

Finish the task in the terminal and answer the questions to complete the lesson.

📝 My notes

Saved automatically in this browser · shows up on the Notes page.

Task

Set up version control for the project and save your first working state.

Tab complete · history · Ctrl+L clear · help commands

  • Not done: Start tracking the project
  • Not done: Stage everything you have so far
  • Not done: Save the first checkpoint
  • Not done: The commit message describes the state
  • Not done: Confirm the checkpoint exists

Lesson Q&A

What should a single turn produce?

Working state, committed, then the next thing. That rhythm is what stops a project falling apart in the middle.

Why commit after every turn you are happy with?

Frequent commits are what make experimenting cheap. Without them every risky turn is a gamble with the whole project.

The agent suggests a feature you did not ask for. What do you do?

You wrote the boundary down for exactly this moment, when the suggestion sounds reasonable and you are tired.

What is the advantage of a working ugly version first?

An end-to-end path means every turn is verifiable. Building beautiful pieces that do not connect yet means nothing is verifiable until the very end.

Move between lessons with · search with ⌘K