Technical debt and AI: finally clearing the legacy

For the past two years, artificial intelligence has been pitched to me in almost exactly the same way every time: a productivity lever, therefore a headcount lever. That misses what it actually makes possible inside an information system.

AI does not replace a team. It makes affordable a kind of work that never was: methodically taking back old software layers, documenting them, testing them, bringing them up to date. In other words, clearing a technical debt that most IT departments have been carrying for ten or fifteen years, for lack of ever being able to justify the spend.

How much does technical debt really cost?

The most telling figure comes from CIOs themselves. Surveyed by McKinsey, they put their technical debt at 20 to 40 % of the value of their entire technology estate, before depreciation. In a large group, that runs into hundreds of millions.

The second figure hurts more, because it describes a suffocation mechanism: 30 % of the CIOs surveyed believe that more than 20 % of the budget officially allocated to new products in fact goes to dealing with debt-related issues. You fund innovation, you pay interest. And 60 % report that their debt has risen noticeably over the past three years.

That is the very definition of a vicious circle: the debt consumes the capacity that would allow it to be repaid.

Why have modernisation plans been failing for fifteen years?

No CIO is unaware of the problem. This is not a failure of clear-sightedness, it is a failure of arbitration — and the arbitration was rational.

Taking back legacy code is massive, repetitive, thankless work, with deferred benefits that are hard to defend in front of an executive committee. Upgrading an application across a major version, rewriting missing tests, reconstituting lost documentation, removing a dead dependency: each task is simple, there are thousands of them, and nobody wants to fund them. Against a business demand that is visible, modernisation loses the arbitration every time. That is why we collectively failed, year after year, on a subject everyone had correctly identified.

What has changed today is not our clear-sightedness. It is the unit cost of that repetitive work.

What does AI actually change on legacy code?

Two large-scale, published and documented field reports give the measure.

Amazon. Announcing the results of its code transformation assistant, Andy Jassy stated that the average time to move an application to Java 17 fell from roughly 50 developer-days to a few hours, for a total of 4,500 developer-years saved and around 260 million dollars in annualised efficiency gains. This is corporate communication, not an independent study — but the order of magnitude and the nature of the task are verifiable.

Google. The field report published by its research teams is more sober and methodologically more interesting: across 39 internal migrations carried out by three developers over twelve months, 74 % of the code changes were generated by the model, and the developers estimate the total time was cut by about half compared with earlier manual migrations.

Note the nature of these tasks: codified, repetitive and verifiable work. A version upgrade, an API migration, a library replacement. The success criterion is binary and the result can be tested. That is precisely where AI delivers its value — and it is no accident that the two companies publishing these figures applied it there, and nowhere else.

When does AI make you slower?

This is the part missing from most articles on the subject, and it is the part that determines whether your programme succeeds.

AI can slow you down. METR ran a randomised controlled trial with experienced developers, on their own repositories, mature and well known to them. The result: with AI tools allowed, they were 19 % slower. The most instructive part is not the number but the perception gap: they expected a 24 % gain, and afterwards still believed they had gained 20 %. On complex ground you already master, AI costs time while creating the feeling of saving it. No programme steered on gut feel can work here.

AI amplifies, it does not repair. That is the central conclusion of the DORA 2025 report, built on nearly 5,000 responses: AI does not improve an organisation, it amplifies what is already there. A solid team gets leverage; a team without tests, without review and without architecture mostly gains the ability to produce its defects faster.

The practical consequence is easy to state, and it is the whole point of an architecture engagement: before accelerating, you need to know what you are accelerating on. A legacy estate with no map, no regression tests and no exit criterion is not handled better with AI — it degrades faster. You then replace old debt with new debt, produced faster and understood less.

Why has obsolescence become urgent in 2026?

Until now, modernising was a choice: the timetable was yours. That is no longer true, and it is the real change of 2026.

For the first time in the report's nineteen-year history, the 2026 edition of Verizon's Data Breach Investigations Report ranks vulnerability exploitation as the leading initial access vector, at 31 % of breaches — ahead of stolen credentials, which had dominated until then. The same report notes that AI on the attacker's side is shrinking the defence window "from months to mere hours".

The French figures from ANSSI, in its Panorama de la cybermenace 2025, describe the same pincer movement:

• the rate at which vulnerabilities are published has grown 18 % per year since 2020;
• about 29 % of the vulnerabilities exploited in 2025 were exploited on the very day they were published, or before;
• and above all: more than 6,200 assets in France were still affected, at the end of 2025, by the main vulnerabilities exploited since 2023 and 2024.

That last point deserves a pause. These are not unknown flaws or sophisticated threats: they are published vulnerabilities, patched by the vendor, documented by CERT-FR — and still open two years later. This is not a security problem, it is a problem of capacity to keep an estate moving. Which is to say, a technical debt problem.

Add to this that automation now sits on both sides. The campaign catalogued as C0062 in MITRE ATT&CK, documented in late 2025, targeted around thirty organisations with 80 to 90 % of operations carried out autonomously by an agent: reconnaissance, exploitation, credential harvesting, lateral movement. An attacker industrialising against a defender patching by hand: that gap does not close with effort, it closes with tooling.

Finally, the constraint is becoming personal for company leadership. The NIS2 directive widens the French regulatory perimeter from roughly 500 entities to some fifteen thousand, with penalty ceilings set by the directive at €10 M or 2 % of worldwide turnover for essential entities, and accountability explicitly carried by the management body. As I write, the French transposition law has not yet been promulgated: the deadline has not passed, it is coming.

How do you take back a legacy estate with AI, step by step?

An AI-assisted legacy remediation programme does not start with AI. It starts with what makes AI usable.

1. Inventory. What is running, what is still supported by its vendor, what is exposed to the internet, what no longer has a known owner. It is the one deliverable whose value is immediate, even if the programme stops there.
2. Application mapping. The real dependencies, not the ones on a five-year-old diagram. Without it no batch can be isolated, and without an isolable batch there is no remediation.
3. Splitting into verifiable batches. A batch qualifies on three criteria: the work is repetitive, the expected result is explicit, and a test proves nothing broke. All three, or the batch does not go to AI.
4. Safety net first. Before any transformation: regression tests, a behavioural reference, the ability to roll back. This is the item that decides everything else — and it is also, today, largely automatable.
5. Assisted transformation, human review. The model produces, the engineer decides. The share accepted without modification is measured and tracked; it is not assumed.
6. Decommissioning. A modernisation that switches nothing off has repaid nothing: it has added a layer. Retiring the old service is part of the batch, not of the next phase.

Steps 1 and 2 are not administrative preliminaries: they are what determines whether steps 3 to 6 produce a gain or a fresh debt.

What has this method been tested on?

I do not sell a theoretical capability. Waypoint360 is a SaaS platform I designed, built and operate: authentication foundation, billing, database migrations, continuous delivery pipeline, a design system shared across several applications, large-scale internationalisation. The trade-offs described here are ones I hold on a production system, not on slides.

The same requirement applies to this article: every figure quoted points to its source, and the sources are dated. On a subject where approximation travels fast, that is the minimum owed to a decision-maker committing a budget.

Where should you start?

With the inventory, always. It is short, it costs almost nothing, and it produces two things: the list of what is exposed and unmaintained — the part that is urgent — and the list of repetitive, testable batches, the part where AI will pay off immediately.

If you want to discuss it concretely, the most useful entry point is a status review of your actual estate.