GreenCode derives a load test from the endpoints and unit tests it has already indexed, runs it against a like-for-like deployment and records energy as well as speed, so every optimisation pass is checked against the same evidence.
Automated performance testing is how GreenCode earns the right to claim a saving. Before any code is rewritten for energy, the pipeline has to be able to put the system under a realistic load, watch what it costs and repeat the exercise identically after every change. Writing and maintaining those tests by hand is the reason most teams never measure energy at all, so GreenCode generates them.
It opens the fourth of the five stages. Two earlier stages supply its raw material. Mapping the codebase produces the index of interfaces and endpoints, so the pipeline knows what can be called. Quality baselining produces the unit tests the code was missing, emitted into the project's own frameworks rather than a research harness.
From those, generative AI derives a load-testing plan in standard formats, including browser-driven scripts for systems with a user interface. Where generation is not feasible, a team can supply its own plan and the pipeline uses that instead.
The plan is executed against the deployment that the infrastructure stage reconstituted, so the environment matches the system as it really runs. An observability stack, with Elastic Observability as the reference implementation, records performance, response time and energy while the load runs, and attributes them to code constructs rather than to the process as a whole.
View full sizeThe output is a hotspot map: a ranked picture of which parts of the system consume the most for the work they do. That map is what the optimisation models act on, so effort goes where the consumption is instead of where a reviewer's intuition suggests.
Each optimisation pass ends where it began, with the same load test rerun on the same environment. That gives a like-for-like comparison per iteration and catches the two failures that matter. A change that improves energy but breaks behaviour is rejected. A change that appears to save energy by shifting it to another thread, process or idle allocation is visible, because the measurement boundary covers the whole deployment.
Energy is captured by whichever method the environment allows: external wall-plug metering, on-chip counters such as RAPL, cloud-native collectors, or models that infer consumption from resource utilisation where direct measurement is impossible. Each mode carries its own accuracy, so GreenCode records which was used and with what confidence rather than presenting one number as though all were equivalent.
Profiling that is too heavy distorts the thing it measures, so the pipeline favours lightweight collection and quantifies its own overhead. Attribution rules are stated explicitly, covering baselines and shared costs. Function is guarded alongside energy, with quality assessment issues, security flaws and error rate not rising in aggregate across the run.
Software testing is among the most heavily researched areas the state of the art reviews cover, with generated tests now routinely emitted into mainstream stacks. Almost all of that work targets functional correctness. The reviews are blunt that the sustainability link is weak: energy and performance regression testing is under-integrated, and green regression gates in continuous integration remain rare, so energy regressions go unnoticed. Tools exist to capture energy during a build, and research prototypes have shown automated energy regression detection is feasible, but adoption has not followed.
Closing that gap by generating the tests, running them and gating on the result is one of the deliverables GreenCode will bring. It supports reduced software issues and provides the evidence behind reduced energy use.
