DEV Community

Nova
Nova

Posted on

The Change Budget Prompt: Stop Scope Creep in AI-Assisted Coding

#ai #promptengineering #productivity #devtools

If you’ve used an assistant to help with a “quick fix,” you’ve probably seen this pattern:

  • You ask for a small change.
  • It proposes a “better structure.”
  • Suddenly you have a refactor, renamed files, new abstractions, and a broken build.

That’s not because the model is malicious. It’s because scope is underspecified.

A simple way to prevent this is to add a change budget: a hard constraint on how much code is allowed to move.

I call it The Change Budget Prompt.

The idea

Before you ask for the solution, define a budget in terms the model can respect:

  • Max files touched (e.g. 2)
  • Max lines changed (e.g. 30)
  • No new dependencies
  • No renames / no new modules
  • Keep the public API stable

The budget forces the assistant to search for the smallest viable patch instead of the “cleanest” architecture.

Think of it like WIP limits for AI-assisted coding: fewer moving parts means fewer hidden failures.

A copy/paste template

Here’s a template I keep around:

Task: <what you want>

Change budget:
- Touch at most <N> files
- Change at most <N> lines (excluding formatting)
- No renames
- No new dependencies
- Keep function signatures stable unless explicitly required

Output format:
1) Brief plan (2-4 bullets)
2) Patch (diff)
3) Why this stays within budget
4) What to test (commands + key cases)
Enter fullscreen mode Exit fullscreen mode

Two details matter:

1) Define what doesn’t count (e.g. “excluding formatting”) so you don’t waste budget on prettier code.
2) Force a diff. Diffs make “budget violations” obvious.

Example 1: Fix a bug without a refactor

Say you have a Node/Express handler that occasionally returns a 500 when the DB returns null.

Bad prompt:

Fix this handler.

Better prompt (with budget):

Task: Prevent 500s when user is missing. Return 404 instead.

Change budget:
- Touch at most 1 file
- Change at most 12 lines
- No new dependencies
- No renames

Output: diff + tests

Code:
<paste handler>
Enter fullscreen mode Exit fullscreen mode

The budget pushes the model toward:

  • A guard clause (if (!user) return res.status(404)…)
  • A minimal test case

…and away from:

  • “Let’s introduce a UserService class”
  • Reworking middleware
  • Reformatting the whole file

Example 2: Add a feature flag safely

Feature flags are another scope-creep magnet: the assistant wants to centralize config, add libraries, or build a full flag system.

If you just need a small toggle, constrain it:

Task: Add an env flag NEW_CHECKOUT=1. If enabled, route /checkout to NewCheckoutPage.

Change budget:
- Touch at most 2 files
- Change at most 25 lines
- No new packages
- Do not change existing routes

Output: diff + rollback note
Enter fullscreen mode Exit fullscreen mode

The likely result is a single conditional branch plus a short note:

  • How to enable/disable
  • What happens when the variable is missing

That’s exactly what you want.

Example 3: “Improve performance” without rewriting everything

Performance prompts are dangerous because they invite broad rewrites.

Instead of:

Make this faster.

Try:

Task: Reduce allocations in parseCsvRow().

Change budget:
- Touch at most 1 file
- Change at most 20 lines
- Keep behavior identical (including edge cases)

Also provide:
- A micro-benchmark snippet
- A note on complexity tradeoffs
Enter fullscreen mode Exit fullscreen mode

You’re telling the assistant: optimize locally, verify with a benchmark, don’t redesign the world.

Why it works (mechanically)

Most assistants “search” the solution space by generating plausible next steps. With no constraints, they drift toward globally “nice” code:

  • symmetry
  • “clean architecture”
  • new abstractions

A budget changes the objective function. The model starts optimizing for minimal edits and low-risk diffs, which tends to correlate with:

  • fewer regressions
  • easier review
  • easier rollback

In practice, you also get better human ergonomics: small diffs are fast to scan.

Make it even tighter: a two-pass workflow

When the task is tricky, I do this in two passes:

1) Plan pass (budgeted): ask for a 3-bullet plan and a list of assumptions.
2) Patch pass (budgeted): ask for the diff.

That catches misunderstandings early without burning time on code you’ll throw away.

Plan prompt:

Before coding: propose a plan that stays within the change budget.
List assumptions and unknowns.
If the budget is unrealistic, say so and propose the smallest budget increase.
Enter fullscreen mode Exit fullscreen mode

This “budget negotiation” is important: sometimes 12 lines simply isn’t enough, and you’d rather learn that upfront.

Common failure modes (and fixes)

1) The assistant reformats everything.

Add: “Do not change formatting or rename variables unless necessary.”

2) It blows the budget anyway.

Add: “If you can’t stay within budget, stop and ask for permission to expand it.”

3) It makes invisible behavior changes.

Add: “Behavior must remain identical; include a small test matrix.”

4) It ‘fixes’ by deleting code paths.

Add: “Do not remove functionality; preserve existing branches.”

A quick checklist for your next prompt

  • [ ] What is the smallest acceptable outcome?
  • [ ] What must not change?
  • [ ] What’s the max diff you’re willing to review today?
  • [ ] What do you want back (diff, tests, commands)?

If you answer those, you’ll get patches that are boring in the best way.

The Change Budget Prompt isn’t about limiting the assistant’s creativity. It’s about aligning the output with the reality of engineering: small, reviewable changes ship.

Top comments (0)