Every fix breaks something else

This is the point where people stop trusting their own app. It is not bad luck and it is not you: it is what happens when code is generated in pieces without anything holding the pieces together. There is a way out and it does not start with another prompt.

Why it happens

Each change is written with a view of a few files, not of the whole app. The same logic ends up copied in several places with small differences, and fixing one copy leaves the others as they were.

The copies usually differ slightly, which is why the bug seems to move rather than repeat.

Step one: stop the bleeding

Before any further change, make it possible to know whether the app still works.

Automated tests are better, but a list you actually follow beats a test suite you never write.

Step two: pull the repeated rules into one place

Each rule that exists in several copies becomes one function, and every screen calls that function.

Ask the tool to do this and it will often produce a seventh copy. This part is faster read than prompted.

Step three: make failures loud

Generated code tends to swallow errors, so a broken part looks like an empty part. You find out from a customer instead of from the app.

A silent failure is worse than a crash, because nobody investigates a page that merely looks empty.

When a rewrite is cheaper

Sometimes the honest answer is that the code cannot be stabilised for less than rebuilding the broken part.

Rewriting everything at once is the mistake on the other side. Replace one part, ship it, then the next.