GreenCode analyses a codebase against quality, security and green software patterns in one pass, so inefficient structures are found as quality defects before any energy optimisation begins.
Most static analysis tells a team where its code is wrong. It does not tell a team where its code is wasteful. GreenCode assesses both in the same pass and treats them as one subject, because the structures that make software hard to maintain are very often the structures that make it expensive to run.
The assessment scores a codebase against three reference sets at once: the ISO/IEC 25010 SQuaRE quality models, OWASP security practice, and the Green Software Foundation's green software patterns, used here as quality metrics rather than advice. A missing test, an unchecked input and a needlessly repeated database call all come out of the same analysis, in the same list, ranked together.
This is stage two of five, and it runs before any energy work. It takes the searchable index, the software bill of materials and the interface inventory produced by the mapping stage. It returns two things: a machine-readable action list in JSON that the refactoring step can work through element by element, and a human-readable report for the team.
Once generative AI has worked through the action list, the assessment is re-run on the changed code to confirm the uplift. The cycle repeats within a bounded number of iterations, so the pipeline cannot spend unlimited energy chasing a diminishing score. Only when the baseline holds does the pipeline move on to infrastructure and benchmarking.
There is a second, later pass. Energy figures measured during benchmarking are fed back as a quality signal, so a construct that survives static analysis but burns disproportionate power is treated as a defect rather than a curiosity. These are the sustainability smells the project set out to detect.
View full sizeThe targets are numeric and checked on every run. A maintainability index above 85, computed from lines of code, cyclomatic complexity and Halstead volume. Cognitive complexity stable or reduced. And a combined count of quality assessment issues, security flaws and error rate that must not rise across an optimisation cycle. That last gate is what stops the pipeline trading correctness for speed, which is the failure mode of naive automated refactoring.
Generated code is held to the same standard as human code, and checked rather than trusted.
The published review of static code analysis found the field strong on correctness and weak on energy. Formal verification, model checking and abstract interpretation give precise answers, but scale poorly to the multi-million-line estates that need the help most, so the review favours combining them with lighter analyses that run on every commit. It also examined analysers for compiled software, which matters where source is unavailable or where the compiler, not the author, determines what actually executes.
The same review is candid about generated code. It reports only a weak correlation between functional correctness and code quality in AI-generated software: code can pass its tests and still carry smells, maintainability problems and defects. The wider state of the art review adds that common coding benchmarks ignore energy entirely, so a tool can look successful while producing inefficient code. Both findings point the same way, towards measurement at every step rather than a single confident pass.
A ranked, explained list of what is wrong and what is wasteful, a report that names the standard behind each finding, and a re-assessment showing what the fixes achieved. The defect side of that outcome is described under reduced software issues.
Organisations that want to trial the assessment on their own codebase can get in touch via the contact page.
