Computing already emits about as much carbon as civil aviation, and software decides how much of it is wasted. GreenCode is building the pipeline that measures software energy, optimises it, verifies the result and certifies it, so that one release cuts consumption at every instance where that software runs.
Before AI and blockchain are added to the account, computing already emits about as much carbon as civil aviation. Most of it is not manufacturing. Around 70% of the sector's footprint is electricity drawn while equipment is running, and about 30% is embodied in the equipment itself. The running total is rising quickly. 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 annual electricity use of Japan. Counting data centres, networks and user devices together, ICT drew around 1,490 TWh in 2022. Wider estimates have the sector taking close to a fifth of global electricity by the end of the decade. The climate case sets out the model and its assumptions in full.
View full sizeA data centre does not consume electricity. The software it exists to run consumes electricity, and the building is simply where the meter is. The same is true of a phone that needs charging by lunchtime, a laptop replaced because a new release made it feel slow, and a vehicle whose control systems draw from a battery that has other work to do. Every watt in computing is spent executing instructions that somebody wrote.
For about seventy years, hardware improvement absorbed whatever software asked for. Each generation was faster and more efficient than the last, so inefficiency written into code was paid for out of a dividend that arrived anyway. That cover is ending. As Moore's law levels off, growth in demand is no longer cancelled by growth in physical efficiency, and the waste in software becomes visible on the bill.
Everyone in the chain is looking at the wrong thing. Data centre operators have attacked cooling, rack density and power purchasing, because the software they host is a black box to them. IT departments buy software on features and have no visibility of, or control over, how much energy it will consume in production. Developers are rarely measured on energy, rarely trained in it, and almost never given time to revisit code that already works.
Green IT monitoring products have multiplied over the last five years, and they are useful. They are also passive. They report a number and leave a team to work out what to do about it. Static analysers are the same story from a different angle: they 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.
GreenCode was set up to address eight connected problems:
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.
Each stage is described in the key features, including comprehensive codebase mapping, automated performance testing and green software certification. The outcomes they produce are set out under benefits.
View full sizeMost 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 work. That makes install base, not percentage, the number that matters.
The arithmetic is stark for widely deployed software. A seven million line open source database engine with around 47,000 deployments emits roughly 16,000 tonnes of CO2e a year in operation at the European grid average. Clearing its technical debt by hand would take about 254 developer-years, which is why nobody does it. Optimising it with the pipeline costs a few kilograms of CO2e in AI inference, a few tonnes even on a very generous allowance, and avoids around 3,700 tonnes a year.
The web is the clearest case of all. WordPress runs about 43% of all websites. On the climate case's own modelling, a content management system at that scale carries a footprint near 10 Mt CO2e a year at the European grid average, of which about 2.3 Mt is removable at the 23% saving the refactoring literature supports. Even a modest 7 to 10% gain across core and the most deployed plugins would remove 0.7 to 1 million tonnes a year, without a single site owner changing anything they do.
GreenCode's target is a measured reduction of more than 15% per system, taken from the original codebase on its generated infrastructure to the optimised one, alongside progression towards an A software carbon efficiency rating. Quality is gated at the same time: a maintainability index above 85, and no net increase in quality issues, security flaws or error rate. A saving bought by breaking something does not count.
System owners get a lower operating cost and evidence of it. Infrastructure operators get headroom they did not have to build. Developers get the maintenance backlog cleared and training drawn from their own code. Procurement teams get a rating they can put in a tender. Regulators and reporting teams get measured figures rather than estimates for CSRD and ESRS disclosure. The carbon saving is the same event in every case.
Want to know what this would find in your own systems? Talk to the GreenCode team about a use case.
Get in touch