AI got you to something that worked, until it did not. I stop the bleeding, then turn it into software that can be safely changed.
The pattern is familiar by now. It’s not new to the AI age. It’s been around for as long as software has. Something was built quickly to prove an idea, it worked well enough to show people, and then it went live without anyone quite deciding that it should. It holds up until real users, real data, or real load arrive. By that point nobody can say why a change in one place breaks something unrelated in another, so the team stops changing anything, and the product stops moving.
The first job is to stop the outages and the data loss, before anything else. After that you get an honest assessment of what is worth keeping, which is rarely all of it and rarely none of it. I refactor in place where the bones are sound, replace the parts that are past saving, and put tests, structure, and dependency hygiene around the code that matters, so your team can change it without holding their breath. If the next idea needs testing too, prototype it deliberately so the throwaway version is built to be thrown away.
Stop the outages and the data loss first.
An honest read on structure, security, and risk.
Refactor in place, or replace the parts beyond saving.
Client names withheld under NDA.
An AI-built prototype went live and started losing data under load. I stabilised it first, then gave an honest read on what was worth keeping: the front end stayed, the data layer was rebuilt with tests and proper migrations.
Every change broke something unrelated and nobody could say why. We untangled the dependencies, added tests around the parts that mattered, and documented the structure so the team could ship again without holding their breath.