We Used to Call It a Write-Off

You have probably heard this one before. A business application has been running in the company for ten years. It was built by a contractor you no longer work with, or by a former employee, or by both, taking turns. One day it needs to change: new features, a data export, or simply understanding why it calculates what it calculates. You call in an expert, then a second one. And the answer comes back in roughly the same words every time: “it’s too complicated”, “it’s badly built”, “there’s no documentation”, “the documentation doesn’t match the code any more”, “the code isn’t commented”.

Nobody always says the conclusion out loud, but everyone hears it: start again from scratch. Along with the quote that goes with it.

I gave that speech myself for years, and for good reasons. When you bill by the day, understanding someone else’s code with no map and no compass often costs more than starting from a blank page. The client ends up paying for the discovery, then for the rewrite.

This year, at several clients, I did it differently.

A few recent jobs

The first: recovering the data from a Cegid Manufacturing system and a Cegid Compta v9 dating from 2013. Thirteen-year-old versions, nobody left in-house who could explain the tables, and years of production and accounting history the company had no intention of losing when it changed tools.

The second: an old Odoo v11, released in 2017 and long out of support, complete with its home-grown modules. The client’s question was simple to ask and tedious to answer: what is standard, what was built specifically for us, and what can we carry over to a recent version?

The third: a home-grown PHP application, written piece by piece over the years, undocumented, used by the team every single day, and that nobody dares touch any more.

There were others. The technologies have nothing in common, neither do the stories, and yet the process was the same every time. I handed the code, the database schema and data samples to Claude Code (Anthropic’s coding agent, which works directly in the terminal, reads files, runs commands and queries databases). And every time, it gave me back three things:

1. What’s there. Which tables hold what, which fields are still in use, which modules are standard and which were added, which functions actually do the work.
2. How it’s built. The choices made at the time, the workarounds, the fragile spots, with files and line numbers to back it up.
3. How to move it forward. Several options you can put a price on, from the lightest to the heaviest, with what each one implies for the client.

With Odoo, for instance, the method boils down to an idea every developer knows but nobody used to take the time to apply: compare the installed code against the official v11 sources. Whatever differs is the custom work. The rest, you know where to find in a recent version. What used to take days of reading by hand, the agent does in a single session, and it explains what it finds.

A diagnosis without the trial

What struck me most was the speed, of course, but above all the tone.

When an expert opens someone else’s code, there is often a reflex to put the predecessor on trial. They were incompetent, the choices were absurd, nothing can be salvaged. Sometimes that reflex is right. It also serves a commercial interest: the worse the existing system looks, the easier the rewrite is to justify.

Claude Code doesn’t have that reflex. It describes the code as it is. When a part is fragile, it says so, says why, and says what that puts at risk. When a part holds up, it says that too, even if it isn’t written the way you would write it in 2026. And sometimes it explains why the developer at the time probably made that choice: a version constraint, a database that couldn’t do better, a client in a hurry.

For a business owner, that changes the conversation. Nobody tells them their tool is “garbage” any more. They are told what works, what is risky, and what each option would cost. They can decide at a fair price, taking into account the size of the company, its budget and who will maintain the tool tomorrow.

And then there was that WordPress site

The icing on the cake was a large WordPress site infected by two different malicious payloads that had piled up over time. The site was stuck: no more updates possible, and spammers were using it for their own mailings.

Only a year ago, nearly every expert, myself included, would have told the client it was dead and that the site had to be rebuilt from scratch. That was the reasonable answer: you can never be sure you found everything, and a site you believe is clean but isn’t costs more than a new one.

This time, we cleaned it completely. The method is a classic one; its scale was not: compare every file in core, themes and plugins against the official releases, look for PHP where it has no business being, go through the database, work out how each of the two payloads installed itself and protected itself. No contractor would quote that work at a price the client could accept. With Claude Code, it became doable in a reasonable time frame.

And on top of a working site, the client received a document that says exactly what was wrong: what each payload did, where it was hiding, and what was removed. That document is what lets them trust the clean-up, and understand how not to go through it again.

Why now

Coding assistants have been around for several years. What changed in 2026 is that frontier models can hold an entire project in memory, that they act instead of merely suggesting (run a query, read the result, revise their hypothesis), and that they do it with a level of rigour that, to this day, still surprises me.

There is also a reason I didn’t see coming, which I’ll offer as a hypothesis: old code is precisely the code these models have read the most. PHP from the 2010s, Odoo modules from every version, ERP schemas documented on forums that no longer exist… What puts off a 2026 developer who has never touched those technologies is familiar ground for the model.

The limits, to be honest

None of this works without someone who knows how to read the output. I have written about the expert’s paradox: you need to be an expert to check what the AI says, so the AI doesn’t spare you the expertise. That is what happens here. I have worked with ERPs and security long enough to spot a mistake, ask the right question, and turn down a recommendation that doesn’t fit the client’s context. And the agent does get things wrong. Less than it used to, but it does.

A few rules I hold myself to:

• We work on a copy, never on production.
• Every significant claim is checked against the real data: if the agent says a table is unused, we count its rows and look at the date of the last write.
• Personal and sensitive client data doesn’t go to an American provider without some thought first. Often, the schema and anonymised data are enough. I go into this at length in Deploying GenAI Without Breaking GDPR and in Où héberger son IA ? (in French).
• The client keeps the deliverables: the map, the scripts and the rules. If they change contractor tomorrow, they leave with all of it. That is what I was already arguing in my ERP project logbook (in French).

And one question stays open, the one I asked in Qui formera les experts de demain ? (Who will train tomorrow’s experts?, in French): if the agent does the reading instead of the juniors, where will they learn to read old code?

What it means if you run a business

That the rather unpleasant phrase “it’s garbage” now deserves a diagnosis before you accept it. Your old business application holds years of business rules that nobody ever wrote down anywhere else, and those rules are worth something. For a long time, getting them out cost too much. That is no longer true in most of the cases I’ve seen, for now at least.

Rebuilding is sometimes still the right answer. But you can now make that call knowing what you’re dealing with, with a map of the existing system in front of you, rather than because nobody had the nerve to open the bonnet.

Read the code first. Decide afterwards.