Yesterday my coding agent fixed a bug I had been circling for an hour.

Then it quietly broke two things that were working fine before it touched anything.

You know the loop.

You ask for a fix. It lands. A test goes red.

You ask it to fix the test. It fixes the test by undoing the original fix.

Now you are back where you started, more tired, and the agent sounds completely confident the whole way around.

For a long time I read that loop as the model being a bit dim.

I do not believe that anymore.

Here is the opinion I will defend in the comments.

When your AI breaks a working feature while fixing another one, that is almost never the model being stupid. Your setup has no memory of what working meant.

What I read this week said it plainly. The problem is configuration, not the model, and the real fix lives in the harness, not the prompt.

That one line reorganized how I think about the whole thing.

Once you stop blaming the model, you can name what actually breaks. I sat down and listed every distinct way "fix one thing, break another" shows up. It collapses into a handful of shapes.

Blast radius blindness.

You change a shared function or a type, and nothing tells you who else was calling it. It lands three files away, in code the agent never opened.

Contract drift.

You change the shape a function returns, or an API response, and the thing consuming it still expects the old shape. Nobody re-checks the handshake.

Silent safeguard removal.

This one is quiet. Your agent deletes a test, or skips it, or strips a guard that was holding something together. A regression hides inside the very check that would have caught it.

Verification gap.

Your agent shows you the change and calls it done. That diff is real. But a diff is not behavior. Nothing re-ran the old feature to confirm it still works.

Look at that list again and notice something.

Most of these breaks share one trait. Something that used to protect you quietly went missing.

That distinction matters more than it sounds.

Every linter and scanner you own is good at spotting bad code that is there. They go blind when good code disappears. A deleted test does not trip an alarm. A removed guard reads as a smaller, cleaner diff.

So tuning the prompt harder will not save you. You can write the most careful instruction in the world and the agent still will not know that one function had four hidden callers, or that one test was the only thing protecting a payment path.

This fix is boring, and it works. Stop trying to make the model behave, and start gating the behavior around it.

A few principles I now treat as non negotiable.

Prove the old thing still works before you call anything done. A green diff is not proof that behavior survived. Run the handful of tests that touch what you changed and read the result, every time.

Surface the blast radius at the moment of the edit, not three hours later in production. If a shared thing changed, you want its callers in front of you right then, while the change is still in your head.

Audit what already protects you before you add anything new.

Everyone skips this step. When I built my own guard for this yesterday, what kept it small was spending the first hour not building. I mapped every one of those failure shapes against the protection I already had. Most were half covered. Tightening what existed beat stacking new tools on top.

That single habit, audit before you add, separates a system that gets sharper over time from one that turns into noise nobody trusts.

None of this is exotic. It is the same discipline good teams have always used against regressions, pointed at a new kind of teammate who types fast, sounds sure, and forgets everything between turns.

Think of the model as a very fast junior who has no memory of yesterday. You would not let that person merge to main on confidence alone. Do not let the agent either.

Give the work a way to prove it did not break the thing that was already working. That is the whole game.

Your turn

What is the last thing your AI agent broke while fixing something else?

If this was useful

I work through this in public, the wins and the freezes both, mostly on LinkedIn and YouTube. If the real version of building in the open is useful to you, that is where it lives. LinkedIn, YouTube and X under Mirza Iqbal, and the work at next8n.com.