You ask the AI to move a button, and somehow the login page stops working. You ask it to change the wording on an email, and the checkout form starts throwing an error. Nothing you asked for was risky. So why did three other things break?
Most of the time, the AI is not the problem. The request is. A vague ask gives an agentic coding tool a wide lane, and a wide lane means it feels free to rewrite, reorganize, and "improve" things you never mentioned. The fix is not a better tool or a secret prompt. It is scoping: telling the AI exactly what to change, exactly what to leave alone, and how you will both know it worked.
This post shows you how to write a change request that fences in the work, so you get one clean edit instead of a cascade of new bugs. It is a practical companion to the fill-in change-request template, and it fits inside the wider habit of the direct-review-extend loop for working with AI-generated code.
Why vague requests produce broken apps
An AI coding tool does not know which parts of your app are load-bearing and which are safe to touch. It only knows what you told it and what it can infer from the code. When your request is broad ("make the dashboard nicer," "fix the signup flow"), the AI has to guess at scope. Guessing means it may refactor a shared function, rename a variable that something else depends on, or "clean up" code that was quietly holding the app together.
Every extra edit the AI makes is another place something can go wrong. A change that touches one file is easy to reason about. A change that touches eight files, half of which you did not expect, is where regressions hide. So the goal of a good request is simple: give the AI the smallest possible job and the least possible room to wander.
Three things do most of the fencing:
- Scope — one change, one place, named exactly.
- Boundaries — a clear list of what must not change.
- Acceptance test — a plain statement of what "done" looks like.
The rest of this post is those three things in detail, plus a before-and-after rewrite.
A note before you start: none of this replaces a backup. Even a one-line change can go sideways, and the whole point of scoping is that you are still in control if it does. Make sure you can undo the change (a commit, a snapshot, or your platform's version history) before you send the request. Small requests still get their own backup.
Scope one change at a time and name the exact file or screen
The single most effective habit is to ask for one change per request. Not two related tweaks. Not "while you're in there, also...". One.
Batching changes feels efficient, but it makes problems hard to isolate. If you ask for three things and something breaks, you cannot tell which of the three caused it, and neither can the AI. If you ask for one thing and something breaks, you know exactly where to look. When you want several changes, do them in sequence: request, review, accept, then start the next one.
Then name the target. Point the AI at the specific file, screen, or component you mean. You do not need to know the code to do this. You can describe it in the terms you already use:
- "On the Account Settings screen..."
- "In the file that handles the contact form (I think it's
ContactForm)..." - "The 'Reset password' email that goes out when someone clicks 'Forgot password'..."
If you are not sure which file that is, that is a fine first request on its own: "Which file controls the Account Settings screen? Don't change anything yet, just tell me." Naming the target does two things. It stops the AI from hunting through unrelated code, and it forces you to get specific about what you actually want, which is often where vague requests fall apart.
Set explicit "do not touch" boundaries
This is the part most people skip, and it is the part that prevents collateral damage. After you say what to change, say what to protect.
The "don't touch X" pattern works because it converts your worry ("please don't break checkout") into an instruction the AI can follow. Left unstated, the boundary does not exist for the tool. Stated plainly, it becomes a rule it can hold itself to and a rule you can check the result against.
Name the areas you care about most, especially anything involving money, logins, or personal data:
- "Do not change anything in the payment or checkout code."
- "Do not modify the login or signup logic."
- "Do not touch the database schema or any existing data."
- "Do not rename existing functions, files, or variables."
- "Do not reformat or 'clean up' code you are not directly changing."
That last one matters more than it looks. A lot of noisy, hard-to-review changes come from the AI reformatting whole files it happened to open. Telling it to leave untouched code alone keeps the resulting change small and readable.
You are not guaranteeing the AI will obey perfectly. It might still stray, which is exactly why you review the result (more on that below). But a stated boundary dramatically narrows where it is allowed to go, and it gives you a checklist to verify against afterward. Boundaries reduce the blast radius; they do not remove the need to look.
State the acceptance test up front so you both know when it's done
An acceptance test is a plain-English description of what success looks like, written before the work starts. It answers one question: how will I know this change worked without reading the code?
You can write one without any technical knowledge, because it describes behavior you can see:
- "When I click 'Save' on the settings page, I should see a green 'Saved' message and the page should not reload."
- "After this change, the contact form should still send me an email, and the confirmation text should now read 'Thanks, we'll reply within one business day.'"
- "The date on each order should show as 'July 18, 2026' instead of '2026-07-18'. Nothing else on the orders page should change."
Stating the acceptance test up front does three useful things. It makes you clarify what you actually want, so you catch a fuzzy request before the AI does. It gives the AI a target to aim at instead of a direction to drift in. And it gives you a concrete thing to check afterward: you click through the steps and see whether the described behavior happened. Success becomes something you can confirm by using the app, not by trusting the AI's summary of its own work.
A good acceptance test usually has two halves: what should now be true, and what should still be true. The "still be true" half is where you catch regressions early.
Ask for the smallest change and the reasoning, not a rewrite
How you frame the request shapes how much the AI does. If you say "redo the pricing page," you are inviting a rewrite. If you say "change only the second paragraph on the pricing page," you are inviting a surgical edit. Ask for the smallest change that satisfies your acceptance test.
Two phrases help a lot:
- "Make the smallest change that does this." This nudges the AI away from ambitious refactors and toward a minimal edit.
- "Before you change anything, tell me what you plan to change and which files it will affect." This gives you a chance to catch an over-broad plan before any code moves. If the AI says it needs to touch six files to change one label, that is your signal to stop and ask why.
Asking for the reasoning is not about understanding every line. It is about sanity-checking the scope. A change that should be small but comes back large is a red flag worth pausing on, whether or not you can read the diff.
Once the change is made, do not accept it on faith. Look at what actually changed and confirm it matches what you asked for and stayed inside your boundaries. If reading a diff feels intimidating, that is a learnable skill on its own, and it is the single best defense against a request that quietly did more than you wanted. Here is how to review the diff before you accept it. The diff is where you find out whether the AI respected your "do not touch" list.
A before-and-after: a bad request rewritten into a safe one
Here is a request the way most people first write it:
"The signup page looks bad and the welcome email is confusing. Fix the signup page and clean up the email, and make everything look more professional."
Look at what is wrong with it. It bundles two unrelated changes (signup page and email). "Looks bad" and "more professional" are not checkable. There are no boundaries, so the AI is free to touch the signup logic, the styling system, and anything it decides looks unprofessional. There is no acceptance test, so nobody knows when it is done. This is the kind of request that comes back having also restyled your entire app and, occasionally, having broken the signup form it was told to "fix."
Now the same intent, scoped. First, split it into two requests and do the signup one first:
Change: On the signup page only, increase the spacing between the form fields so they are not cramped, and change the button text from "Submit" to "Create account."
Do not touch: Do not change the signup logic or what happens when the form is submitted. Do not modify any other page. Do not change the app's overall styles or theme. Do not rename or reformat anything you are not directly editing.
Acceptance test: After the change, the signup page fields should have visible breathing room between them, and the button should read "Create account." Submitting the form should still create an account exactly as it does now, and every other page should look unchanged.
How to work: Make the smallest change that does this. Before you edit anything, tell me which file(s) you will change and confirm you are not touching the submit behavior.
Then, as a separate request afterward, do the welcome email with its own scope, boundaries, and acceptance test.
The second version is longer, and that is the point. Every extra sentence is a fence. The AI now knows exactly what to change, exactly what to protect, and exactly what "done" means. You have turned a vague wish into a job with edges. You can grab ready-made versions of this structure from the Change-request templates so you are not rewriting the scaffolding each time, and you can find more on steering AI tools at the Direct AI hub.
This same discipline is what lets you add a feature without breaking the rest of your app, because a feature is just a change request with a bigger scope and even more reason to draw boundaries first.
In Plain English
What it means: A change request that does not break things is one where you name exactly what to change, list what the AI must not touch, and state how you will know it worked, all before any code moves. You are trading a vague wish for a fenced-in job.
Who it helps: Non-technical builders directing an AI coding tool who keep getting side effects they did not ask for, and who cannot read the code well enough to spot the damage until something visibly breaks.
When to use it: Every time you ask an AI tool to modify a working app. It matters most when the change is near money, logins, or personal data, where an unwanted edit is expensive. For anything touching payments, authentication, or personal data, treat this as the floor, not the ceiling, and bring in a qualified professional to review before you ship if you are unsure. This is educational guidance, not security or legal advice for your specific situation.
What to do next: Pick one change you have been putting off. Write it out in four parts (change, do not touch, acceptance test, how to work), back up your app, send it, and review the diff before you accept.
Common questions
Does scoping guarantee the AI won't break something? No. It reduces the room the AI has to wander and gives you a clear boundary to check against, but no phrasing prevents every regression. That is why the backup and the diff review are non-negotiable, not optional extras.
Isn't writing all this slower than just asking? It is slower to write and much faster overall. A two-minute scoped request that lands cleanly beats a ten-second vague one that spawns an afternoon of hunting for what broke.
What if I don't know which file to name? Ask the AI to tell you first, with an explicit "don't change anything yet." Identifying the target is a fine standalone request, and it is safer than letting the tool guess.
Your next step
Take the four-part structure from this post and keep it where you can reach it. Grab the reusable Change-request templates in the toolkit, keep them beside your editor, and fill one in the next time you are tempted to type a one-line ask. A little scoping up front is the difference between one clean edit and a week of surprises. For the bigger picture on directing, reviewing, and extending AI-generated code, start with the direct-review-extend loop.
Kodbe is an independent commercial publication about maintaining and owning software built with AI or no-code tools. It is not affiliated with Kodbe Inc, Kodobe, Kodable, or Kodu.