By the end of this post you will have a short set of habits for asking an AI coding tool to change a working project so that the working parts stay working. None of them require reading code. All of them are about how you phrase the request and what you do immediately after.
The problem the habits solve
An AI coding tool does not know which parts of your project are precious. It sees files. If it decides a file would be better rewritten, it may rewrite it while doing something else, and it may not mention it. The habits below exist to give the model the information it lacks, and to catch the cases where it ignores that information anyway.
Habit one: say what must not change
Every request should name the thing you want and the things you are protecting.
Weak: "Add a pause menu."
Better: "Add a pause menu that opens on Escape. Do not change player movement, the save system, or anything in the audio files. If the pause menu needs something from those areas, tell me first instead of changing them."
A stated boundary is something the model can follow. An unstated one does not exist.
Be specific about what you protect. "Don't break anything" is not a boundary. "Do not edit player.js" is.
Habit two: ask for a plan before any edit
Before the model touches a file, ask it to describe what it intends to do.
"Before changing anything, tell me: which files you will edit, what you will change in each, and anything else you think needs to change to make this work. Do not make the changes yet."
Then read the plan. You do not need to understand the code to notice that a request for a pause menu has produced a plan involving six files and a rewrite of the input system. When the plan is bigger than the request, ask why. Often the model will say the extra work is optional, and you can strike it. Sometimes it is genuinely necessary, and now you know before it happens rather than after.
Only when the plan matches what you asked for do you say go.
Habit three: one change at a time
Bundling requests is the fastest way to lose track.
"Add a pause menu, fix the enemy wall bug, and make the coins spin" is three changes in one edit. If something breaks, you do not know which of the three did it.
Ask for the pause menu. Test it. Confirm the game still works. Then ask for the wall fix. Each step should be small enough that if it goes wrong, going back is cheap and the cause is obvious.
Habit four: ask what else was touched
After every change, ask directly.
"List every file you modified, and for each one, what changed. Include anything you changed that I did not ask for."
The last sentence matters. Models tend to report the requested change and omit incidental ones unless asked. When you ask explicitly, the incidental ones usually surface.
Compare the answer to the plan from habit two. If the plan said two files and the answer says four, ask about the extra two before you do anything else.
Where you can, check the answer against reality. Most tools show which files changed. Your file explorer shows modification times. If the AI says it did not touch a file and the file was modified a minute ago, the AI is wrong, and you want to know that now.
Habit five: test the thing you asked for, then the things you did not
Run the new feature. Then run the parts that were supposed to be untouched. Jump, shoot, save, load, open menus. This is where unrequested rewrites are caught.
If something that used to work no longer does, say so immediately and precisely, before asking for anything else. "After the pause menu change, the double jump no longer works. It worked before this change. What did you change in player movement?" The model can act on a specific report. It cannot act on "something's off".
Habit six: keep a copy before every request
Before you ask for a change, make sure a copy of the current working version exists somewhere the model cannot edit. Copy the project folder and name it with the date and a short note. Or use a version control tool if you have one. Or use anything else that keeps a snapshot.
The rule is never to ask for a change to the only working copy.
Habit seven: write down why it works
When a feature finally works after a long struggle, write one or two sentences about it in a file the model will see next session. "The boss phase transition depends on the value near line 212. Do not change it. Took many attempts to tune."
The model does not remember the struggle. Next session it will see the boss code cold, and a note it can read is the only thing standing between it and a helpful simplification that undoes an evening's work.
Putting it together
A request that follows all seven habits looks like this.
You copy the working project folder. You write: "Add a pause menu on Escape. Do not change player movement, saving, or audio. Before editing, tell me which files you will change and what you will change in each." You read the plan, strike anything extra, say go. Afterwards you ask what was touched, including anything unrequested, and compare it to the plan. You test the pause menu, then the double jump, then saving. If it all works, you write a line about what the pause menu depends on. Then you ask for the next thing.
This is more ceremony than "add a pause menu". It is also the difference between a project that survives its fiftieth change and one that does not.
More guides
This is one of a series of plain-language guides to building with AI coding tools. See all guides.
Ask Aquila