See what a change will touch before you say yes¶

Verified: 2026-10-13

In developers' words: The plan, the diff, small commits

By the end of this level you read the list of files a change will touch before you say yes, you make one commit per change, and when something breaks you type one sentence to find which change did it.

TIME: 5 MINPROMPTS: 3 + 4CODE: 0

The moment

"Which change broke it?"¶

You asked for a green button. The button went green, and the login stopped working. You never asked for anything near the login. Something in that one change touched it, and you have no idea what, because you said yes to the whole thing without seeing what was in it. The only move you know is "try again", which is one more change you cannot see. That is how a two-minute ask costs an afternoon.

Developers never say yes to a change they have not read. They ask for the plan first, the files a change will touch, like the ghost of a block before you place it. They keep each commit to one thing. And when something breaks they read the diff: what changed since the last commit that worked. Your AI does all three, if you ask. Three sentences.

Why this matters

A change you did not read can touch anything¶

The AI changes what it thinks you meant, not what you said. "Make the button green" can reach the login, because the AI decided the two shared a colour. You will never know unless you ask to see the list first.
One big change has no "which". Three things in one commit is three places to look, and no way to undo one without the other two. One thing per commit, and "which change broke it" has one answer.
"Try again" is a second guess on top of the first. Every retry on a broken app adds more changes you have not read. The list of what changed is the only thing that tells you where to look. Without it you are guessing, right alongside the AI.
You can't avoid it. "Plan", "commit", "diff": your tool says these words every day, and so does anyone you ask for help. Better to learn them now, on purpose, than later, with the login down.
Five minutes now, or an afternoon later. After this, "which change broke it" costs you one sentence.

The map

The level in one picture¶

1THE PLACEMENT GHOST

before you say go: the files it will touch

Button.tsxthe colour you asked for
styles.cssthe green
Login.tsxyou never asked about this
a file you never asked about: ask why first

2ONE BLOCK PER SAVE

one change per dated save, named for it

v1-worksTue 6 Oct
it worked
footerWed 7 Oct
1 file
button colourWed 7 Oct
3 files
broke: loginToday
login fails

3WHAT CHANGED SINCE V1-WORKS

one line per file, with the save it came in

Button.tsx"button colour"
styles.css"button colour"
Login.tsx"button colour" · the one

One box per word: the plan is 1, a commit is 2, the diff is 3. The red file is the one.

Step 1

Ask what a change will touch before you say yes¶

The plan is every file the AI means to change, and why, before it changes anything. The example asks for a green button; put the change you actually want in its place, or keep it. If every file on the list is one you would expect, type "go". Nothing changes until you do.

Prompt: Make the button green. Before you change anything, show me the plan: every file you will change for this and, for each one, one plain sentence on why. Then wait for my OK.

✓ A short list of file names with a reason each. For a button colour, one or two files with "button" or "style" in the name. A file with "login", "auth", "database" or "config" in its name is your signal: ask "why that one?" before you say go.

Before
Your ask, in a sentence. Nothing has changed yet.
▼
After the prompt
The plan: the files the change will touch, each with a reason, waiting for your go.

Step 2

Say go, and commit that one change on its own¶

Small commits: one change per commit, so when something breaks there is one block to take out. This step makes the change you read, nothing else, and commits it with a message that says what it was.

Look at it first if you can: on Lovable and Bolt.new in the preview, on Claude Code and Cursor by asking "run it so I can look at it". Can't check it? "Commit it anyway" is allowed.

Prompt: Go. Change only what is on the list, nothing else, even if you notice something you would improve. When it is done, commit it with the message button colour, put it on GitHub, and tell me the short id.

✓ One line with a short id, like b2c3d4e button colour, and one change in it. Asked to install some pieces before it can run? Say yes, that is normal, then open the address it gives you.

Before
The list you read, and your go.
▼
After the prompt
One commit, one change, named for what it was, next to v1-works on GitHub.

Step 3

When it breaks, ask for the diff since the last good commit¶

The diff is every file that changed since v1-works, and the commit each one came in with. Developers read the raw one; you ask for it in plain words, and the file names do the work.

Replace the part in angle brackets, brackets included, with what you saw, in your own words, like "it says wrong password for everyone". Nothing broken yet? Write "nothing broke, just show me" in its place.

Prompt: Something broke: <what you see>. Show me the diff since v1-works in plain words: one line per file that changed, and for each file, which commit it came in with. Don't fix anything yet.

✓ One line per file, each with the commit it came in with. A commit is named for what you asked, not what it touched: a login file inside "button colour" is the one. Long list? Ask "which of these could affect <the broken part>?"

Before
Your commits since v1-works, and a broken app. Which one did it?
▼
After the prompt
One line per file. The login file came in with the button colour commit. That is the one.

Keep that sentence. It is your "which change broke it", and the one line on this page to remember: "what changed since v1-works, and which commit did each come in with?"

Your turn

Ask for two things at once, and watch the list catch it¶

v1-works and button colour are both on GitHub, so nothing here can cost you anything. Ask for two things in one commit, the thing this level says not to do, and watch what it does to the diff. Four prompts, one at a time.

Prompt 1: Change my home page's headline to the word TEST and, in the same change, rename the contact page's button to SEND. Before you change anything, show me the plan: the files you will touch, one sentence each. Then wait for my go.

Two files, on two pages. Two things in one plan: already two places to look.

Prompt 2: Go. Commit it with the message test and send, on this computer only, not on GitHub.

A short id with test and send. On this computer only, so prompt 4 can throw it away without touching GitHub.

Prompt 3: Show me the diff since v1-works in plain words: one line per file, and which commit did each come in with?

Both files under test and send, and the button files under button colour. Now imagine the headline broke: two files in one commit, and the diff cannot tell you which. That is why one thing per commit.

Prompt 4: Put every file back exactly as it was just before the test and send commit, and throw that commit away, so my history looks as if it never happened.

It may ask permission for a command with "reset" or "hard" in it. Say yes if the commit it names is test and send: it changes only your computer, that commit never went to GitHub, and button colour stays.

Prompt 1
The plan lists two files on two pages, before anything changes.
▼
Prompt 2
Two changes in one commit called test and send, on this computer only.
▼
Prompt 3
Both files under one commit. If one had broken, the diff could not say which.
▼
Prompt 4
The test and send commit is thrown away. button colour stays, one change, as it should.

That is the whole habit. Next Tuesday, when the login breaks after three changes, you type "what changed since v1-works, and which commit did each come in with?" and a file name tells you where to look.

The limit

The list tells you where to look, not what to fix¶

One limit. The diff names the file and the commit it came in with. It does not say what inside that file went wrong, or promise it was the only cause. From there you have two moves: ask for a fix in that file only, or go back to the commit before it and redo the colour on its own. Level 4 is for when the fix itself keeps missing.

If it didn't work

Common problems¶

A file I never asked about is on the list.
That is the level working. A file with "auth", "login", "database" or "config" in its name, for a button colour, means the AI decided to change it while doing what you asked. Ask "why that one?" before you say go, and "what is that file for?" if the name means nothing to you. Verified 2026-10-11.
It changed things first and explained after.
Don't accept it yet. Ask "undo that, and this time show me the plan first and wait for my OK". If the change is already in, step 3 still works on it.
It bundled two things into one change.
Not committed yet? Ask for two commits, one per thing. Already one commit? Leave it, and ask for one thing at a time from now on.
It keeps improving things I didn't ask for.
Put this sentence at the top of every prompt: "Change only what I ask for."
The diff is long.
That is the lesson: too much happened between commits. Ask "which of these could affect <the broken part>?" to narrow it. Then commit, so the next diff is short. Verified 2026-10-11.
It showed me code instead of words.
Say "in plain words, no code, one line per file". The raw diff is for developers; the file names are what you need.
It refused the "reset" command.
Ask "put the files back the way they were just before test and send and drop that commit, without that command". A refusal can cancel the other things it was doing in the same breath, so ask what it did before the refusal, and for one step at a time.
On Lovable and Bolt.new.
The plan shows in the chat as the change is made, so step 1's "wait for my OK" may not hold; read it anyway, and ask "why that one?" after. Their version history is your line of commits, one per change if you ask for one thing at a time. Step 3 works the same. Not yet tested there.

The words

Each thing on this page, with its three names¶

In the game	Developers say	Plain
the placement ghost	`the plan`	the list of files a change will touch
one block per save	`small commits`	one thing per save
a save	`commit`	every file, right now, dated
(no game word)	`a diff`	what changed since a save
a file in the world folder	`Login.tsx`	a page of your app, named after the page

Next · Level 3 "Don't test on your users." Try every change on a copy first.

THE FRAME
Developers say	In the game	Plain
`the developer`	the player	YouYou give the orders and check the work. The controller never changes hands.
`the agent, the assistant`	the character you give orders to	Your AI tool: Lovable, Bolt, Cursor, Claude CodeFast and tireless, and it guesses what you meant. When it guesses wrong, level 4 is the way out.
`the project`	your world	Your app: the folder of files you are buildingNot the chat and not the editor. It can be saved, copied and moved, and every move in this course keeps it safe.
`the platform defaults, rollback`	autosave	The platform’s own undoIt saves when it wants, in one slot with no name, and writes over it. Fine until the day it isn’t.
`process, developers’ habits`	the strategy guide	The five habits in this courseWhat developers do so that losing work stops happening. One per level.

LEVEL 1 · A SAVE POINT
Developers say	In the game	Plain
`a repository, on GitHub`	your save files	A copy of your app on GitHub, under your own accountIt lives outside the platform, so nothing the platform does can write over it. Every commit goes here.
`a commit`	a save	A snapshot of your app: every file as it is at one moment, with a date and a messageThe tool gives each commit a short id like a1b2c3d. Level 2 keeps each one to a single change.
`a tag`	the save’s name	A name you put on a commit, like v1-worksMany commits say “working”. The tag is the one you ask for by name, and still recognise in three weeks.
`“go back to v1-works”`	load	Go back to a commit, by its tag“Go back to v1-works” puts every file back as it was then. It brings back the app, never the data.
`rollback`	autosave	The platform’s undo buttonIts autosave: one slot, no name, written over. Not a commit, and not yours.

LEVEL 3 · TRY IT ON A COPY
Developers say	In the game	Plain
`your users`	the guests	The people who use your appThey use what you built, get stuck, and leave if it is broken. Everything you try, you try in front of them, unless there is a preview.
`publishing, going live, deploying`	opening the gates	Sending a change to the live copyOnce it is published, your users see it. The preview comes first.
`a preview, a staging environment`	practice mode, the gates closed	A second copy of your app at its own address, where nothing countsBuilt from its own line of commits, with its own test database. Every change goes here before it is published.
`production`	the gates open	The live copy of your app, the one your users are inWhatever is published here is real. Nothing here is a test.
`an environment variable`	the copy’s world settings	A setting that says which database, email service or payment provider a copy of the app usesOne line like DATABASE_URL, set per copy. It decides where a form’s data went; the green tick does not.
`the database`	the guest book	Where your app keeps what your users typedTables of rows on the platform’s servers. A commit never holds it, so going back to v1-works never touches it.

LEVEL 4 · STOP AFTER TWO TRIES
Developers say	In the game	Plain
`an attempt`	one death	One fix: your order, and everything the AI changed in answerTwo that fail is the limit. The third is a fix of the fix.
`the error message, the stack trace`	the death message	The line the tool printed when it brokeThe closest thing you have to the cause. Read it before you try again.
`reset to the save point`	load the save	Go back to v1-works after two failed attemptsThe attempts were never committed, so they go. The original problem is still there, on its own, without the two new ones.
`/clear, a new chat`	a fresh run	A new chat that has not seen the two failed attemptsIt remembers nothing, so tell it: the commit you are at, the error message, the two attempts, and “don’t repeat those”.
`the loop`	the death loop	Try, try again, worse each timeEach attempt is built on the last broken one. The way out: stop, reset, new conversation.
`a bug report`	a guest’s complaint	A user’s “it broke”, in their wordsAn error message you did not see yourself. Read it the same way, then the same three moves.

LEVEL 5 · A COPY YOU OWN
Developers say	In the game	Plain
`the project folder`	the world folder	Your app as a folder of filesOn the platform’s servers it is theirs to keep or lose. In your repository it is yours.
`a private repository you own`	your world on your own drive	A repository under your own GitHub account that only you can seeNot an organisation with the platform’s name on it. Check the owner on github.com, signed in as yourself.
`an export, a backup`	a copy of the guest book on your own drive	The database copied to a file: every table, every rowThe only copy of your users’ data that you hold. Once, to learn what it leaves out, then on a schedule.
`an off-platform backup`	your own drive	Kept somewhere that is not the platform: your own computer or your own cloud driveA backup that lives on the thing it backs up goes down with it.
`code is versioned, data is not`		Going back to a commit brings back your app, never its dataThe one place your app is not like a game save. The export is the answer.