Do not change prompt pattern for safe, small iterations

Why small changes often break other parts

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.

What the “do not change” prompt pattern is

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:

• Flows (user journeys): the steps users take and what screens appear.
• UI and UX details: layout, spacing, field order, button placement, and interactions.
• Business rules and data behavior: validation rules, pricing math, permissions, database writes, and API responses.

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.

The basic template you can reuse

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.

How to freeze critical flows without being vague

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:

• Flows to freeze: Login, Signup, Checkout, Settings (no new steps, no reordered screens)
• Edge cases to freeze: back button outcomes, error messages, empty states, refresh behavior
• Data behavior to freeze: what is saved, when it is saved, and where it appears after reload
• Security to freeze: permissions, auth checks, rate limits, no new public endpoints
• Performance to freeze: no extra API calls in these flows, response time not worse than current

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.

How to freeze UI and UX details

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:

• Keep identical: routes/screens, navigation order, and back button behavior
• Keep identical: layout grid, spacing, fonts, colors, and component states
• Keep identical: all text and labels except: <the one string>
• Mobile rules: keep current behavior at <breakpoints>, do not reflow other sections
• Output: describe every UI change you made, and list files/components touched

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.

How to freeze business rules and data behavior

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.

Spell out the rules that must not change

Instead of “keep pricing the same,” pin it down:

• Pricing: exact formula, rounding (up/down), currency, tax/VAT behavior, and when discounts apply
• Permissions: which roles can create, edit, delete, approve, refund, export, or view sensitive fields
• Statuses: allowed states and valid transitions (and what triggers them)
• Calculations: totals, commissions, credits, limits, and any caps or minimums
• Data writes: what tables/records are created or updated, and what must stay immutable

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).

Step-by-step: making one safe change request

Treat a tiny update like a mini contract. The pattern works best when the change is narrow and everything else is explicitly frozen.

1. 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.

2. 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.

3. 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.

4. 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.

5. 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:

• Only the requested behavior changed
• Frozen flows and screens still match
• Business rules and data writes are unchanged
• Tests (or manual steps) pass as written
• No “cleanup” commits slipped in

This works especially well in Koder.ai: paste the freeze list into Planning Mode, have it echo constraints, then generate the smallest patch.

Common mistakes that still cause drift

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:

• Being abstract: you protect intent, but not the click-by-click flow and expected results.
• Missing edge cases: empty states, loading states, validation errors, permission denied, offline behavior.
• Bundling changes: two or three tweaks in one request makes tradeoffs likely and regressions harder to spot.
• Not defining “identical”: same UI layout, same API calls, same database writes, same emails/notifications, same analytics events.
• Approving by vibe: it “looks fine” without verifying key paths.

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:

• Run the main flow end to end (the one you froze).
• Trigger at least one error state and one empty state.
• Check permissions (admin vs regular user) if relevant.
• Confirm side effects: records created/updated, notifications sent, and logs/metrics unchanged.

If any of those differ, the request was missing a frozen detail, not “bad coding.”

Example: a small UI tweak without changing the workflow

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:

• Flow freeze: submit still creates an account, shows the same validation messages, and sends the user to the same next screen.
• UI freeze: page layout, spacing, colors, and the position of the button stay the same.
• Data freeze: backend payload keys and types do not change; the stored value for company size remains the same format as before.
• Business rules freeze: required fields remain required, and the button remains disabled until the form is valid.
• Analytics freeze: the same tracking event names fire on submit and on validation errors.

Acceptance checks you can run in minutes:

• Button text shows “Continue” everywhere (default, loading, disabled state).
• Company size is a dropdown with the same default as before.
• Submitting still reaches the dashboard and the account is created.
• Existing users editing their profile still see the saved company size correctly.
• No new warnings or failing tests in the signup area.

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).

Quick checklist before you approve the update

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.

5 fast checks (10 minutes)

Run these checks in the same order each time. It keeps reviews calm and makes regressions easier to spot.

• Critical flow still completes end-to-end: Start from the same entry point a real user uses (login, landing page, dashboard) and finish the main task.
• UI looks identical except the intended change: Open the key screens you froze. Scan layout, button labels, spacing, and navigation.
• Business rules still match reality: Spot-check 2 to 3 cases that often break, like a discount calculation, a role permission, or a status transition.
• Data shape is unchanged: Confirm there are no new fields, renamed fields, removed fields, or migrations.
• Integrations are untouched: Confirm there are no endpoint changes and no payload changes (field names, required fields, status codes).

When to revert and re-issue the prompt

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.

Next steps: apply it in Koder.ai for safer iterations

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.

Start with a quick planning pass

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.”

Protect each iteration with snapshots

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:

• Make a snapshot: “Before - change button label only”
• Run the planning pass and confirm the freeze list
• Request the one change and ask for a brief diff-style summary of what changed
• Verify with your checklist (UI, flows, rules, data)
• Make a snapshot: “After - verified”

Reuse the same pattern across the stack

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.