What the feature is

Developer sustainability training is the part of GreenCode that leaves something behind in the team. The pipeline can optimise a codebase without anyone learning anything, and the savings would then erode with the next release. Instead, every change it makes is recorded with its reasoning, and that record becomes teaching material about the code the developers already know.

Where it sits in the pipeline

It is an output of the fifth and final stage, alongside certification and management reporting. By that point the pipeline holds a complete account of the run: the quality findings from the baseline, the energy measurements taken before and after each optimisation pass, and the commit-level history of what was altered.

The generation step reads that account rather than a general body of best practice. What comes out is explanatory material tied to specific functions, dependencies and patterns in the team's repository, expressed as reasoned change requests instead of verdicts. Because the changes return as pull requests for review, a developer meets the explanation at the moment they decide whether to accept it.

What it produces

Three things reach different audiences.

View full size

• Reviewable pull requests in which each change carries the reasoning and the measurement that justified it, so review is itself the lesson.
• Course material drawn from the run, usable for onboarding and internal sessions, grounded in systems the team maintains rather than toy examples.
• Aggregated insight across successive runs, showing how a team's practice is moving and where the remaining weaknesses lie. This is deliberately aggregated and handled in line with data protection law, because it is a picture of a codebase and a practice, not a measure of individuals.

How it is assured

The material is only as good as the evidence under it, which is why it is generated after measurement rather than before. A claim that a pattern wastes energy is accompanied by the figures from that codebase, and the project intends to feed patterns that prove themselves back into the Green Software Foundation's public pattern library, so the teaching is corrected by evidence rather than repeated by habit.

The pipeline also checks that what it hands back is legible. Optimised code has to remain understandable and documented, on the reasoning that code nobody can read teaches nobody anything.

What it builds on

The state of the art reviews identify the reach problem plainly. Organisations working on sustainable software are largely doing so through standards and education, and those efforts are limited by weight of numbers against the size of the industry. The Green Software Foundation's membership accounts for under 1% of it, and the Foundation's own target of training a million practitioners would still reach under 5% of the world's developers. Most development environments still give no feedback on the energy cost of a decision, and the reviews name workforce development as a near-term priority alongside better tooling.

Automating the practice reaches teams that a course would not, in the same way security linters spread secure coding faster than security lectures did. The reviews point to sustainability heuristics embedded directly in development workflows as the promising direction, and that is the route GreenCode takes.

The project's universities are working the other side of the same problem, with six continuing courses and programmes across Germany, Spain, Denmark and Türkiye, listed under teaching and training page. The outcome for an organisation is set out under impactful sustainability training.