GreenCode automates the QA, test and documentation work that developers do by hand or skip, and builds energy measurement into the pipeline, so teams spend less time on maintenance and more on features.
Ask an engineering manager where the team's time goes and the answer is rarely new features. It goes on understanding code nobody documented, writing tests that should already exist, chasing quality problems found late, and keeping legacy systems alive. The consortium records that in automotive software alone, modernising legacy code is largely manual and consumes up to around 40 per cent of developer productivity. It names the problem directly: complex maintenance and QA work reduces the productivity of development teams, and the project's answer is to automate the laborious parts.
The productivity case for GreenCode rests on that automation, not on a general claim that AI writes code faster.
View full sizeThe project's review of code analysis tooling describes modern systems as vast, spanning millions of lines written by many people over many years, with documentation frequently incomplete or outdated, so that the source itself is the only reliable reference. Existing mapping tools help humans read code but do not produce a model that automated tooling can act on.
Energy measurement is a second gap. The state of the art review finds there is no widely accepted green developer toolkit: tools such as CodeCarbon, Scaphandre and Kepler exist but were built for discrete contexts, so teams must stitch them together. Developers interviewed for that review see optimisation as extra effort that time pressure and weak incentives push out, and say adoption depends on low-friction tooling in the IDE and CI pipeline with quantified impact reporting. In most teams, energy measurement is simply not done.
The static code analysis work package removes the manual steps. Codebase mapping comes first: the SACA module parses source in multiple languages into a formal model, removing manual and error-prone interpretation and giving every later stage a searchable index of the system. Static analysis then treats energy as a quality metric, reporting code smells, security issues and green software patterns together, with inefficient structures identified up front.
Artefact generation identifies and creates the missing unit tests and documentation that a codebase needs before it can be changed safely. The state of the art review notes that LLM-generated tests are now emitted into standard frameworks such as JUnit, pytest and Jest, and that published studies rate LLM-generated documentation on a par with human-written documentation for readability and completeness. The open problems GreenCode targets are doing this at repository level and linking it to energy regression testing.
Generated changes are then checked. The code analysis review reports a weak correlation between functional correctness and code quality in AI-generated code, and persistent hallucination, so GreenCode checks every change against maintainability, security and domain metrics before a developer sees it.
The pipeline automates the measurement developers otherwise skip: stress testing and benchmarking with energy monitoring, so the pipeline can show which change saved what. The project's vision statement is that output arrives as transparent, reviewable pull requests with a human in the loop, alongside training material generated from the refactoring performed on the team's own code.
A team gets a mapped, documented and tested codebase without assigning developers to produce it by hand. Energy and quality regressions are caught in CI rather than in production. Reviewers spend their time judging changes, not writing the tests that make a change safe.
The consortium's estimate, drawing on Tidelift's managed open source survey and SQM's data from forty years of completed software projects, is a 20 to 40 per cent increase in developer productivity. The project will test that estimate against partner use cases. Those trials measure whether running the pipeline live inside the development workflow is a net gain compared with batch processing at the end of a day's work.
The consortium also weighs GitHub's published productivity figures for Copilot against a 2024 GitClear study showing that copilots can degrade code quality and maintainability, which is why generated changes are checked, and holds that GreenCode must be a tool that lifts burdens from developers, not a way of replacing them.
The productivity benefit is the direct output of the static code analysis work package, and of the pipeline's active development workflow trials and energy benchmarking. The AI work package supplies the energy-efficient language models behind the generation steps. One use case applies the refactoring tools to enterprise back-end systems, and another migrates an industrial plant engineering product from VB6 to C# under sustainability constraints.
Organisations that want to trial the tools on their own codebase, or contribute a use case, can reach the consortium through the contact page.
