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%
In this lesson

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

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

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?

Often somewhere between ten and forty. If you are past a hundred and it is not converging, the scope grew — go back to your one sentence and check what crept in.

Should I write any of it myself?

Whenever it is faster or when you want to understand a part properly. There is no rule that the agent has to type everything, and hand-writing the tricky part is often the quickest route through it.

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?

One small change you can check, running, in a state worth committing — 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?

It makes throwing away a bad turn a one-command operation — 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?

Check it against your not-doing list and usually decline — 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.

Commands in this lesson

Move between lessons with ← → · search with ⌘K

Written and reviewed by Mikhail Kuzmitskii