GreenCode treats code quality as the precondition for energy optimisation. Static analysis, generated tests and regression gates cut defects and technical debt before any energy work begins.
Software defects are an operating cost as well as a delivery problem. Unplanned fixes, production regressions and modules nobody dares touch add to technical debt and to the energy a system burns. GreenCode names this directly. Among the problems the project set out to address are technical debt, a shortage of developers able to write quality software and over-reliance on copilot tools, alongside the cost of legacy systems that are inefficient in operation and in the productivity lost to maintaining them. The consortium makes the link plain: poor code quality, technical debt and security issues can signal poor operational performance and decreased energy efficiency.
GreenCode therefore treats quality as the precondition for energy optimisation. A cleaner, better tested codebase can be optimised safely, and the tooling that finds energy hotspots finds defects on the way.
View full sizeGreenCode's pipeline starts with quality baselining. A codebase is mapped file by file into a searchable index, then analysed against the ISO/IEC SQuaRE series of quality standards, OWASP security guidance and the Green Software Foundation's green software pattern library. An AI refactoring stage works through the machine-readable findings, the assessment is re-run to confirm that quality scores have risen, and the cycle repeats within configurable limits. Only then does energy benchmarking begin.
Three features of that loop matter. Missing artefacts are generated before code is changed: unit tests and documentation are created where they are absent, so refactoring has a safety net. Every change is checked for regressions. The project's preliminary requirements define QASER, a combined count of quality assessment issues, security flaws and error rate, which must stay stable or fall during optimisation cycles, and a separate requirement (NFR3) demands tests, checks and approval gates to prevent functional regressions from automated refactoring. And nothing is merged silently: changes land on an optimisation branch as documented commits with pull requests for review.
The project's own reviews are candid about generative AI. The code analysis review finds a weak correlation between functional correctness and code quality in GenAI-generated software: code that passes its tests may still carry code smells, maintainability problems or defects. It also identifies hallucination, the confident generation of false or unsupported content, as a persistent quality defect. The state of the art review adds that AI-generated fixes may improve one metric while degrading maintainability, readability or correctness, and that models infer behaviour from syntax rather than runtime, so code that appears efficient may not be.
GreenCode's answer is to pair generation with static QA and measurement at every step. The same reviews note that energy regression gates in CI/CD remain rare; the project is building them.
The code analysis work package is producing a code QA toolkit that scores codebases using code artefact information and GSF green software patterns as quality metrics, a codebase mapping toolkit and a GenAI tool that generates missing documentation and unit tests. Research on automotive software asks whether AI refactoring introduces system-level risk to security or maintainability, and a further strand examines commit trends and comment sentiment as quality indicators.
The pipeline and benchmarking work package supplies evidence. It measures energy for legacy and new code while checking that functionality is preserved, and tracks quality, maintainability and energy KPIs as a codebase moves through the pipeline. Project-wide targets include a maintainability score above 85, stable or reducing cognitive complexity and a stable or reducing QASER, alongside the headline target of at least 15 percent energy reduction.
An industrial transitive closure use case names poor maintainability, which raises development effort and the risk of bugs, as a target issue, with fewer SonarQube-reported code smells as a stated goal.
For a CTO or QA lead the outcome is a codebase with fewer latent defects, current tests and documentation, and an audit trail of what changed and why. The code analysis review puts 60 to 80 percent of all software in the legacy category, so this matters most for long-lived estates. The evidence bundle produced at the end of a run records tool versions, diffs and test results, so improvements can be verified rather than asserted.
The static code analysis work package develops the QA toolkit, mapping index and artefact generators. The processing pipeline work package runs end-to-end trials on legacy codebases and tracks regressions and KPIs.
Organisations that want to trial the QA toolkit on their own codebase can get in touch via the contact page.
