The change you asked for works. Something you did not ask about has quietly stopped working.
Almost everyone tests the first half. Very few people test the second, and it is the second that produces the unpleasant discoveries — usually days later, usually by someone else, usually in the part of the system you were most confident about.
Two different tests
There are two questions to answer after any change, and they are not the same question.
The first is whether the new behaviour is correct. You described what should happen, so you check that it happens. This is straightforward, it is directly connected to what you just asked for, and it is where attention naturally goes.
The second is whether everything that already worked still works. Nobody described this, because it was not part of the request. It is the assumption underneath the request — that you were adding to a working system rather than trading one behaviour for another.
Checking the first is testing. Checking the second is regression testing, and treating it as optional is the single most reliable way to accumulate faults you cannot account for.
Why AI-assisted work makes this more likely
Not because the code is worse, but because of how the change is produced.
An assistant works from the code in front of it and the request you made. Nothing in either says which existing behaviour is deliberate. A slightly odd-looking condition may be a workaround for a real problem discovered months ago; from the outside it looks like something to simplify. A default that seems arbitrary may be load-bearing.
Human developers make this mistake too. The difference is pace: changes arrive faster than they can be reviewed at the same depth, and the surrounding code is read more literally than a colleague would read it. So the same failure mode occurs more often, and is noticed later.
An example worth recognising
An order screen calculates a total with tax. You ask for a discount field: enter a percentage, and the total reduces accordingly.
It works. You enter 10%, the total drops by 10%, and you move on.
What you did not check is whether tax is still calculated on the correct figure. If the discount was applied after tax rather than before, orders without a discount are unaffected — everything looks entirely normal — while every discounted order is now slightly wrong in a way that nobody will notice until someone reconciles the figures.
This is the shape of the problem worth internalising. The regression is not visible in the feature you built. It is visible in the behaviour you did not think to look at, under conditions you did not try.
Deciding what to re-check
You cannot re-test everything after every change, and pretending otherwise leads to testing nothing. Three questions narrow it usefully.
Whatever you settle on is worth recording alongside the change itself — the regression rows in the test record exist for exactly this.
What shares data with what I changed? In the example, the total, the tax and anything that reports on orders. Shared data is where regressions congregate.
What did the change touch on its way past? Look at which files were modified. If something outside your expectation was edited, whatever lives there needs checking regardless of how confident the change looks.
What would be expensive to get wrong? Money, permissions, anything stored. These deserve a look even when the connection to your change seems remote, because the cost of a silent fault is disproportionate.
Two or three checks chosen this way take a minute and catch the overwhelming majority of regressions that a general poke around would miss.
Make existing behaviour part of what you accept
The more durable fix is to stop treating existing behaviour as an assumption and start stating it.
Two sentences in the request will do it: what must keep working, and what must not change. "The order total, tax calculation and existing order list must continue to behave exactly as they do now" is not sophisticated, and it changes the shape of what comes back — as well as giving you a written basis for rejecting a change that violates it.
Then carry the same sentences into your checking. If you said the tax calculation must not change, verify the tax calculation. Constraints that are never checked decay into decoration.
When you find one
Establish what the behaviour was before, precisely, rather than working from memory of how it felt. If you have a version you trust, run the same case there and note the result. That gives you an observed and expected pair, which is the starting point for a contained correction: fixing AI-generated code without making it worse.
Then consider whether to fix forward or go back. A regression found immediately, in a small change, is usually worth correcting. A regression found later, after several changes have been built on top of it, often means the more honest option is returning to a known-good version and redoing the work in smaller pieces — which is only available if you kept one.
That is the practical argument for small increments. Not that small changes are less likely to cause regressions, but that when they do, the amount you have to unpick is bounded: why the smallest useful increment beats the smallest increment.