The cost nobody puts in the budget

View full size

Somewhere between 60 and 80% of the software in use today is legacy. It works, it earns money, and it is held together by people who did not write it. Maintenance on that estate is risky, invisible and unsponsored. A change to a system with no tests, no current documentation and no living author can break something that matters, and it delivers no feature anyone asked for. So the minimum is done, and the rest is carried.

What is carried has a price. Technical debt is estimated at about $3.61 per line of code, which puts a million line system roughly $3.6m in arrears before anything is decided. Clearing it by hand costs more again: $3 to $8 per line for the refactoring itself, $0.50 to $2.50 per line for the quality assessment that has to come first, another 10 to 15% of the refactoring cost in re-testing, and 10 to 20% on top for project management and contingency. Independent studies have observed manual refactoring at 3 to 5 EUR per line.

Take an ordinary 100,000 line application. It carries around $361,000 of technical debt. Refactoring it by hand costs $300,000 to $800,000 before assessment, re-testing and management are added, so the realistic bill starts around half a million dollars. The effort is the harder constraint. The climate case works through a seven million line system that would take about 254 developer-years to clear manually, a rate of roughly 125 lines per developer-day. At that rate the 100,000 line application is about 800 developer-days: four engineers for most of a year, doing work that adds no visible feature.

That is why it does not happen. It is not that teams do not know the debt is there. It is that the business case never clears, so the system ages, gets slower, gets more expensive to run, and quietly burns more energy every year.

Why a copilot makes this worse

The obvious answer is to point generative AI at the problem, and many teams already have. A copilot sits with one developer, in one file, and completes what they are typing. It is genuinely useful and it is the wrong shape for maintenance.

The project's review of the state of the art is blunt about the limits. Single-pass generation is regularly outperformed by iterative, workflow-based approaches that combine translation, test generation, error correction and call-graph analysis. Copilot-style tools have produced siloed, developer-centric practice that creates new technical debt at team level rather than removing it, because nothing in the loop has a view of the whole application. Code can pass its tests and still carry smells, maintainability problems and defects. Meanwhile the inference happens continuously, in the moment, on the interactive path, which is the most expensive way to spend it.

The duplicated helper repeated three hundred times, the dependency that is two major versions behind, the pattern that works but costs four times what it should: none of these are visible from inside a single file. They are properties of the system.

What the pipeline actually does

GreenCode works on the whole system, asynchronously, and measures as it goes. Maintenance is stage two of five, and it runs on what the mapping stage produced.

View full size

• It maps the codebase first, line by line and file by file, into a searchable index with a software bill of materials and an inventory of every interface and endpoint, so every later change has something reliable to work against.
• It generates the artefacts the system never had: unit tests in standard frameworks, in-code and external documentation, and commit messages that explain each change in terms a reviewer can check.
• It refactors element by element rather than attempting the system in one pass, working through a machine-readable action list produced by the quality assessment, and replaces deprecated, vulnerable or wasteful libraries identified from the bill of materials.
• It modernises and ports, including heterogeneous cases such as moving a Visual Basic 6 application to C#, with forms, classes, modules and controls migrated and API mapping automated.
• It returns everything on an optimisation branch as documented pull requests, so a team reviews and approves rather than inherits.

Iteration is bounded and every cycle is re-assessed. The quality gate is explicit: no net increase in quality issues, security flaws or error rate across an optimisation cycle, with a maintainability index above 85. That gate is what separates automated maintenance from automated damage, and it is checked rather than assumed. The mechanics are set out under automated software maintenance and sustainability led code quality assessment.

Keeping the AI itself lean

A tool that uses generative AI to reduce energy has to answer for the energy it spends. GreenCode's approach is small, fine-tuned models in place of general ones, retrieval so a model reads only what it needs, mixture-of-experts routing so each task goes to the lightest component that can handle it, and processing only what changed between runs. Because the work is asynchronous rather than interactive, heavy jobs can be held until clean power is on the grid. On the project's own accounting, inference costs a fraction of a percent of what the resulting optimisation saves. See green optimised generative AI and green AI and energy-aware computing.

What changes for the team

The backlog that was never going to be funded becomes a reviewable set of changes. The outcomes are described under legacy code modernisation, increased productivity and accelerated software development. The energy saving follows, because cleaner code is cheaper code to run, and stage four then goes looking for what is left.