Answer
How do you stop an AI coding agent fixing one bug by creating another?
Make it find the cause before the fix, keep the change small, and run the whole suite rather than the relevant part.
Require the cause before the fix, keep the change to the smallest thing that addresses it, and run the whole suite rather than the tests it judges relevant. Most regressions come from treating a symptom without finding what produced it.
There are two distinct ways this goes wrong and they need different handling. The first is the symptomatic fix: the reported behaviour stops happening without the cause being found, typically by special-casing the input, catching an error, or adjusting a value until the observed problem disappears. The code now behaves correctly in the reported case and incorrectly, in a new way, somewhere else.
The control is to require the cause before the change. Say what is producing this behaviour and how you know, then propose a fix. That is one extra turn, it is cheap, and it is where the value of the exchange sits: a stated cause can be disagreed with, whereas a fix can only be accepted or rejected. It also makes the symptomatic fix visible, because a cause that cannot be stated is a cause that was not found.
The second failure is the side effect. A correct fix to a real cause changes behaviour for callers nobody considered, because the function is used in four places and the agent looked at one. The control here is search rather than reasoning: who calls this, what depends on this shape, what else reads this field. This is the same class of check as reviewing generated code for what it does not cover, and it is answerable mechanically.
Change size is the third control and the most reliable. A minimal change has a bounded set of things it could break; a change that also improves adjacent code does not. The instruction that works is to fix only the reported problem and report anything else noticed, which keeps the diff proportional to the claim being made about it.
The fourth is running everything. An agent that runs the tests it considers relevant is running the tests for the code it was thinking about, which is exactly the wrong sample: the regression is in the code it was not thinking about. Where the full suite is too slow to run every time, that is a constraint worth addressing on its own merits, because it degrades every check that depends on it.
One pattern is worth naming because it is the most expensive version: the repeated fix. A change fixes the symptom, a new symptom appears, another change fixes that, and after three rounds the code contains several compensating special cases and the original cause is still there. The signal is a second fix in the same area within a short period, and the correct response is to stop fixing and start diagnosing, from the original report rather than from the current symptom.
A fix aimed at a symptom will usually work, and what it did to everything else is not visible from where it was aimed.
Siddharth Sharma, Context Theory
Related questions
How do you tell a symptomatic fix from a real one?
Ask what the cause was and check whether the answer explains the behaviour completely. A real cause accounts for why it happened, why it happened now, and why it did not happen elsewhere. An answer that describes where the failure surfaces rather than what produced it is a symptom description wearing the word cause.
Is a defensive fix ever the right answer?
Sometimes, and it should be labelled as one. Guarding against a bad input while the cause is investigated is a legitimate mitigation, particularly under time pressure. The damage comes from a mitigation recorded as a fix, because it closes the investigation and the underlying problem then resurfaces in a form nobody connects to it.
METHOD
Every figure below carries its source and the date it was verified. Nothing on this page is asserted.
The numbers on this page.
| What | Value | Specific to |
|---|---|---|
| Close rate — response under 5 minutes vs over 24 hours | 32% vs 12% | Category-wide |
| Sub-15-minute compliance — automated routing vs manual only | 62.5% vs 39.1% | Category-wide |
Optifai speed-to-lead benchmark · n=939 companies · Q2 2025–Q1 2026 · verified
2026 speed-to-lead benchmark · verified
What is specific to this page.
| Kind | Claim | Check it against |
|---|---|---|
| Workflow | Regressions from fixes divide into symptomatic changes that suppress the reported behaviour without addressing its cause and correct changes with unexamined side effects, and the two require different controls. | Classifying past regressions by whether the original fix stated a cause. |
| Response | Requiring a stated cause before a proposed fix costs one turn and makes the symptomatic fix visible, because a cause that cannot be articulated was not found, and a stated cause can be disagreed with while a fix can only be accepted or rejected. | Requesting the cause before the change and checking whether it accounts for why the behaviour occurred where and when it did. |
| Software | Side-effect regressions are addressable by search rather than reasoning, because the callers, dependants and readers of a changed element are mechanically enumerable, and the agent examined only the path it was working on. | Searching for every caller of a changed function and checking which were considered. |
| Constraint | Running the tests judged relevant samples the code the agent was already thinking about, which is precisely the wrong sample because the regression lies in the code it was not considering. | Comparing the tests an agent selected against the tests that cover the callers of the changed code. |
Each row would be wrong on another industry's page. Where a sourced figure exists it is in the table above instead; these are the constraints that shape the work and do not happen to be numbers.
Start with the measurement.
Reading about a benchmark is not the same as knowing your own number. The audit produces yours, measured rather than estimated.
$497 · delivered in 5 business days · credited against month one