# Small steps beat one big request

Course: Vibe Coding 101 — https://zero2vibecode.com/learn/vibe-coding-101
Canonical URL: https://zero2vibecode.com/learn/vibe-coding-101/2-3-small-steps

How big a change should be before you stop being able to check it, why you save a snapshot between steps, and how to split a feature into pieces that each run.

You can ask for the whole feature at once. It will produce something. And you will be holding a change too large to check, built on assumptions you never saw.

The alternative is unglamorous and much faster in practice: small steps, each one verified.

## What "small" means

Not lines of code. Not files. The measure is: **can you run it and see whether it worked?**

That is the only limit that matters, because it is the limit of your ability to steer.

Adding tags to Readlist, in verifiable steps:

1. Add a second text box for tags. Nothing saves yet. *Check: the box appears and you can type in it.*
2. Save tags along with the link. *Check: save one, refresh, the tags are still there.*
3. Show tags under each list item. *Check: you can see them.*
4. Click a tag to filter the list. *Check: click one, only matching items remain.*

Four steps, four checks, each about a minute. If step 2 quietly breaks the existing links, you know at step 2 — while the change is still small enough to point at.

## Every step should leave the thing running

The trick that makes this work: split so that the app *always runs*, even mid-feature.

Step 1 above adds a text box that does nothing. That feels pointless. It is not — it means you are never sitting on a half-broken project wondering which of six changes caused the blank page.

Compare a split that breaks this rule: "change the storage format" as step one leaves the app broken until step three, and now you are debugging three changes at once with no working version to compare against.

If a step cannot leave the app working, say so out loud: "this step will leave the page broken until the next one". At least then a blank screen is expected rather than alarming.

## Save a snapshot between steps

After each step that works, save a snapshot of the project. This is the difference between "undo that" costing one sentence and costing your afternoon.

The standard way is version control — a system that records project snapshots you can return to. Git is the one nearly everyone uses, and the sibling Terminal Basics course covers it hands-on.

The zero-knowledge version, which is much better than nothing: copy the whole project folder and name the copy something like `readlist-works-with-tags`. Ugly, effective, takes four seconds.

You can also just ask:

```text
Commit what we have with a short message describing the change.
```

## When you notice it went wrong three steps ago

It happens. The saving broke at step 2 and you noticed at step 5.

Two options:

**Go back.** Return to the last snapshot you trust and redo the steps with better instructions. Clean, and only possible because you took snapshots.

**Fix forward.** Describe the symptom and let the agent investigate — the level 1 message shape: what you did, what you expected, what happened.

Fix forward when the problem is small and local. Go back when you have lost track of what changed, or when two or three fix attempts have already failed.

Three failed fix attempts in a row means the agent is guessing. Stop, go back to a working snapshot, and re-describe the goal from scratch. Attempt four is almost never the one that works.

## The wall of ten thousand lines

The other reason small steps matter: the alternative is a change nobody reads.

Ask for a whole app and you get hundreds of lines across several files. Nobody reviews that — not you, not an experienced engineer, not honestly. So it goes in unread, and every problem in it is now a problem in your project, discovered later, at a worse time.

Ten changes of thirty lines each get read. One change of three hundred lines does not. Same code, entirely different amount of review.

## The rhythm

Ask for one step. Run it. Look. Save a snapshot. Next step.

It feels slower for the first ten minutes and is dramatically faster by the end of the hour — because you never spend forty-five minutes untangling a change you did not watch happen.

## Try it yourself

It works. Now decide what happens next.