On this page
Three things, in this order: bound the scope before it starts, make it prove the change rather than describe it, and keep one working version you can return to. The problem is almost never that the model is stupid. It is that nothing told it what it must not touch.
Why does it change things you did not ask about?
Two reasons, and neither is a bug.
The first is that it was trained on good practice, and good practice says you improve what you touch. Inconsistent naming, a duplicated block, an old pattern next to a new one — a competent developer tidies those. So does the agent, helpfully, in the same commit as your one-line fix.
The second is that it cannot tell which parts of your project are fragile. You know that one file is held together with tape and must not be breathed on. To the agent it is just a file, and a slightly untidy one.
Put those together and you get the classic session: you ask for a change to one screen, you get a change to one screen plus a rename in four others, and now something unrelated is broken and you do not know which of the twelve changes did it.
How do you bound the scope before it starts?
One sentence, before the work, not after:
That last clause matters more than it looks. Without it you get compliance and silence — it obeys, and the thing it noticed goes unmentioned. With it you get the observation without the edit, which is what you actually wanted.
Two more boundaries worth setting by default:
- No new dependencies without asking. Installing a package is the single change with the widest blast radius, and it is also where agents invent things that do not exist. The research on that is worth ten minutes.
- No changes to anything you cannot easily undo. Database structure, deployment settings, anything involving money or login. Explain first, wait for a yes.
The full prompt I use for this, with the reasoning behind each clause, is on change only this file.
The whole list
68 tools, what each costs and when you actually need it. Updated twice a year.
How do you tell whether it actually worked?
By refusing to accept a description.
An agent will tell you the change works. It is not lying — it is predicting what a finished task looks like, and a finished task is usually described as working. That sentence costs it nothing and tells you nothing.
The rule that fixes it:
The difference in practice is stark. Asked to describe, an agent reports success. Asked to run it and paste what came back, it often discovers the failure itself and fixes it before you have read the message. You have not become a better reviewer; you have moved the check to before the claim instead of after it.
Longer version, with the prompt: prove it works.
What do you do when it goes in circles?
Stop at the second repeat. Not the fifth.
The pattern is easy to spot once you know it: the fix does not work, so it tries a variation of the same fix, then another variation. That is guessing with confidence, and each round leaves residue in your code — a defensive check here, a try/catch there — so that even when it eventually works, you are left with three attempts' worth of debris.
What to say instead of "try again":
This changes the mode from generating to reasoning, and very often the answer is "I do not actually know where it fails" — which is the real problem, and now it is visible. More on that in stop going in circles.
What should stay out of reach entirely?
| Keep away from | Why |
|---|---|
| Production data | an undo does not exist there |
| Secrets and keys | once read, assume they are elsewhere too |
| Deployment commands | a broken deploy is public immediately |
| Database structure changes | easy to write, expensive to reverse |
None of this means working with fear. It means recognising that the cheap failures are the ones you can undo, and keeping the expensive ones behind a confirmation.
Does this go away with a better model?
Not so far, and not for the reason people assume.
A more capable model is better at the task and equally uninformed about your intent. It still does not know that the file is fragile, that the naming is deliberate, or that you would rather have a small ugly change than a large elegant one today. That is context, not capability, and no amount of capability substitutes for it.
Which is why the fix is structural rather than a matter of finding the right words. Set the boundaries once, in a file the agent reads every session, and you stop repeating yourself — that is how to brief an agent once.
What this looks like in a real session
Roughly:
- Commit first. Whatever state it is in, get it into GitHub before the agent starts.
- Name the file, name the change, name what is off limits. One message.
- Read the diff. Not every line forever, but always for anything touching data, money or login.
- Ask for evidence, not a summary.
- At the second repeated failure, switch it to diagnosis.
- Commit again the moment it works.
Steps 1 and 6 are the ones people skip, and they are the ones that turn a bad afternoon into a thirty-second git reset.
The Operator Prompt Pack
60 prompts for working with an AI coding agent, built around the three things it measurably gets wrong. €9, PDF, instant download.
Tools in this piece
| Tool | What it does | Price |
|---|---|---|
| Claude Code | An AI agent in your terminal that reads your files, edits them, runs commands and deploys. | ~€17–20/mo |
| Cursor | A code editor with AI. The step between browser builder and terminal. | ~$20/mo |
| GitHub | Version control. Your restore point when an hour of building goes wrong. | Free |
| Supabase | Database, accounts and file storage in one, with no backend work. | Free tier |
| Vercel | Hosting. Puts a project live on a real address with one command. | Free tier |
Every tool has its own page with the price, who should skip it and what to check before paying. Some links are affiliate links.
Questions people ask
How do you stop an AI agent changing files you did not ask about?
Name the file and say what is off limits in the same message. Agents treat nearby code as fair game unless told otherwise, because tidying is usually helpful. One sentence — change only this file, do not refactor or rename anything else — removes most of it.
Why does an AI agent rewrite code I did not mention?
Because it was trained on work where improving what you touch is good practice, and because it cannot tell which parts of your project are fragile. Without a boundary it optimises for the code being better, not for your change being small.
How do you check that an AI agent's change actually works?
Make it show the output rather than describe it. Done means it ran the thing and pasted the real result — the test output, the response, the screenshot. A description of success is not evidence of success, and models produce confident descriptions easily.
What do you do when an AI agent keeps trying fixes that do not work?
Stop at the second repeat, not the fifth. Make it state what it believes is wrong, what evidence it has, and what single test would prove it. Repeated variation is a sign it is guessing, and more attempts make the code worse while burning your budget.
Should you let an AI agent commit to version control by itself?
Commit often yourself, at every point where things work. Version control is what makes a bad change cost seconds instead of an evening, and it matters more as you trust the agent more, not less.