You asked the AI to fix a typo on your pricing page, and somehow it also rewrote your navigation, renamed a function three files away, and changed how your signup form validates email. Now you have a bug you didn't have this morning, and you can't tell which of those "improvements" caused it.
That sprawl usually isn't the AI misbehaving. It's the prompt. A vague request gives the AI permission to roam, and it will happily touch anything it decides is relevant. The fix is not a magic phrase that never regresses. It's a small set of reusable phrasing patterns that constrain what the AI is allowed to change, force it to explain itself first, and keep the edit reviewable before any code moves.
This post gives you four named patterns you can copy, adapt, and reuse across whatever tool you're in. Each one prevents a specific failure. Together they turn "please fix this" into a scoped, reversible instruction. They pair directly with the direct, review, extend workflow that this post sits under, and with the fill-in change-request template when you want the scoping baked in from the start.
Why Phrasing Controls Blast Radius
"Blast radius" is just how far a change reaches. A small blast radius means the AI touched one file, one function, one line. A large one means it edited things you never mentioned. The wider the radius, the harder it is to know what broke and the harder it is to undo.
The AI decides that radius largely from how you phrase the request. Ask "make the checkout better" and you've handed it an open-ended mandate. It will interpret "better" broadly and refactor whatever it feels like. Ask "in the checkout total function, fix the rounding so 19.99 plus 5.00 shows 24.99, and change nothing else," and you've drawn a fence.
None of this replaces judgment. A tightly-worded prompt still produces code you have to read, and it does not make risky edits safe (more on that below). But phrasing is the cheapest lever you have. It costs nothing, works in every tool, and stops most of the sprawl before it starts. The four patterns below are the fence-drawing moves worth memorizing.
Pattern 1: Explain Before You Change
The first pattern doesn't ask for code at all. It asks for a plan.
Before the AI edits anything, have it describe what it intends to do and why, in plain language, and then stop. You read the plan, catch a bad approach, and only then let it proceed. This turns a silent rewrite into a decision you get to make.
Copyable phrasing:
Before you write or change any code, explain your plan: which files and functions you'd touch, what you'd change in each, and why. List anything you're unsure about. Do not edit anything yet. Wait for me to confirm.
The failure it prevents: The AI takes a wrong approach and you only discover it after the code is written and half-applied. By then, unwinding it is more work than it was worth. When the plan is wrong, you catch it in a sentence instead of a diff.
This pattern matters most when the request is fuzzy or the app area is unfamiliar to you. If the AI says "I'll add a new global state variable and rewire three components to read from it," and all you wanted was a label change, that's your signal to say "no, do the smallest version instead." You caught a bad approach before a single line moved. If the plan reads sensibly, you approve it and continue.
Pattern 2: Scope It to One File or One Function
The second pattern names the boundary explicitly. You tell the AI the exact place it's allowed to work and forbid it from wandering.
Left to its own judgment, an AI will "helpfully" fix things it notices along the way. Sometimes that's fine. Often it means a one-line fix drags in changes to unrelated code, and now your simple edit is a sprawling one you can't fully review.
Copyable phrasing:
Only change the function
calculateShippingincart.js. Do not modify any other function, file, import, or config. If the fix seems to require touching something outside that function, stop and tell me instead of doing it.
That last sentence is the important part. You're not just naming the scope, you're telling the AI what to do when the scope feels too small: surface it, don't silently expand it. Sometimes the real fix genuinely lives elsewhere, and you want to know that, not have it quietly done for you.
The failure it prevents: A tidy edit that spreads across files you didn't mean to open, so a bug that appears later could be hiding in any of them. Keeping the edit to one place keeps the diff it produces short enough to actually read.
Scope by function when you know exactly where the logic lives. Scope by file when you're less sure but can name the neighborhood. Either way, you've capped the radius.
Pattern 3: Propose, Don't Apply Yet
The third pattern separates writing the code from applying it. You ask the AI to show you the exact change as a proposal you can read, and to hold off on committing it to your files.
Some tools apply edits automatically the moment they're generated. That's convenient right up until it isn't, because it collapses "here's an idea" and "it's now live in your app" into one step. This pattern re-inserts the pause.
Copyable phrasing:
Show me the proposed change as a diff or a clearly-marked before-and-after. Do not apply it to my files yet. I'll review it and tell you whether to proceed.
The failure it prevents: Code lands in your app before you've read it, so you're now reviewing something that's already running instead of deciding whether it should. If the proposal looks wrong, you reject it and nothing in your app ever changed.
This pattern stacks naturally with Pattern 1. Explain-before-you-change gets you a plan; propose-don't-apply gets you the actual code for that plan, still held at arm's length. Both give you a checkpoint. Neither writes to your files until you say so.
Even here, a proposal that looks reasonable is not proof it's correct. It's a chance to catch obvious problems (wrong file, unrelated changes, a deleted line you needed) before they're live. The real review still happens on the applied diff.
Pattern 4: Preserve This Behavior While You Fix That
The fourth pattern protects what already works. You name the existing behavior you care about and make keeping it a hard requirement, not something the AI has to infer.
When you ask for a fix, the AI focuses on the thing you pointed at. It doesn't automatically know that the same function also handles a case you rely on. So it optimizes for your stated goal and quietly breaks the unstated one. Stating the constraint out loud closes that gap.
Copyable phrasing:
Fix the bug where the discount code field rejects lowercase codes. While you do this, the field must still reject empty submissions and still apply the existing 10% member discount exactly as it does now. Do not change either of those behaviors. If your fix would affect them, tell me before proceeding.
Notice what you did: you didn't just describe the fix, you listed the things that must survive it. "Still reject empty submissions" and "still apply the member discount" are protected by name. The AI now has to work around them instead of over them.
The failure it prevents: A regression, where fixing one thing silently breaks another that used to work. This is the single most common way AI edits go wrong, and it's the whole reason the add a feature without breaking the rest approach leans so hard on stating what must stay intact.
You won't always know every behavior worth protecting, and that's fine. Name the ones you can think of, especially anything a user touches: forms, logins, prices, saved data. The more of your app's real behavior you make explicit, the less the AI has to guess.
A Boundary These Patterns Do Not Cross
Well-worded prompts control sprawl. They do not make dangerous edits safe.
If the code you're editing handles authentication (logins, sessions, passwords, permissions), payments (charging cards, subscriptions, payouts), or personal data (anything about a real user), a tidy prompt does not lower the stakes. Scoping an edit to one file doesn't make that file safe to change. A confident-sounding proposal for your login logic can still introduce a hole you can't see.
For those three areas, the honest threshold is this: if you can't personally verify the change is correct and safe, route it to a qualified professional before it touches production. That's not a failure on your part. It's the same judgment a careful engineer uses. These patterns keep your everyday edits scoped and reviewable. They are not a substitute for professional review of security, payment, or data code, and no prompt phrasing is. (Educational, not legal or security advice; verify sensitive changes with a qualified professional for your situation.)
Combining Patterns Into a Single Safe Edit Prompt
You don't have to pick one. The patterns are additive, and for anything nontrivial you'll stack them. Here's what all four look like in a single prompt:
I want to fix the bug where the discount field rejects lowercase codes.
First, explain your plan before writing any code: which function you'd change and how. Don't edit anything yet.
Once I confirm, only change the discount validation in
checkout.js. Do not touch any other file or function. If the fix needs something outside that, stop and tell me.The field must still reject empty submissions and still apply the existing member discount exactly as it does now.
Show me the change as a diff before applying it. I'll review and tell you whether to proceed.
Read that back and you can see each fence: explain first, one file only, preserve two behaviors, propose don't apply. Adapt the specifics to your app and tool. There's nothing tool-specific in the wording, so it travels.
Here's how the four map to what each one buys you:
| Pattern | What you say | Failure it prevents |
|---|---|---|
| Explain before you change | "Describe your plan first, don't edit yet" | A wrong approach you only catch after the code is written |
| Scope to one place | "Only change this function, nothing else" | An edit that sprawls across unrelated files |
| Propose, don't apply | "Show me the diff, don't apply it yet" | Code going live before you've read it |
| Preserve behavior | "These existing features must still work" | A fix that silently breaks something else |
One more thing that no combination changes: after the AI applies the edit, you still read the resulting diff before you accept it. A well-scoped prompt makes that diff short and honest. It doesn't make reading it optional. The prompt narrows what could go wrong; the diff review confirms what actually did.
In Plain English
What this means: How you word an edit request largely decides how much of your app the AI changes. Four reusable phrasings, explain-before-you-change, scope-to-one-place, propose-don't-apply, and preserve-behavior, keep edits small, reversible, and explained before anything moves.
Who it helps: Any non-technical builder directing an AI tool to edit an app they already shipped, especially anyone whose "quick fix" requests keep turning into changes they can't fully track.
When to use it: Every time you ask an AI to change existing code. Use one pattern for a trivial edit, stack all four for anything that touches logic users depend on. For auth, payment, or personal-data code, use them and still get a professional to review before it ships.
What to do next: Copy the combined prompt above, swap in your own file and behavior names, and keep it somewhere you can paste it. Then make reviewing the applied diff your non-negotiable last step.
Where to Go Next
These patterns work best when scoping is already part of how you describe every change. Pair them with the Change-Request Templates so the constraints are built into your prompt from the first word, and browse the Direct AI hub for the rest of the direct-review-extend workflow. Some tool links across the site may be affiliate links, disclosed on our disclosure page.
Some links in Kodbe content may be affiliate links, disclosed on our disclosure page. Kodbe is independent and not affiliated with any tool mentioned.
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.