Computing already emits about as much carbon as civil aviation, and most of it is electricity spent running software. This film tells the whole GreenCode story in four parts: the problem, what needs to be done, how the pipeline measures and cuts software energy, and the work so far. It is the one place to understand the project from start to finish.
Before AI and blockchain are added to the account, computing already emits about as much carbon as civil aviation, and most of that is electricity drawn while equipment is running. A data centre does not consume electricity. The software it exists to run does, and the building is simply where the meter is. Data centre operators have attacked cooling, rack density and power purchasing, because the software they host is a black box to them. The same is true of a phone that needs charging by lunchtime, a laptop replaced because a release made it feel slow, and a vehicle whose control systems draw from a battery with other work to do. Every watt in computing is spent executing instructions that somebody wrote.
Most software in service is already old, and in banking and healthcare the systems written decades ago still carry the transactions and the patient records. They cannot be switched off, and nobody wants to touch them. The reason is structural. Who can safely change this system? One with no documentation, no test coverage, no sponsor, no visible feature to show for the work, and an energy bill nobody in the room is accountable for. Behind it sit the transactions it carries, and the records it holds.
For about seventy years, hardware improvement absorbed whatever software asked for. As Moore's law levels off, that cover is ending, and the waste in software becomes visible on the bill. Green IT monitoring products have multiplied, and they are useful, but they are passive: they report a number and leave a team to work out what to do about it. Static analysers check correctness and security, say nothing about energy, and do not fix what they find. Modernisation consultancies will do the work, by hand, at a price that means only the most valuable systems ever qualify. GreenCode exists to close that gap. The point is not another dashboard. The point is a measured reduction, delivered as code.
Almost every energy-using product sold in Europe carries a rating a non-specialist can read at a glance. Software carries nothing. An organisation weighing up two systems can compare licence cost, features and support, and security posture, but not the electricity the software will draw over its service life. That cost arrives later, as a hosting bill, a hardware refresh, or a battery that no longer lasts a shift, and it is written off as part of doing business rather than attributed to the product that caused it.
The problem is not that engineers do not want to modernise legacy code. It is that doing it by hand costs more than anyone will approve. Technical debt has a cost per line, and clearing it has its own price list: the quality assessment, the refactoring itself, the re-testing, the management and contingency on top. For a large open-source database, the estimate comes to a number of developer-years that no organisation funds and no community project has. So the work is not delayed. It is never done. Automating it changes the arithmetic.
Any claim of a saving has to show it would not happen anyway, and for software energy it would not, for four reasons. Maintenance is done grudgingly, and energy is never on the list. The skills are scarce: even the largest training target would reach under one developer in twenty. Today's tools watch rather than act. And legacy code, most of what runs, is where the waste sits and where nobody has the budget to intervene by hand.
The consortium is building a pipeline of five stages, each a pluggable component, so tools can be swapped as the field moves.
It maps a codebase into a searchable index with a bill of materials and an inventory of interfaces. It baselines quality and refactors against recognised standards. It reconstitutes a representative deployment environment as infrastructure as code. It benchmarks the system under load while an observability stack records energy against individual code constructs, then rewrites the hotspots and measures again. Finally it rates the result, reports it, and returns every change as a pull request for human review.
GreenCode treats energy the way a mature engineering team handles quality, security or performance: something to measure, improve and verify, rather than estimate. First a quality baseline: the codebase is indexed, missing documentation and tests are generated, and quality flaws are refactored out. Then energy: the application is deployed on a reconstruction of its own infrastructure, stress-tested and benchmarked, and specialised generative AI refactors the areas responsible. The loop repeats until the measured improvement is good enough, and the optimised code comes back on a branch for human review, with a report on what changed and what it saved. What distinguishes this from a generic performance tune is when energy is recorded: before any change, after the quality baseline, and after each optimisation pass, all in the same environment.
The headline target is a net saving per product large enough that its owners see commercial value, with quality, maintainability and security scores that must not regress. The pipeline must also account for its own footprint.
GreenCode is built to measure and minimise the energy and carbon of its own operation: energy-efficient AI, and an agentic framework designed to be efficient as well as effective, so that the AI doing the optimising does not cancel out the savings. It is also developing methods that combine energy and performance metrics with the energy mix, so that design reflects how clean the supply is.
Most decarbonisation ramps up over years as assets are replaced. Software does not work that way. An optimised release cuts consumption from the moment it is deployed, at every instance running it, and keeps cutting it until someone undoes the change. That makes install base, not percentage, the number that matters. For a widely deployed database engine, and for the content system that runs nearly half the web, the arithmetic is the same: the run costs a little inference once, and the saving repeats every year, at every site, without a single owner changing anything they do.
Take one widely deployed open-source database engine: over seven million lines of code, running in tens of thousands of deployments. On the model it emits around sixteen thousand tonnes a year, and clearing its technical debt by hand would take some two hundred and fifty developer-years. The pipeline would spend a few kilograms of carbon on inference and avoid thousands of tonnes a year. Even at a thousand times the modelled tokens, the return is over nine hundred to one.
The work is already showing, in four places. In published research, GreenCode researchers compared writing code by hand with writing it through an AI assistant, and on the tasks they studied the assisted route carried more than thirty times the carbon, which is why the pipeline keeps its own AI lean. They have built a benchmark that scores generated code for energy as well as correctness. In public reports, the state of the art in energy measurement and in code analysis has been reviewed, and the pipeline set out. In open standards, the project contributes to shared tooling for rating software. And in the consortium itself: twenty-one partners across eight countries, presenting the work at events in Europe and beyond.
One result reaches into AI itself. The software that serves a model, its engine, kernels and surrounding code, draws energy on every prompt, and it can be optimised like any other program. GreenCode researchers gave an AI agent written principles to work to, correctness first, then a catalogue of known energy-wasting patterns. It profiles the code, plans ranked fixes, critiques each change against them, then measures again and keeps only what saves. On a widely used and already highly tuned inference engine, the energy saved outstripped the gain in speed. Faster is not always greener, so the loop reads the meter rather than the stopwatch.
The approach is being tested on real enterprise systems. Transaction processing in banking and insurance, where transaction volumes are so high that even small improvements become significant savings. A content platform that runs nearly half of all websites, so an optimisation found once is multiplied across every installation. The direct power draw of optimised software in an operational data centre. And the processor, memory and disk demand of database servers, so that capacity matches need.
On the tooling side, three related items are planned: bespoke training material derived from the codebase and its optimisation decisions, codebase-specific guidance for upskilling a workforce, and documentation, learning artefacts and partner-facing workshops to support transfer. On the teaching side, the university partners are already putting the material in front of students: a master's course on energy-aware programming, a green software training programme run in a capital city and online, students taught to conduct empirical measurement studies, a cloud energy course with a lab on real infrastructure, and green IT in regular lectures on software architecture. The consortium will publish measured results from its industrial use cases as they complete, and those measurements will replace the model. Until then, the case is open to challenge, with every assumption stated. Reach out to us with the system you would like to test these figures against, and we will help you understand what GreenCode could save on it.
Overview film
Better cooling, processors and power are all being built.
Overview film
Computing already emits about as much carbon as civil aviation, and most of that is electricity drawn while equipment is running.
