Module 1 · Learn to drive: how to tell AI what to build
Iterating: how to ask for changes
Building a tool is a conversation, not a single command. You look at what you’ve got, ask for one change, look again. Doing that well — small requests, in the right order, with a safety net — is what separates a smooth build from a frustrating one.
One change at a time
The single biggest habit: ask for one thing at a time, and be specific. “Make the total bigger and blue” gets you exactly that. A paragraph asking for five changes at once gets you a muddle where you can’t tell which request landed and which didn’t.
Make a change, look at the result, then ask for the next one. It feels slower. It’s much faster, because you’re never untangling three half-done edits.
Describe what you see, not what’s underneath
You and Claude are looking at different things. Claude sees the code; you see the screen. So point at the screen. “The button at the bottom — make it green and put more space above it.” You never need to know what the button is called in the code. Describe where it is and what you want, the way you’d tell a designer sitting next to you.
Plan mode for the bigger changes
Small tweaks you just ask for. But when a change is bigger — “add a whole second page,” “change how the whole thing is laid out” — ask Claude to plan before it touches anything:
Ask for a plan first
Before you change anything, tell me your plan in plain English for how you'd do this. I'll approve it before you start.
You read the plan, you approve or adjust it, then it builds. This catches the “that’s not what I meant” moment while it’s still just a sentence — not after the tool’s been rebuilt.
Your undo button: snapshots
Remember Git from setup — your undo button? You never type its commands. You ask Claude in plain English. The habit is simple: every time the tool is working the way you want, save a snapshot.
After every working version
This is working well. Save a snapshot with git so we can come back to it.
Now you can experiment fearlessly. If a change makes things worse or something breaks, you go back:
When an experiment goes sideways
That made things worse. Undo the last change and go back to the last snapshot.
This is the confidence that lets you try things. Nothing you do is permanent, because a good version is always saved behind you.
Git snapshots are the habit worth building — your permanent, off-machine history. But Claude Code also keeps its own automatic checkpoints as you work, so you can rewind to an earlier point in a session even before you’ve saved a snapshot. Two nets, not one. You still ask in plain English — “go back to how it was before that last change” — and it handles the rest.
Long conversations drift — after a lot of back-and-forth, Claude can lose the thread. When a session starts feeling muddled, start a new one, point it at the same folder, and say: “Read this project and tell me what it does.” It re-reads everything and you’re back on solid ground with a clear head.
One change at a time, describe the screen, plan mode for big moves, and a snapshot after every good version. That’s the whole craft of iterating — the same on a ten-minute tweak or a week-long build.
Watch this step
Plan mode is much clearer once you've watched it — this shows Claude laying out the plan for your approval before it changes anything, exactly the workflow this lesson recommends for bigger changes. It’s from an independent creator — credited below, so go give them a follow.
The Explore Plan Code Commit workflow in Claude Code
More learning resources
Still want another angle? These are hand-picked and vetted to line up with this lesson — from creators and sites worth your time.