The AI Change Budget

Why AI Needs a Budget

The old question was "Can I write this change?" The AI-era question is often "How much should I let the assistant change before I stop and inspect?"

That distinction matters. AI can produce a thousand-line diff in the time it takes you to make coffee. The output may compile. It may look stylistically consistent. It may even solve the visible problem. But if the diff is too large to review with real attention, the workflow has quietly moved from engineering to acceptance-by-exhaustion.

A change budget is a boundary you set before prompting. It defines how wide the AI is allowed to edit, how many behaviors can move at once, and what must be true before the change is accepted. The point is not to slow AI down. The point is to keep its speed inside a reviewable shape.

The Four Things That Spend Your Budget

1. Behavioral Surface

A change that alters one visible behavior is easier to review than a change that alters five. Even if the line count is small, broad behavior is expensive. Authentication, billing, permissions, persistence, and error handling all spend budget quickly because a subtle change can affect users in ways the diff does not make obvious.

2. Boundary Crossings

Moving across layers increases risk: UI to API, API to database, sync code to async code, local state to shared state. AI can make those jumps confidently, but each boundary adds a contract that must still be checked. A small diff across three boundaries can be more dangerous than a larger diff inside one component.

3. Validation Strength

Tests increase your budget because they make mistakes cheaper to find. A mechanical refactor with a strong suite can safely be larger. A behavior change with no focused test should be smaller, even when the code looks obvious.

4. Rollback Cost

If reverting the change is easy, the budget can be larger. If the change includes a database migration, data rewrite, payment workflow, customer-visible state, or irreversible side effect, the budget should shrink. "The AI can probably handle it" is not a rollback plan.

A Simple Budget Scale

You do not need a formal scoring spreadsheet. Most changes fit into four useful bands.

Tiny Budget: One File, One Reason

Use this when the change has weak tests, affects sensitive behavior, or you are still learning the code. Ask AI to touch one file, make one behavior change, and stop. This is the safest mode for bug fixes, unfamiliar modules, auth, billing, permissions, and production incidents.

Small Budget: One Slice With Its Test

This is the default for healthy AI-assisted development. Let AI change a file and the nearby test, or a small pair of files that belong together. The test anchors the intended behavior and gives you a cheap validation loop.

Medium Budget: A Contained Refactor

Use this when the behavior should stay the same and you have enough test coverage to catch regressions. Examples include renaming a local concept, extracting a helper, replacing repeated parsing logic, or moving a component into smaller subcomponents without changing its contract.

Large Budget: Mechanical or Disposable Work

Larger AI edits are reasonable when the work is generated, isolated, or easy to throw away: scaffolding a new route, drafting a first version of an internal tool, converting a documented format, or applying a repetitive migration with strong automated checks. Even then, review it in smaller chunks before merge.

When to Cut the Budget Immediately

Some signals mean the next AI prompt should get narrower, not broader.

• The AI changed unrelated files. Restart with explicit file boundaries.
• The explanation sounds generic. Ask it to tie each change to the concrete code path.
• The diff mixes refactor and behavior. Split cleanup from functional change.
• The validation step is vague. Define the exact test, command, or manual path before accepting more edits.
• You are tempted to skim. The budget is already too large for your available attention.

The last point is the quiet one. AI-assisted work fails when the human review loop becomes ceremonial. If you cannot afford to read the diff carefully, you cannot afford that diff yet.

The Change Budget Checklist

Before you ask AI for an implementation, answer these five questions. If any answer is unclear, shrink the request.

This checklist turns "make this better" into an engineering task. It gives the model less room to wander and gives you a sharper standard for accepting the result.

Examples

Too Much Budget

"Refactor the checkout flow, clean up the validation logic, improve error handling, and update the tests."

This bundles product behavior, validation rules, UX states, and tests. If something breaks, you will not know whether the refactor, the error handling, or the test rewrite changed the contract.

Better Budget

"In the checkout form, make the email validation error appear only after blur. Do not change payment submission or server validation. Add or update the smallest test that covers the blur behavior."

This has a single behavior, a clear non-goal, and an obvious check. After it passes, you can budget the next change separately.

Good Large Budget

"Generate a first draft of a new internal admin page in /admin/reports/. It can be rough. Do not connect it to production data yet. Use mock data and keep all changes inside that directory."

This is larger, but it is contained and disposable. The risk is low because it does not alter existing behavior. The review question is not "is this production-ready?" It is "is this a useful draft to continue from?"

Budget Is How You Keep Momentum

The habit feels conservative at first. Then it becomes faster. Smaller AI tasks produce cleaner diffs. Cleaner diffs get reviewed sooner. Focused checks fail with useful information. Rollbacks are less dramatic. You spend less time untangling broad almost-right edits.

The goal is not to make AI timid. It is to make the collaboration legible. Let the model move quickly inside boundaries that you can still reason about.