The "fixed one, broke another" loop

why it happens and how to get out

What it is

A familiar picture: you fixed error A and B appeared. You fixed B and A came back. A third lap, a fourth, and it starts to feel as if the code is resisting.

The loop is not bad luck. It has three causes, and all three can be removed.

Why it happens

Cause 1. The AI cannot see the whole

Every change is made locally: this function, this error. That the function is also called in three other places with different expectations — the AI does not know, unless it was shown.

So a change that is correct in itself breaks the neighbours.

Cause 2. The symptom is being fixed

If every time you patch the crash site rather than the cause, the error does not go anywhere — it moves. It pops up somewhere else, under another name, and looks new (articles 2.12, 2.13).

Cause 3. The session's context is contaminated

By the fifth lap the conversation holds three abandoned solutions, two wrong assumptions and a pile of code that is no longer current. The AI leans on all of it and starts contradicting itself.

How to get out

Stop and write it down

The first and most useful thing is to stop asking for changes and write out what is known. Five lines of ordinary text:

A: crashes on an empty city — fixed twice
B: duplicate records — appeared after the first fix of A
In common: both are about the save_sub function
Not checked: whether save_sub is called from two places

Often the loop ends right there: the shared link becomes visible.

Pin the behaviour down with tests

While there is no check, every change trades one error for another blind. Two tests — one for A, one for B — turn guesswork into work: now you can see when both are fixed.

Write two tests: one reproducing A, one reproducing B.
Both must fail against the current code. Don't fix the code.

The requirement that both must fail matters — it proves the tests really check the right thing (article 4.6).

Narrow the zone

If the changes touch half the project, each of them disturbs something extra. Explicit boundaries (article 3.13) sharply reduce the number of collateral breaks:

Change only save_sub. If the task can't be done without
touching anything else, stop and say what else needs changing.

Start a new session

If this is the third lap and the answers contradict each other, the problem is a contaminated context. A new session with a clearly stated task and fresh code is almost always faster than a sixth lap in the old one.

What to carry into the new session: the current code, both tests, the note from the first step. What not to carry: the history of failed attempts.

What to tell the AI

When you suspect a change will disturb something extra:

Is this function called anywhere else? If so, what in those
places breaks from the change you're proposing?

When the loop has already set in:

We've been fixing this three times: first A, then B, then A
again. Don't propose a change. Tell me what these two errors
have in common and what single cause could produce both.

The ban on proposing a change is essential. Without it the AI produces a fourth version of the code instead of an analysis.

What to look for

Each change bigger than the last. The first is three lines, the second twenty, the third a new module. A sign the wrong thing is being fixed; the size grows from attempts to go around rather than solve.

"Now it definitely works." After the third lap that sentence means nothing until there is a test.

The errors take turns. A and B appear alternately, never together — almost certainly they share one cause and one place.

Changes in different files. If one error is fixed now here, now there, the cause has not been found once.

Cheat sheet