When AI Keeps Rewriting Working Code: Four Causes
When AI keeps rewriting working code, the cause is usually your context, not stubbornness. Four causes ranked by frequency, each with its own fix.
When AI keeps rewriting working code, it is almost never because the model dislikes your style. It is because something in its context told it the rewrite was wanted, and that something is usually fixable in one line. Four causes account for nearly all of it.
The symptom is familiar. You ask for a bug fix in one function. You get back a diff touching nine files, a renamed helper, a new abstraction layer and a reformatted config. The bug is fixed. Everything else is now different, and you have to review all of it to find out whether anything broke.
Cause 1: the request was wider than you meant it
The most common cause by a distance, and the least satisfying to hear.
"Fix the date parsing in the invoice export" reads to you as a surgical instruction. To a model it reads as a goal, and models pursue goals. If the date parsing is tangled with three other things, fixing it "properly" means untangling them, and a helpful agent will do exactly that.
The fix is to state the boundary as explicitly as the goal:
Fix the timezone bug in parseInvoiceDate in src/export/dates.ts.
Change only that function. Do not rename anything, do not change
the signature, do not touch other files. If the fix requires
changes elsewhere, stop and tell me what and why instead of
making them.That last sentence does most of the work. Without an escape hatch, a model that believes the change is necessary will make it. With one, it has a sanctioned way to raise the problem rather than solve it.
Cause 2: your repo tells it to
Agents read configuration and convention files, and they follow them. If your repository carries an instruction file saying the codebase prefers functional components, or that all modules should use dependency injection, the agent will apply that preference to any file it opens, including files that predate the rule.
This surprises people because the instruction was written for new code and is being applied to old code. The model has no way to know the difference unless you say so.
Check for instruction files, linter configs with autofix enabled, and formatter settings that rewrite on save. Then add the missing clause: these conventions apply to new code, existing files are migrated deliberately and not as a side effect of unrelated work. Agent skills are worth auditing for the same reason, since a skill that instructs cleanup will cheerfully clean up.
Cause 3: AI keeps rewriting code it cannot verify
A model that cannot verify behaviour has to infer it, and code it does not understand looks like code that is wrong.
This shows up most with unusual-looking code that exists for a reason: a deliberate loop instead of a map because of an allocation issue, a manual check instead of a library call because the library was wrong about a leap year, a retry that looks redundant and is not. The agent sees something that looks like a mistake and corrects it.
Two fixes, both cheap. First, a comment saying why, placed above the odd code, because the next reader is now a model and models read comments. Second, a test that fails if the behaviour changes, which converts "looks wrong" into "provably required". A model that runs your tests gets told it was wrong, and this is a large part of why agents rewriting tests is so damaging: it removes the only mechanism that pushes back.
Cause 4: the context ran out and it started over
The rarest of the four and the most confusing when it happens.
On a long task, an agent that exhausts its context window may compact or drop earlier parts of the conversation, including your constraints. What comes back is an agent working from a partial picture, re-deriving decisions you already made, and rewriting code it no longer remembers agreeing to.
The signature is temporal: the first twenty minutes were fine and the last ten produced churn. If you see that shape, the problem is not the instruction, it is the window. Running out of context mid-task covers the recovery, and the structural fix is smaller tasks with clean boundaries rather than one long session.
A diagnostic order
Work the causes in this sequence, because each is cheaper to check than the next:
**Re-read your own request.** Did you state a goal without stating a boundary? Most of the time, yes.
**Grep the repo for instruction files.** Anything an agent reads at startup is an instruction you are giving on every task without noticing.
**Check whether tests ran.** An agent that skipped the suite has no evidence the old code worked, and whether it actually ran them is worth confirming rather than assuming.
**Look at the timeline.** Churn concentrated at the end of a long session points at context, not instructions.
The habit that prevents most of it
Ask for a plan before a diff. "Tell me which files you intend to change and why, then wait" costs one extra round trip and surfaces an overreaching plan while it is still text rather than a diff you have to unpick.
It also gives you a cheap moment to say "no, only the first one", which is a far easier conversation than reviewing nine files to work out which three mattered. The wider patterns behind this are covered in why AI writes code that does not work and the coding tools guide.
Sources: Google's guidance on reviewing machine-generated changes carefully is consistent with its long-standing engineering practices documentation.
How did this land?
About the author
Developer Advocate
Steve builds something with Swarmz every week and writes up what worked, what broke, and what he'd do differently. Tutorials and hands-on guides are his lane.
