Skip to content
zero2vibecodelearn vibe coding
Level 2 · Talking to the agent 6 min Reviewed by the author · Aug 4, 2026

Small steps beat one big request

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.

Level 2 · 0 / 3 lessons0%

No hands-on task in this lesson — just read it through and answer the questions.

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.

Quick check

What determines whether a step is small enough?

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.

Tip

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. 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:

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

Quick check

Why does a snapshot after every working step change how you work?

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.

Important

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.

Quick check

Why is one 300-line change worse than ten 30-line changes, even with identical final code?

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.

Check your understanding

Answered 0/2
Mode:

What is the right size for one step of work with an agent?

Why save a snapshot of your project between steps?

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.

Lesson Q&A

What is the right size for one step of work with an agent?

Verifiability is the limit, not the agent capacity. If you cannot check it, you cannot steer it.

Why save a snapshot of your project between steps?

A known-good point to return to is what makes experimenting cheap. Without it, every change is permanent.

What determines whether a step is small enough?

Steering requires feedback. A step you cannot verify is a step you cannot correct.

Why does a snapshot after every working step change how you work?

With a known-good point to return to, a risky idea costs nothing to try. Without one, every change carries the fear of losing what worked.

Why is one 300-line change worse than ten 30-line changes, even with identical final code?

Review is the point. A change nobody reads carries every one of its problems into your project unnoticed.

Related reading on the blog

Move between lessons with · search with ⌘K