Answers to common questions about GreenCode
GreenCode is an international consortium of leading academic and business partners from around Europe, convened via ITEA (the Eureka Network’s software innovation cluster), who are collaborating to produce practical automated solutions for software decarbonisation via state of the art generative AI and ICT quality assessment practices.
The partners represent a variety of sectors, viewpoints and industry specialisms which are needed to ensure a development project such as this is successful and widely applicable.
GreenCode is currently in development, so is not generally available yet.
When ready it will be made available:
Talk to us about what GreenCode could do for your organisation »
Yes, on the published estimates. Allianz Research put the ICT sector's emissions above those of civil aviation in 2023, before the growth of AI is counted, and the International Energy Agency expects data centres alone to consume more than 1,000 TWh of electricity in 2026, roughly as much as Japan. Around 70% of ICT's footprint is the electricity used in operation, and software decides how much of that is drawn. The climate case sets out the numbers and their sources.
Because data centres exist to run software, and software decides how much energy they draw. Operators have already optimised cooling, density and power supply, but the applications they host are a black box to them, so the root cause has been left untouched. The same waste appears wherever code runs, from phones that need charging by lunchtime to servers bought to mask slow code. For seventy years faster hardware absorbed the growth in what software demands. As Moore's law levels off that cover is ending, and software efficiency is becoming the lever that matters.
Studies of code refactoring report energy savings of 10 to 30% from ordinary quality improvement, before any energy-specific optimisation is applied. GreenCode uses 23% as a central modelling value and sets itself a lower, measured target of more than 15% in each industrial use case. The saving applies at every deployed instance from the moment the optimised release ships, and it persists unless later changes undo it. Measured results from the use cases will be published on the publications page as they complete.
It is accounted for and it is small relative to the saving. Using the providers' own published energy figures (Google's measured 0.24 Wh per Gemini prompt and OpenAI's 0.34 Wh per ChatGPT query), GreenCode's model puts inference at about 0.58 mWh per generated token, or about 2 mg of CO2e per line of refactored code at the European grid average. For a 7 million line open-source database engine that is a few kilograms of inference to avoid about 3,700 tonnes of CO2e a year, and even at a thousand times the modelled tokens the return in the first year is over 900 to 1. See the climate case for the method.
The consortium is also working to shrink that cost with small fine-tuned models, retrieval so the model reads only what it needs, mixture-of-experts routing, processing only the changes between runs, and scheduling intensive jobs for when clean power is available on the grid. A pre-assessment decides whether a system is worth optimising at all. See Green AI and energy-aware computing.
A copilot is a buddy programmer. It helps one developer write the code in front of them, has no view of the whole application, and cannot tell how its suggestion affects long-term quality or maintainability. Studies show that heavy reliance on copilots speeds up releases while adding technical debt at team level. Copilots also run inference on every keystroke, all day, which adds up.
GreenCode works on the whole system, asynchronously to live development. It maps the codebase, measures its energy, finds the hotspots and returns reviewable changes, so it can correct the debt copilots introduce as well as the debt that was already there. Because it is not interactive it runs fewer inference jobs and can schedule them for the cleanest power. The consortium treats a general-purpose copilot as a non-goal.
Static analysis tools check quality and security. They are useful, and GreenCode uses them, but they do not measure energy and they do not fix what they find. Green IT monitoring products report the footprint of infrastructure without acting on the software that causes it. Modernisation consultancies can do the work by hand, at a published cost of 3 to 8 dollars per line of code for refactoring plus re-testing and management, and few organisations have that budget for a legacy estate.
GreenCode combines the assessment, the energy measurement, the automated remediation and the certification in one pipeline, with a human reviewing every change. The consortium's own review of the state of the art found no existing tool that does this end to end.
Legacy systems make up 60 to 80% of all software, with the highest shares in sectors such as banking and healthcare. CAST's research puts technical debt at around 3.61 dollars per line of code, so a million-line system carries over 3.6 million dollars of it. Clearing that by hand for a 7 million line codebase would take about 254 developer-years, or 51 developers for five years. Maintenance adds no visible features and carries risk, so the minimum gets done and energy is never on the list. That is why legacy estates are both the worst offenders and the best opportunity. See Legacy code modernisation.
It can be, when it is generated in a single pass and never checked. GreenCode does not work that way. Every change is produced inside a loop that measures energy and runs the generated and existing tests before and after, and a combined count of quality issues, security flaws and error rate must not rise during optimisation. Where iterative, workflow-based generation with test generation, error correction and call-graph analysis has been compared with single-pass generation, it wins. Changes reach the codebase as reviewable pull requests with documented commits, so a developer stays in control.
No. The industry has a significant skills shortage and is accelerating, not shrinking. GreenCode removes the repetitive, less creative work: reading undocumented code, writing tests that should already exist, chasing hotspots by trial and error. Developers review, decide and build features. Partners in the consortium are studying how engineering teams receive the tools so that they enhance the work rather than meet resistance, and the pipeline generates training material from a team's own code so the skills stay with the people.
GreenCode is a consortium of 21 partners under an ITEA project cooperation agreement, a well-tested framework for sharing the results of collaborative research. Partners use the outcomes internally, for their clients and in products, and the project has a duty to disseminate what it learns.
A system that is optimised is not used to train the models. Code is treated as a trade secret and stays confidential. Because humans review and approve every change and significant parts of the original code remain, the usual copyright position of the codebase is preserved. The consortium tracks the developing law on AI-generated code and will state its position clearly for any tool it releases.
In the European Union the Non-Financial Reporting Directive applies now, the Corporate Sustainability Reporting Directive phases in from financial year 2025 to 2028 with the European Sustainability Reporting Standards, the Corporate Sustainability Due Diligence Directive follows from 2027 to 2029, and, since 27 September 2026, EU consumer law (Directive (EU) 2024/825) bans generic environmental claims to consumers that cannot be proved; the proposed Green Claims Directive has been on hold since June 2025. Companies outside the EU with a significant EU presence come under the CSRD from financial year 2028. Reporting reaches medium and small businesses through supply chains, and a direct tax on IT carbon is a possibility. GreenCode produces the measured software energy data and certification these regimes ask for. See Accurate ESG data for CSRD reporting and Certified software energy efficiency.
Any application can be measured and improved, but the climate benefit scales with deployment. GreenCode's pipeline is aimed at systems that run at scale or at high intensity, because that is where a 23% saving amplifies into tonnes of carbon. A pre-assessment weighs the size and deployment of a system against the carbon the optimisation itself would spend, and a small, rarely run tool may not be worth it. The techniques also apply to software at the edge, where efficiency decides whether a device can run on its battery or on local renewable power at all.
Moving to a provider with a clean power supply helps, and GreenCode recommends it, but it does not solve the problem on its own. Clean electricity is limited: there is not yet enough of it for everyone, so every kilowatt hour wasted by inefficient software is one that cannot decarbonise something else. Market-based claims of zero-carbon power do not change the physical grid the servers draw from at any given hour, and waste still costs money and hardware wherever it runs.
Efficient software and clean power work together. The less energy software needs, the further the clean supply goes, and the more of the grid is left for the heating, transport and industry that also need it.
