The "what not to change" section: the cheapest fix for AI coding agents that quietly break things

The scariest failure with an AI coding agent is not the one that throws an error. It is the one where the agent hands you code that runs, passes a quick glance, and quietly solves a slightly different problem than the one you had. Obvious failures you catch in seconds. This one you find in production, three days later, when something you never asked it to touch has changed.

I keep seeing the same root cause, and it has almost nothing to do with the model. It is the brief.

Why "make it better" goes wrong

When you hand an agent a loose instruction like "clean up this file" or "add caching here," you have not actually told it where the edges are. The model fills the gap with its own guess about scope. Usually that guess is reasonable. Sometimes it rewrites a function three files over, renames a variable that something else depended on, or "helpfully" swaps your logging library because it looked outdated. Each of those is defensible in isolation. Together they are a diff you now have to audit line by line, because you no longer trust that the change stayed inside the box you had in your head.

The model was not being careless. You never drew the box.

The habit: say what not to change

The fix is almost embarrassingly small. Alongside what you want done, write a short explicit list of what must stay untouched, plus the exact files or targets in scope. Two or three lines is enough:

Add a retry with backoff to the fetchOrders call in api/orders.ts.
Do not change the function signature, do not touch other files, do not add new dependencies.
If a retry still fails after 3 attempts, throw the existing OrderFetchError.

That is the whole trick. You have turned a fuzzy ask into something with edges. Now the output is checkable: either it stayed inside the box or it did not, and you can tell at a glance instead of reading every line with suspicion.

Notice what the "do not" lines are really doing. They are not there because the model is dumb. They are there because every unstated assumption is a place the model is free to improvise, and improvisation is exactly what you do not want in a change you have to trust.

Specificity beats cleverness

There is a bias, especially early on, toward writing clever prompts. Long, elaborate instructions, role play, "you are a senior engineer who cares deeply about clean code." Most of that does far less than one boring line naming the exact file and the exact thing not to touch.

The reason is simple. A clever prompt tries to make the model want the right outcome. A specific brief removes the room for the wrong one. The second is more reliable because it does not depend on the model reading your mind, it depends on you having said the quiet part out loud.

This is also the fastest way to get better at working with any coding agent, Claude included. The skill that actually transfers is not memorizing syntax or prompt tricks. It is learning to write a brief tight enough that you can check the result against it in seconds. Once you can do that, the model stops being a slot machine and starts being a tool you point.

A quick before and after

Before:

Refactor the checkout logic, it is getting messy.

After:

In checkout/total.ts, extract the discount math into a pure function applyDiscount(cart, code).
Keep the public behavior of getTotal identical, same inputs and outputs.
Do not touch the tax logic, do not reformat the rest of the file, do not add libraries.
If code is invalid, return the cart total unchanged, same as today.

The "before" invites the model to redesign your checkout. The "after" gets you one clean, reviewable change and nothing else. Same model, same day, completely different level of trust in the result.

Where this leads

Once the "what not to change" habit is automatic, a lot of downstream pain disappears. Your diffs shrink. Your reviews get faster because you are checking a small, bounded change against an explicit spec instead of reverse engineering the agent's intent. And you stop getting those quiet, three-days-later surprises, because there was never room for the agent to wander in the first place.

It is a small habit with an outsized payoff, and it is the kind of thing that is obvious once you have been burned by the alternative. If you are learning to build with Claude, this is one of the first instincts worth drilling: not a better prompt, a tighter box.