My AI agent fixed one bug and broke another feature

If your AI agent fixed one bug and broke another feature, the cause is almost always shared code: the fix changed something a second feature also relies on, and the agent only checked the first. The way out is a short routine. Find the shared code the fix touched, find every other consumer of it, rerun those consumers' checks, and record the breakage as its own linked task instead of patching it quietly. Resist the urge to tell the agent to fix the new bug too in the same session before you understand the link, because that often trades one regression for another. The steps below work with any agent and any tracker. For the underlying idea, and a worked example where one rounding change passed checkout and failed an export, see the blast radius of AI code changes.

Step 1: Find the shared code the fix touched

Start from the fix's diff, not from the broken feature. List every changed file and mark the ones that more than one feature uses: utility modules, money and date helpers, serializers, configuration defaults, base classes, shared styles or schema files. In most cases the culprit is in that short list.

For each shared file, write down the behavioral change in plain words. Not "edited format.py" but "format_amount now drops trailing zeros". Semantic changes are the dangerous ones because nothing else in the toolchain complains: the signature is the same, imports still resolve, types still check.

If the diff is large, bisect. Check out the commit before the fix, confirm the other feature works, then apply the fix's files one at a time, or use git bisect across several commits, until the feature breaks. Ask the agent why it changed the shared file, but treat the answer as a lead to verify, not a finding. Agents report what they intended, and the second feature was not part of their intent.

When you can name the line and the behavior change, you have the cause. Do not move on until you can.

Step 2: Find every other consumer of that code

Now turn the question around: who else depends on the changed behavior? Search the codebase for imports and call sites of each changed symbol. Include tests, scripts, migrations, templates and background jobs, which are easy to forget because they sit outside the main app.

Then look for the dependencies a text search misses. Dynamic imports and plugin registries load code by name. Configuration files reference functions as strings. Other services may consume your output without importing anything, so a CSV layout, a JSON field or a rounding convention can be a dependency with no import at all.

Finally, compare the list with what your tracker or plan says. If your tasks record which features depend on which modules, check them, but do not trust them alone. In a probe on a development build, an impact query over recorded links found the checkout task and its parent but missed the CSV exporter, because nobody had recorded that the exporter imported the helper [D6]. That gap is the difference between declared and inferred dependencies. Every consumer you find in code but not in your records is worth writing down now.

Step 3: Rerun every consumer's checks, not just the fix's

The agent almost certainly ran the check for the bug it was fixing. That check is not the one that matters now. For each consumer from step 2, run its own tests, or exercise it by hand if it has none.

Be specific about inputs. Regressions from shared code often appear only on boundary values: a half cent, an empty list, a time zone change, a null field. If the breakage came from a rounding change, test values that land exactly on half of the smallest unit, because that is where rounding and truncation disagree.

Where a consumer has no test that would have caught the breakage, write one before you fix anything. It should fail on the current code and pass once the conflict is resolved. That test is now part of the shared module's contract, and future changes to the module should run it. For why the original test let this through, see narrow tests that miss regressions.

Then decide what the shared code should do. Often two features want different behavior, and the right fix is two functions or an explicit parameter, not one helper that satisfies whichever task touched it last.

Step 4: Record the regression as linked work

Avoid the quiet patch. Asking the agent to fix the second feature in the same session, without a record, loses the most useful information you have: which change broke what, and which dependency nobody knew about.

Create a new task for the regression. Link it to the change or task that caused it and to the feature that broke. State the failing check with expected and actual output, for example: row(1.235) expected "124", got "123". If the original task was marked done, reopen it or record that its acceptance no longer holds, since it was accepted on evidence that missed a consumer. Reopening completed AI work covers how to do that without losing history.

Add the missing dependency to your records so the next change to the shared module lists the broken feature as affected. Then choose the fix: revert the shared change and implement the new behavior separately, or keep it and adapt the consumer. Either way, the new consumer test from step 3 must pass before anyone calls it done.

If this keeps happening, look at how you review cross-file changes: shared modules deserve the first look in every agent diff.

QUESTIONS

Why does fixing one bug create another?

Usually because the fix changed shared code that another feature relies on, and only the original feature was tested. The change often keeps the same function name and signature, so nothing fails to compile or import. The second feature simply receives different behavior than it expects, and the breakage shows up later, often in someone else's work.

Should I ask the AI agent to fix the regression it caused?

Yes, but after you understand it, and as a fresh, recorded task. First identify the shared code and the consumer that broke, write a failing test for that consumer, and decide what the shared code should do. Then give the agent a task that names both features and both checks, so it cannot satisfy one by breaking the other again.

Should I revert the agent's change or fix forward?

Revert when the shared change has several consumers you have not checked, or when you cannot yet explain the breakage. Fix forward when the cause is clear, only one consumer is affected and you have a failing test for it. In either case, keep the new consumer test so the same breakage is caught the next time the shared code changes.

RELATED GUIDES

• How to read BRAIN FLUID reports and provenance

RELATED HARNESS PAGES

• The blast radius of AI code changes The blast radius of AI code changes: what one agent edit can break elsewhere, a worked rounding example, and how a reviewer finds affected features.
• Why narrow acceptance tests miss AI regressions Why narrow acceptance tests miss AI regressions: a task's check can pass while a shared change breaks another consumer. A worked example and a fix.
• Reopening work an AI agent already closed Reopening work an AI agent already closed: when new evidence shows a DONE task is wrong, reopen it with the evidence instead of fixing it quietly.
• Reviewing cross-file changes made by AI agents Reviewing cross-file changes made by AI agents: check scope, read shared modules first, test interface changes and handle generated files apart.