AI keeps fixing one thing and breaking another: how to stop the loop

Do not diagnose the model before diagnosing the change

A repeated regression can come from unclear requirements, missing tests, a shared component, an incorrect assumption, or an ordinary coding error. The pattern alone does not prove which cause applies. Switching models or adding a longer prompt may produce another plausible patch without clarifying the boundary. Freeze the failing sequence first: what action triggers it, what visibly changes, what should happen instead, and whether the failure survives navigation or reopening.

Example: three broken pages can have one shared cause

Consider an illustrative app with Dashboard, File Upload, and Settings under a shared shell. A new drawer opens correctly, but closing it leaves the page unable to scroll. Patching all three pages independently may conceal the shared issue. Inspect the drawer lifecycle and its ownership of document scrolling, focus, overlays, and cleanup. These are possible inspection targets, not a diagnosis of your application. The actual code and a reproducible trace must determine the cause.

Give the agent a repair contract with an observable finish

Describe the result and surrounding promises. Let the agent handle routine tracing and implementation inside that boundary. It should not need another human handoff for every lint error or failed assertion. It should stop when it needs a consequential decision, lacks required access, or cannot recover within a sensible effort budget.

• Reproduce the failure against the current code.
• Find the owner of the state that remains wrong.
• Repair the cause rather than compensating on every affected screen.
• Exercise open, close, navigate away, and reopen paths.
• Report the verified outcome and any remaining uncertainty.

Check what the user does, not just whether the build passes

Choose checks that can falsify the repair. If an overlay blocks input, interact with the underlying page after closure. If a save operation duplicates records, repeat the action and simulate a lost response where the environment permits. If state disappears across sessions, close and reopen rather than refreshing the same component. Keep tests proportionate to the consequence. An isolated presentation repair and a change to customer payments do not need the same evidence.

Escalate product ambiguity, not routine engineering friction

Some apparent bugs are competing definitions. Should an AI proposal update the official plan immediately, or wait for approval? Either implementation can look correct locally while contradicting another screen. The builder must resolve that product rule; the coding agent can then implement it. Driftbreak fits when the repair needs those decisions connected to the broader system. It supplies a direction and implementation package, while your coding agent still makes and verifies the code change.

Plan a consequential change to a working product

Do not turn every regression into a rewrite

If the failing boundary is narrow and the surrounding behavior is trustworthy, repair that boundary and move on. A broad rewrite creates its own preservation and regression burden. If the same ownership conflict appears across several unrelated workflows, investigate the shared design before choosing the next patch. The decision should follow the demonstrated consequence, not how frustrated the last coding session felt.