Dec 11, 2025·7 min
Do not change prompt pattern for safe, small iterations
Learn the do not change prompt pattern to make one small update while freezing key UI flows, business rules, and critical behavior so nothing else drifts.
Learn the do not change prompt pattern to make one small update while freezing key UI flows, business rules, and critical behavior so nothing else drifts.
A “small” change rarely stays small. You ask to tweak one button label, and suddenly a page layout shifts, a form stops validating, or a checkout step behaves differently. Apps are connected systems. UI, logic, data, and integrations all lean on each other.
A frequent cause is unclear boundaries. If a request says “make the signup simpler,” the builder (human or AI) has to guess what “simpler” means. Guessing leads to extra edits: removing fields, changing steps, adjusting copy, or rewriting validation. Another cause is hidden dependencies. A tiny UI change might reuse a component that appears in five other screens.
A safe iteration means you get the one intended improvement while everything else stays effectively identical. For a non-technical team, that means the workflow still feels the same to users, support scripts still match the product, and reporting still makes sense. For a technical team, it means no unexpected changes to routes, data shapes, API contracts, or edge-case behavior.
To make that possible, you have to freeze what must not move. In practice, that usually includes critical flows (the exact steps users go through), UI and UX details (layout, spacing, interaction behavior), business rules (pricing, permissions, validation), data behavior (what’s stored and when), and integrations (analytics events, emails, payments, external APIs).
This “do not change” prompt pattern reduces risk by removing guesswork and keeping the change scoped. It’s not a guarantee. You can still get drift if the original behavior is poorly defined, if the change touches shared components, or if you don’t verify the result. The goal is fewer surprises and faster approvals.
The do not change prompt pattern is a simple way to ask for one specific update while clearly locking everything else. You name the one change you want, then you write a short freeze list of the parts that must stay identical after the update.
This matters because models often try to be helpful by refactoring, renaming, reorganizing files, or “cleaning up” logic while they touch the code. Even if the output still works, those extra changes can introduce bugs, change behavior, or make reviews harder.
Compare these two requests:
“Make the settings page better.” This invites design changes, new copy, layout shifts, and logic tweaks.
“Change only the label text from ‘Phone’ to ‘Mobile phone’. Do not change layout, validation, or the save behavior.” This is narrow, testable, and safer.
A solid freeze list usually covers three areas:
When you use this pattern in a chat-based build tool like Koder.ai, iterations tend to move faster because the model focuses on the single edit instead of making broad “improvements” you didn’t ask for.
This pattern works best when your request reads like a tiny contract: one clear goal, a frozen list of what must stay identical, and a few checks to confirm the result.
Copy this template and fill in the brackets. Keep it short, but specific.
Goal (one sentence):
- Change: [describe the one small change you want]
Context (1-3 sentences):
- Current behavior: [what happens today]
- Desired behavior: [what should happen after]
DO NOT CHANGE (must remain identical):
- Critical flows: [e.g., sign up -> checkout -> receipt stays the same]
- UI/UX that must not move: [e.g., button location, labels, navigation order]
- Business rules: [e.g., pricing, permissions, validation rules]
- Data behavior: [e.g., database schema, stored fields, migration rules]
Constraints (limit drift):
- Scope: [only this screen / only this endpoint / only this component]
- Files/modules (if known): [list a couple, or say “only touch what’s necessary”]
- No refactors: do not rename, reorganize folders, or change formatting beyond the touched lines
Acceptance checks (how I will verify):
1) [a simple before/after check]
2) [a user path that must still work]
3) [a rule that must still hold]
Output requested:
- Provide a brief diff-style summary: what changed, where, and why
- Call out any risk or unclear requirement before implementing
A concrete example: if you want to change a checkout button color, your goal is “Update the primary checkout button color to #1A73E8.” Your DO NOT CHANGE items should freeze the full checkout flow, the button text, and the pricing calculation.
If you’re using Koder.ai, this format also makes reviews quicker because you can compare the acceptance checks against the preview and the change summary before you approve anything.
When you ask for a small change, don’t just say “don’t break anything.” Name the exact user journeys that must behave the same, from first click to final result. You’re not freezing the whole app, you’re freezing the parts where regressions hurt.
Start by listing the critical flows in plain language: login (including password reset), onboarding, checkout, settings. For each flow, state what “done” looks like. Example: “User can log in with email + password, lands on Dashboard, and stays signed in after refresh.”
Then lock down the edge cases people forget. Back button behavior is a classic source of drift: “Back from Checkout returns to Cart (not Home), and cart items remain.” Call out error states (“wrong password shows the same message”), empty states (“no projects shows the same empty screen copy”), and loading states (“spinner appears within 200ms, no layout jump”).
If performance and security expectations matter, freeze those too. If you don’t mention them, the model may “improve” things by adding extra requests, new logging, or changing auth checks.
A tight way to specify this without writing a novel:
Be specific about data flow in one sentence per item. For example: “Address is saved only after pressing Save, stored in the user profile record, and must persist after logout/login.” That level of detail prevents accidental autosave, new fields, or timing changes that break real users.
UI drift usually happens because the model “helpfully” cleans up styles, spacing, or component structure. The fix is the same as with business logic: name what must remain identical, and name the one thing that’s allowed to change.
Pin down the visible structure. Call out layout (columns/rows, header and footer placement), spacing rules (padding, gaps, alignment), and component behavior (hover, disabled state, loading spinners, error messages). If a component has a specific feel, say it plainly: “Button size, radius, and color must stay exactly the same.”
Responsive behavior needs explicit rules. If you don’t mention mobile, tools may “improve” it. State the breakpoints you care about and what must happen at each one: stacking order, hidden elements, fixed bars, and tap targets.
Also freeze words. Tell the model that all copy, labels, placeholders, and helper text must stay unchanged, except the one label you’re editing. This prevents silent rewrites that change meaning.
A compact prompt you can paste into a change request:
If you can, ask for before/after screenshots. If screenshots aren’t available, request a short “UI diff” description (what moved, what resized, what changed color) so you can approve with confidence.
Business rules are one of the easiest places for a small UI change to create a quiet regression. A label update can accidentally change a calculation, a status transition, or who can see a record. Treat rules and data behavior as frozen contracts.
Start by naming the few rules that would hurt most if they drifted. Write them like tests: inputs, outputs, and who is allowed to do what.
Instead of “keep pricing the same,” pin it down:
Add one numeric example to remove interpretation. For example: “Order subtotal $120, discount 10% (applies before tax), tax 8.25% on discounted amount. Expected total = (120 - 12) * 1.0825 = $116.91. Rounding to 2 decimals only at the final total.”
Call out role-based visibility, not just actions. Example: “Support agents can view order status and customer email, but must not see full card details. Only admins can issue refunds.”
If validations matter, freeze them explicitly. Mention the exact trigger and the user-facing message: “If start date is after end date, block save and show: ‘End date must be after start date.’ Do not change this wording.”
Don’t forget side effects outside the app. If you send emails, webhooks, or call third-party APIs, freeze what must stay the same: event names, payload fields, timing (immediate vs delayed), and idempotency behavior (no duplicate sends on retry).
Treat a tiny update like a mini contract. The pattern works best when the change is narrow and everything else is explicitly frozen.
Write the change as one testable sentence. “On the settings page, add a toggle to enable dark mode” is testable. “Improve the settings UI” isn’t. If you can’t test it in 30 seconds, it’s still too broad.
Write a freeze list for the parts that would hurt if they drifted: the user flow, key UI elements, business rules, data behavior, and any APIs or database tables that must remain the same.
Add acceptance checks plus a quick test plan. This is where you prevent “it works on my side” surprises. Include checks like: the new toggle appears, existing settings still save, and nothing else on the page moves.
Before any editing begins, ask the assistant to repeat your constraints back to you. Make it confirm what will change and what must stay identical. If the summary is off, fix the prompt before you allow changes.
Request the smallest possible implementation: no refactors, no renaming, no formatting passes, no dependency upgrades. You’re buying one change, not a makeover.
A short review checklist:
This works especially well in Koder.ai: paste the freeze list into Planning Mode, have it echo constraints, then generate the smallest patch.
Most “small” edits go wrong for the same reason: the request protects the goal, but not the behavior. A model can hit your goal in a new way that quietly changes screens, logic, or data.
One common trap is freezing the outcome (“make onboarding smoother”) instead of the exact steps users take. Another is writing “keep everything the same” and assuming the system knows what that means.
Mistakes that most often cause drift:
A small example: you ask to “make the button more visible” and freeze the color, but forget to freeze the disabled state. The update might always enable the button, changing behavior in a way you only notice later.
What helps is getting specific about what cannot move. Before you accept the update, do a quick regression pass:
If any of those differ, the request was missing a frozen detail, not “bad coding.”
A common safe iteration is a small UI polish where the workflow can’t change.
Scenario: a founder has a simple signup screen with a short form (Name, Email, Company size) and a primary button that submits the form and then routes users to the dashboard.
Exact change request (one sentence): “Rename the primary button from 'Create account' to 'Continue' and change the 'Company size' field from a free-text input to a dropdown.”
Now apply the pattern by freezing what must stay identical:
Acceptance checks you can run in minutes:
A good assistant response should restate the frozen items, confirm any ambiguity (for example: exact dropdown options and what value gets stored), and then produce only the minimal code/UI change needed. It should also call out what it deliberately did not touch (routing, validation logic, payload shape).
Before you accept a “small change,” do a fast pass that looks for silent drift. The goal isn’t full QA. It’s to confirm the app still behaves the same everywhere you said “do not change,” except for the one intended edit.
Run these checks in the same order each time. It keeps reviews calm and makes regressions easier to spot.
Revert if any frozen item changed, even if the app “still works.” A changed label, a new field, or a slightly different rule is a sign the model took extra liberty.
Re-issue the request with tighter constraints: restate the single change in one sentence, list the frozen flows and screens by name, and add “no schema changes, no endpoint changes, no behavior changes outside X.” If you’re using Koder.ai, taking a snapshot before you test makes rollback a one-step decision when something drifts.
If you’re building in Koder.ai, the do not change prompt pattern works best as a habit: one small change, everything else locked, and a clear way back if anything drifts.
Before you ask for the change, switch to Planning Mode and have the assistant restate your scope in plain words. Ask it to repeat two things back to you: (1) the exact change, and (2) a clear freeze list (flows, UI details, and business rules that must not move).
A planning prompt that works well: “Restate my request. Then list what must not change. If anything is unclear, ask questions before editing.”
Treat every change request like a checkpoint. Create a snapshot before you apply the update, then another snapshot after you verify it. If something breaks, rollback is faster than trying to patch over a bad change.
For example, you might be adjusting a button label in a React screen. The change looks tiny, but it can still shift spacing, trigger a rerender, or break an automated test. A snapshot lets you compare behavior and revert quickly.
A simple workflow:
Koder.ai can generate web (React), backend (Go + PostgreSQL), and mobile (Flutter). The pattern stays the same even though the code differs. Freeze the parts that define behavior, not just the files.
If you’re changing a backend endpoint, freeze the request/response shape, validation rules, and data writes. If you’re changing a mobile screen, freeze navigation order, field defaults, and error messages. If you’re changing database logic, freeze what existing rows mean and keep migrations safe.
Copy your template, run one small change today, and verify it with the checklist before you accept the update. Keep the template text and swap in the next change request, one at a time.
Use it whenever you want one specific change and you care that everything else stays the same. It’s especially useful for checkout, auth, billing, or any flow where small drift creates real user issues.
Because parts of an app share components, data, and rules. A tiny UI edit can touch a reused component, which can shift layouts elsewhere, alter validation, or change API payloads without you noticing until later.
Write one clear goal, then list what must remain identical after the change. The key is to freeze behavior (flows, rules, data, integrations) and visible UI details, not just say “don’t break anything.”
Keep it short but specific: critical flows, UI/UX details that must not move, business rules, data behavior, and integrations. If you can’t name what must stay the same, the model has to guess, and guessing causes drift.
Scope it to the smallest area that still protects you. For example, freeze the checkout flow and its shared components, but don’t freeze the entire app if you’re only changing a label on one screen.
Name the journeys step-by-step and define what “done” looks like. Add the common edge cases like back button behavior, error messages, empty states, and refresh behavior so the flow stays identical in the places users notice most.
Explicitly freeze layout structure, spacing, component states (hover/disabled/loading), and all copy except the one string you’re changing. Without that, models may “clean up” styles or rewrite text in ways that change meaning or layout.
Freeze contracts: request/response shapes, validation rules, permissions, calculations, and what gets stored and when. Add one numeric example for sensitive rules like pricing so there’s no interpretation during implementation.
Ask for acceptance checks you can run fast, plus a brief diff-style summary of what changed and where. Then verify the frozen flows end-to-end, trigger at least one error state, and confirm data/integrations didn’t change.
Take a snapshot before the change, run a planning pass that repeats the scope and freeze list, then apply the smallest patch. After verifying, snapshot again so rollback is one step if anything drifted.