Why software, and why now

The ICT sector, before AI and blockchain are counted, already has a carbon footprint on a par with civil aviation. Energy use is the largest part of that footprint, and the trend is steep. The International Energy Agency put data centre consumption at about 460 TWh in 2022 and expects it to pass 1,000 TWh in 2026, roughly the electricity use of Japan. Wider estimates have the sector consuming around a fifth of global electricity by the end of the decade.

Data centres are where the problem is easiest to see, but they are infrastructure. They exist to run software, and software decides how much energy they draw. The same waste is felt wherever code runs: in the phone that needs charging by lunchtime, in the console that overheats, in the laptop that is replaced because the latest application made it feel slow. Data centre operators have attacked the symptoms with better cooling, denser racks and cleaner power. They have not been able to touch the cause, because the software they host is a black box to them.

For seventy years hardware improvement has absorbed the growth in what software demands. That cover is ending. As Moore's law levels off, the power drawn by compute is no longer counterbalanced by physical efficiency gains, and the inefficiency written into software becomes visible on the meter. Roughly 70% of ICT's footprint is use-phase electricity and 30% is embodied in equipment. GreenCode addresses the 70% directly and the 30% indirectly, because software that needs less hardware means less hardware gets built.

What GreenCode does about it

View full size

GreenCode is building an AI pipeline that takes a software system, new or legacy, and improves it in three stages. It first baselines quality: mapping the codebase, generating the tests and documentation that are missing, and refactoring defects. It then measures energy, finds the hotspots in code and infrastructure, and optimises them with fine-tuned models until a target saving is reached. Finally it returns the changes as reviewable pull requests, reports the result, rates the system against ISO-aligned software carbon intensity and produces training material from the changes it made. The benefits pages describe each outcome in detail.

Impact logic

The distinctive thing about software optimisation as a climate intervention is speed. Most decarbonisation ramps up over years as assets are replaced. An optimised release cuts energy from the moment it is deployed, at every instance, and keeps cutting it until someone undoes the work.

Why it would not happen anyway

Additionality asks whether the reduction would occur without the intervention. For software energy the honest answer is no, for four reasons.

• Maintenance is done grudgingly. Refactoring adds no visible feature, carries risk and costs money, so the minimum is done and energy is never on the list. Automating maintenance makes the sustainability work possible inside the exercise that happens anyway.
• The skills are not there. The Green Software Foundation set itself a target of training a million practitioners, and even that target would reach under 5% of the world's developers. Few developers know how to write efficient code, fewer are given time to, and fewer still get to revisit a legacy estate.
• Today's tooling watches rather than acts. Green IT monitoring products have multiplied, static analysers check quality and security but not energy, and none of them fix what they find. GreenCode moves from reporting to doing.
• Legacy code is 60 to 80% of all software and the worst offender. It is where the technical debt sits, where the energy waste is largest, and where no one has the budget to intervene by hand.

Beyond the direct reduction, GreenCode's climate case identifies further ways the work is additional: it frees grid renewable energy for other uses; it lowers the energy of development and support because better software raises fewer tickets; it puts targeted training in front of teams based on their own code; it develops Green AI methods and energy-aware scheduling that other AI systems can adopt; it gives procurement an energy rating to buy on; it produces evidence of steps taken, not just status, for ESG reporting and green claims; and it spreads the practice through the open-source projects the consortium optimises as it tests the pipeline.

How much carbon is addressable

The top-down model starts from the IEA's 2022 figures for the electricity used by ICT globally and grows each component at the rate implied by the IEA's own forecasts rather than by market growth. Electricity is converted to carbon at the European Union's average grid intensity of 242 g CO2e per kWh in 2023. ICT runs on grids of every mix, so the global figures would be higher, roughly 1.8 times at a global average of about 0.45 kg; the European factor keeps the model conservative.

On those assumptions the total addressable carbon of ICT's use-phase electricity is about 374 Mt CO2e in 2023, 593 Mt in 2027, 882 Mt in 2030 and 1,874 Mt in 2035. Networks are then set aside, because their traffic is not directly related to their emissions, which leaves the software running in data centres and on user devices. The literature on refactoring for energy, from object-oriented languages to embedded systems and portable devices, reports savings of 10 to 30% from ordinary code improvement, before any energy-specific optimisation. Using 23% as a central value, the carbon that software optimisation could remove is about 142 Mt CO2e a year in 2025, rising to about 283 Mt in 2030 and 635 Mt in 2035 as the sector grows. GreenCode's own target is a measured reduction of more than 15% in each industrial use case, which is deliberately below the central literature value.

What one optimisation is worth

View full size

The bottom-up view looks at individual systems. The examples below are widely deployed open-source projects, chosen because their size and install base are public. Line counts come from cloc, the energy per instance is estimated with the Green Software Foundation's method, and the footprint uses the minimum plausible install base. The model assumes about a quarter of a codebase is touched and a 23% energy saving results. Carbon is at the European factor above. The last column is the carbon cost of the AI inference needed to do the work, at the energy per token described in the next section.

The carbon return is large in every case. An open-source database engine of about 7.3 million lines with at least 47,000 deployments, emits around 16,000 tonnes of CO2e a year in operation on this model. Clearing its technical debt by hand would take about 254 developer-years. Optimising a quarter of it with the pipeline takes about 28 million tokens of inference, roughly 4 kg of CO2e, and avoids about 3,700 tonnes a year. Even if a real run used a thousand times more tokens than modelled, it would cost about 4 tonnes and return over 900 to 1 in its first year. Doing the same work by hand would itself emit around 6 tonnes, from the energy of the developers' workstations over those 254 developer-years. Commercial systems have smaller install bases than these examples, but they are typically less well optimised, and workloads in finance, retail and advertising run millions of transactions a day on relatively few installations.

The footprint of the AI itself

A pipeline that uses generative AI to save energy has to account for the energy it spends. The most credible figures are the providers' own. Google has published a measured median of 0.24 Wh for a Gemini text prompt, with its method; OpenAI has given about 0.34 Wh for an average ChatGPT query; Anthropic has not published a figure. Taking the average of the two, 0.29 Wh, over a response of 500 tokens, the conservative length Epoch AI uses for the same purpose, gives about 0.58 mWh per generated token, in line with Epoch's own estimate of 0.3 Wh per GPT-4o query. At 15 tokens per line of refactored code and the European grid factor, that is about 2 mg of CO2e per line.

That figure counts only the code the model writes. A real run also reads the surrounding code, tests and documentation, so it uses many more tokens than it emits. The conclusion survives even a large allowance: at a thousand times the modelled tokens, inference is still well under a thousandth of the first year's saving in every example above. Training is a larger but one-off cost: Meta reports 11,390 tonnes of CO2e to train all three Llama 3.1 models together, which a WordPress optimisation on the model above would repay in under two days of deployment.

The consortium is also working to keep that cost small as the pipeline grows. The methods are small and fine-tuned models in place of general ones, retrieval so the model reads only what it needs, mixture-of-experts routing so each task uses the lightest specialist, and processing only the changes between runs rather than the whole codebase every time. Because the pipeline runs asynchronously to development, intensive jobs can be held until clean power is available on the grid. A pre-assessment decides whether a system is worth optimising at all; small, rarely deployed software may not repay the carbon spent on it, and the pipeline says so.

Rebound effects and net benefit

Digital solutions are often proposed as climate tools, and the evidence that they deliver a net saving is thin. Freitag, Berners-Lee and colleagues showed in 2021 that ICT's footprint, AI included, is routinely underestimated and that efficiency gains are regularly cancelled by the demand they enable. In 2023 Mike Berners-Lee and his co-authors took the argument further in Systems thinking and efficiency under emissions constraints: when computing becomes cheaper and more efficient, people use more of it, and "efficiencies under emissions constraints are the only way in which efficiencies for true emission reductions can be realized". Efficiency, in other words, is one solution among several, and on its own it may not cut emissions at all.

We agree with that position, and GreenCode is designed around it rather than in spite of it:

• It works on software that already exists. The pipeline optimises systems that are already deployed and already running, so the saving comes out of demand that is there today rather than creating new demand by making computing cheaper.
• It makes the saving visible. Energy and carbon are measured before and after, in absolute terms, and certified with their evidence, so a reduction can be counted against a carbon budget instead of being quietly spent on more computing.
• It helps owners bank the saving. The reports show where capacity can be retired, cloud estates shrunk and devices kept in service for longer, so that the headroom efficiency creates is taken out of the system rather than filled.
• It counts its own footprint. The AI the pipeline uses is accounted for on every run, and a pre-assessment declines optimisations that would not repay their carbon.
• It supports the constraints. Ratings and evidence are built to feed ESG disclosure, procurement rules and green claims, the kinds of emissions constraints under which efficiency becomes a real reduction.

GreenCode does not claim that efficient software will cut emissions by itself. It claims that, alongside limits on emissions, it makes those limits cheaper and easier to meet, and that it improves the odds that a digital climate intervention comes out net positive. Systems that can do more locally, on constrained devices and renewable power, also need less of the heavy remote infrastructure that rebound effects tend to hide in.

UN Sustainable Development Goals

The work supports several goals directly. Climate action (SDG 13) through fast, persistent reductions at the point of deployment. Decent work and economic growth (SDG 8) because optimised systems cost less to run and maintain and free developers from repetitive work. Affordable and clean energy (SDG 7) because energy not wasted on inefficient software is available elsewhere on the grid. Clean water and sanitation (SDG 6) because less heat in data centres means less water spent on cooling.

The indirect effects reach further. Efficient software lets sensing, control and AI run at the edge on local renewable power, supporting goals on poverty, hunger, health and sustainable communities (SDGs 1, 2, 3 and 11). Longer hardware life and fewer new devices reduce demand on metals and manufacturing (SDG 12) and keep older equipment useful for education and access (SDGs 4 and 10). Longer battery life for remote devices supports ocean and land monitoring (SDGs 14 and 15). Critical infrastructure that keeps working on backup, depleting or renewable power is more resilient (SDG 9).

System boundaries

View full size

The model draws a deliberately narrow boundary. On the cost side it counts GreenCode's own footprint: the AI inference for each optimisation run, the one-off cost of training models shared across all runs, the benchmarking that proves a saving, and the small overhead of hosting, offices and travel. On the saving side it counts only the use-phase electricity the optimised software stops drawing, in data centres and on users' devices, at every deployment and for every year the release stays in use. Network energy, the embodied carbon of hardware that lighter software avoids buying, and rebound effects are all left outside, so that everything the model claims sits inside a boundary it can defend.

Assumptions and limits

The figures on this page are modelling, not measurement. The addressable carbon assumes all ICT electricity is attributable to running software, that all software could be optimised, and that the IEA growth rates hold. Embodied carbon is excluded even though lighter software reduces the hardware bought. The per-system examples are open source, and multiple optimisation runs may be needed, although later runs process only what has changed and cost a small fraction of the first. Savings persist unless later development reverses them. The consortium will publish measured results from its industrial use cases as they complete, and those measurements will replace the model.

This climate case was first written by Chris Dean in 2024 as an assessment of GreenCode's potential impact, and has been reworked here for the project. It was updated in September 2026: carbon is now calculated at the European Union's average grid intensity, and the cost of AI inference uses the energy figures Google and OpenAI have since published. It is reviewed as new data and publications become available.