Summary
The application worked and had been a real success, but only one person really knew how to run it, and that person could not keep it available around the clock. Handing it over was justified; it had to move to another technical stack, and the choice fell on an AI-assisted rewrite. The rewrite started from far more than a repository: functional and technical documentation, up-to-date specifications, migration history, good test coverage. What reached qualification had a poor design and more than fifty regressions of varying severity.
I do not read this as proof that AI cannot rewrite software, nor do I pin every defect on the model: method, instructions, controls and human decisions shape the outcome too. The lesson is that a rewrite is not a translation. Behaviour, business rules and API contracts must be preserved; architecture, error handling, concurrency and libraries must be designed for the target stack. AI can help, but the team still has to decide which is which.
The harder question is what happens when that knowledge was never written down. AI can analyse code and draft hypotheses, but it cannot preserve a business rule that no document, test or trace reveals. Fast generation can then turn knowledge debt, an organisation no longer understanding its own system, into technical debt. The article closes with a six-step controlled approach, six rewrite strategies chosen by what is known of the system and how far apart the stacks are, and the question of who is accountable for the result.
Key ideas
- Complete documentation, specs and tests did not prevent more than fifty regressions: having the information does not guarantee it is used well.
- Rewriting is not translating: behaviour must be preserved, while the architecture must be designed for the target stack.
- Qualification is not a formality at the end: explicit success criteria and independent checks belong at the start of the migration.
- When business rules live only in a few people’s memory, AI cannot preserve a rule that nothing available reveals, and fast generation can turn knowledge debt into technical debt.
- Handing over the code is not handing over responsibility: the measure of success is a team able to deliver a reliable system and maintain it over time.
Why I wrote this
AI can produce much of the code, but it cannot be blindly trusted to preserve knowledge the organisation itself no longer holds. The real question is not whether AI can rewrite our software, but whether we can prove that what it rewrote is the software we need.