What is a regression — and why a fixed bug comes back

Here's the annoying one. There's a bug you already fixed. Last week. You remember the struggle, you remember the line you changed. And it's back.

Important bit: it didn't come back on its own. Someone brought it back. Almost always with an edit somewhere nearby, made by a person who had no idea there'd been a fight here.

This has a name — a regression. And it's the one kind of bug that tells you something honest about your project.

What a regression is, in plain words

A regression is when something that worked stops working after a change.

Not the new feature breaking. The old thing breaking — the part you never touched.

The difference matters:

• A regular bug — you wrote something new and it's wrong. Happens to everyone.
• A regression — you wrote something new over there, and something broke right here. You never even looked this way.

The word comes from statistics and means "moving backwards." Here it's literal: your project slid back into a state you'd already dragged it out of.

Why the bug comes back

The reason is nearly always the same: the fix lived in the code, not in a check.

Picture it. You found that the app crashes on an empty list. You added a guard — "if the list is empty, do nothing." Done, works.

A month passes. You (or an agent) tidy up that file. You spot a weird emptiness check — looks pointless, the list always comes from the server anyway. You delete it. Cleaner now.

The crash is back.

And notice: whoever deleted that guard behaved reasonably. The code never explained why it was written that way. The reason for the fix stayed in your head, and heads are terrible storage.

That's the core property of a regression: it isn't about carelessness. It's about knowledge that was never written where someone would read it.

Why AI agents bring regressions more often

Let's be fair here. An agent isn't "worse" than a human — it just has a different blind spot.

It sees the chunk of code you showed it. And it really wants to make that chunk prettier. A strange emptiness check, a confusing if, a hack with no comment — all of it looks like litter worth removing. The agent doesn't know that hack saved production three months ago.

It also tends to edit more than you asked for. You said "change the button text" — it also "improved" the function next door. Worth reading separately: why AI-written code has bugs.

Which gives a simple rule: the faster code gets written, the more expensive missing checks become. Speed without a net is just falling faster.

How to catch a regression once and for all

There's exactly one move, and it's cheaper than it sounds.

When you fix a bug — first write a check that fails. Then fix it.

Step by step:

1. You reproduce the bug by hand. The app crashes on an empty list.
2. You write a test: "given an empty list, the app does not crash." Run it. It's red. That matters: a red test proves it actually catches this specific problem.
3. You fix the code.
4. Run again. Green.

Now the fix lives in the repo, not in your memory. If anyone — you, a teammate, or an agent — removes the guard, the test goes red and says why.

Tests like these are called regression tests. They don't check "does the app work at all." They guard the specific spots where it already hurt.

Two multipliers on top:

• Leave a note in the code. One comment line — "without this check it crashes on an empty list, see the March 12 bug" — saves someone an hour and saves the hack from deletion.
• Let a robot run the tests. A test you run once a month isn't a net. Here's how to hang them on every commit: what CI/CD is. And you can absolutely ask a model to write the test — here's how.

The point of all this: a regression is unpleasant but useful. It isn't saying "you code badly." It's saying here's a spot where your project rests on memory instead of checks. Every regression you catch is one hole in the net closed for good.

How is a regression different from a regular bug?

A regular bug lives in new code you just wrote. A regression lives in old code that worked until your edit broke it. The second is more dangerous — nobody's looking for it, because "that part has worked for ages."

Do I need regression tests on a small project?

Not for everything — but yes, for every bug you've already fixed. They're the cheapest tests you'll ever write: you already know how to reproduce the problem and what the right answer looks like.

Who's to blame for a regression — whoever broke it?

Usually nobody. A person or an agent edited code that didn't explain itself. The fault isn't the edit — it's the missing check that should have stopped it.