You found the bug. A date shows in the wrong format, or a button lands in the wrong spot. You describe it to your AI coding tool, hit send, and get back a wall of changes that fixes the date but also renames a function, rewrites a component you never mentioned, and quietly breaks your signup flow. Now you have two problems instead of one.
The issue usually is not the AI. It is the request. A vague ask gives the tool room to guess, and it guesses big. A tight request gives it a narrow job and a way to check its own work. This post gives you a fixed template you can copy, fill in, and reuse for every fix, plus two worked examples on ordinary bugs so you can see the difference between a weak request and a strong one.
If you want the wider picture of how this fits together, this template is one step inside the direct, review, extend workflow behind this template. Here we zoom all the way in on the "direct" part: the actual work order you hand the AI.
The anatomy of a change request that doesn't regress
Think of a change request the way a contractor thinks of a work order. Nobody hands a plumber a note that says "the kitchen feels off." They say what to fix, where, what not to touch, and how you will both know it worked. A good AI request has the same parts.
Five slots do almost all the work:
- Goal. One sentence on the outcome you want, in plain language. Not the code, the result.
- Scope. Where the change should happen: a page, a component, a file if you know it. This is the fence.
- Do-not-touch. The parts that must stay exactly as they are, especially anything to do with logins, payments, or personal data.
- Acceptance test. A specific thing you (or anyone) can click through afterward to confirm it worked. If you cannot describe the test, you do not yet understand the fix.
- Rollback. Your safety net: the backup or revert point you made before sending, so a bad result costs you a click, not a weekend.
The acceptance test is the slot people skip, and it is the one that saves you. When you tell the AI "here is how I will check this," you are giving it a target instead of a vibe. It also gives you a reason to look at the result critically rather than accepting whatever comes back. A related reason these requests go wrong is that the model has no memory of how your app was built, which is worth understanding on its own: here is why the AI that built your app can't just fix it now.
The fill-in template
Copy this. Keep it in a note. Fill the blanks before every fix.
GOAL
In plain language, the one thing that should be different after this change:
______________________________________________
SCOPE
Where this change should happen (page, screen, or file if known):
______________________________________________
Change only what is needed to meet the goal above. Do not refactor,
rename, reformat, or "improve" anything else.
DO-NOT-TOUCH
Do not modify anything related to:
- Login, sign-up, sessions, or passwords
- Payments, checkout, billing, or subscriptions
- Storing, reading, or deleting personal user data
Plus, for this specific request, do not touch:
______________________________________________
If the goal seems to require changing any of the above, stop and tell
me instead of editing it.
ACCEPTANCE TEST
After the change, I will do this and expect this result:
Step: ______________________________________
Expected: ___________________________________
Also confirm nothing else on the same page changed behavior.
OUTPUT
Show me the list of files you changed and a short summary of what
changed in each, before I accept anything.
Two of those slots deserve a note.
The do-not-touch list names auth, payments, and personal-data code by default, every time, even when your fix has nothing to do with them. That is on purpose. Those are the areas where a small wrong edit turns into locked-out users, failed charges, or leaked data, and they are exactly the areas an AI will happily "tidy up" if a file happens to be nearby. A change-request prompt is not the place to modify them. When a fix genuinely needs to touch a login or payment flow, that is your signal to slow down and route it through someone who does this professionally, not to loosen the prompt and hope. Treat that threshold as firm.
The rollback slot is not part of the text you send. It is the thing you do before you send anything: commit your working code, duplicate the project, or use your tool's snapshot or version history so you have a clean point to return to. The template assumes you already have that revert point. If making one is new to you, build the habit alongside this one, because it is what makes a bad AI edit a non-event.
Example 1: a small bug fix, weak vs strong
The bug: on your customer list page, the "joined" date shows as 2026-03-09T00:00:00Z instead of a friendly date like March 9, 2026.
Weak version:
The dates look ugly, can you fix how they show up?
This is an invitation to sprawl. "Fix" is undefined, "ugly" is a feeling, and there is no boundary, so the AI is free to reach into a shared date helper used across ten screens, or reformat every date in the app, and you have no test to catch what it broke.
Strong version:
GOAL
On the Customers page, the "Joined" column should show a friendly
date like "March 9, 2026" instead of the raw 2026-03-09T00:00:00Z.
SCOPE
The Customers list page only. If a shared date function is involved,
add a display format at this page rather than changing the shared
function, unless changing it is clearly safer, in which case explain
first.
DO-NOT-TOUCH
[default auth / payments / personal-data block]
Plus: do not change how dates are stored or sent to the server.
Only change how this one column is displayed.
ACCEPTANCE TEST
Step: Open the Customers page and look at the Joined column.
Expected: Each row shows a date like "March 9, 2026".
Also confirm the sort order of that column still works and no other
page's dates changed.
OUTPUT
List the files you changed and what changed in each before I accept.
Same bug. But now the AI knows the outcome, the fence, the forbidden zones, and how you will grade it. If it proposes editing a shared helper that touches other screens, your scope line makes it flag that instead of silently doing it.
Example 2: a copy or styling change that should touch one file
The change: your homepage headline says "Sign up free" and you want it to say "Start for free." A two-word copy edit. These feel too small for a template, which is exactly why they cause trouble. An unscoped "change the wording" request can send the AI hunting through several files for related strings.
Weak version:
Change the sign-up wording to "Start for free" everywhere it makes sense.
"Everywhere it makes sense" hands the judgment to the model. It might rewrite button labels in your checkout, your emails, and your account settings, and now you are auditing five screens for a headline tweak.
Strong version:
GOAL
The main homepage headline should read "Start for free" instead of
"Sign up free". Nothing else.
SCOPE
Only the homepage headline. This should be a single text change in
one file. Do not change any other buttons, labels, or pages, even if
they have similar wording.
DO-NOT-TOUCH
[default auth / payments / personal-data block]
Plus: do not change any signup button behavior or links. Text only.
ACCEPTANCE TEST
Step: Open the homepage.
Expected: The headline reads "Start for free". Every other button and
label reads exactly as before.
OUTPUT
Show the one file you changed and the before/after text.
The "single text change in one file" line is the whole point. You are telling the AI how big the change should be, so a result that touches six files is an obvious red flag before you accept it.
How to set the do-not-touch boundary when you don't know the codebase
You do not need to know your file structure to draw a fence. You can draw it by capability instead of by filename.
Describe the areas in the terms you already understand:
- "Anything that logs a user in or out."
- "Anything that charges a card or manages a plan."
- "Anything that saves, shows, or deletes a person's name, email, or address."
- "Anything on pages other than the one I named."
Then add one instruction that covers the gap in your knowledge: "If you are unsure whether a file falls into a do-not-touch area, stop and ask me before editing it." That single line converts your uncertainty into a checkpoint instead of a gamble. The AI can see the file names you cannot, so you are asking it to respect a boundary described in plain terms and to pause when it is not sure. This is also the safest way to grow into bigger edits over time; for a fuller treatment of scoping fixes so they stay contained, see how to give a change request that doesn't break everything.
One honest caveat that belongs on every request: a template reduces regressions, it does not eliminate them. The AI can still misread scope or make a change that looks fine and behaves badly. That is why the last line of every request asks for the list of changed files, and why you read that diff before you accept. The template makes the change reviewable. You still have to review it.
Before you send: a 60-second pre-flight check
Run this quick pass before every request. It is faster than cleaning up a bad edit.
- Do I have a revert point? Committed, duplicated, or snapshotted. If not, make one now.
- Is my goal one sentence about a result? If it describes code or lists three things, split it.
- Did I name the scope? A page, screen, or file. Not "the app."
- Is the do-not-touch block in there? Auth, payments, personal data, plus anything specific to this fix.
- Can I state the acceptance test as a click and an expected result? If I cannot, I do not understand the fix well enough to send it yet.
- Did I ask for the list of changed files? So I can review before accepting.
If all six are yes, send it. If any is no, that is the part of the request most likely to bite you.
In Plain English
What this is: a fixed, fill-in-the-blank work order for asking an AI coding tool to make a fix, with five slots (goal, scope, do-not-touch, acceptance test, rollback) that keep the change small and checkable.
Who it helps: a non-technical builder who already shipped an app and keeps getting sprawling AI edits that break working features from vague requests.
When to use it: every time you ask an AI to change existing, working code, especially for "small" fixes and copy tweaks, which are the ones that quietly spread. Do not use the ad-hoc prompt path at all for login, payment, or personal-data changes; route those to a professional.
What to do next: copy the template into a note, fill it in for your next bug, make your revert point, run the six-step pre-flight, send it, and read the list of changed files before you accept anything.
Grab the templates
Keep a filled-in version handy so every fix starts from a scoped work order instead of a vague ask. You can copy the ready-made Change-Request Templates and browse the rest of the Direct AI hub for the surrounding habits. This template is the "direct" step inside the larger Direct, Review, Extend workflow; once your requests are scoped, the review step is what catches the regressions a template cannot.
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.