Nothing can be optimised until it is understood. The first stage of the pipeline reads a codebase line by line and returns a searchable index, a software bill of materials and a map of every interface, so every later change has something reliable to work against.
The systems that stand to gain most from optimisation are the ones nobody fully understands any more. Between 60 and 80 per cent of software in service counts as legacy: millions of lines accumulated over decades, documentation that stopped being true years ago, and source code as the only trustworthy record of what the system actually does. An automated pipeline that starts by editing such a system is guessing. So GreenCode starts by reading it.
Mapping is the first of the five pipeline stages and the foundation for the four that follow. It takes a working repository and returns a structured, machine-readable picture of it. Every later stage, from quality assessment to energy benchmarking to the final report, refers back to that picture rather than re-reading the source.
View full sizeThree artefacts come out of it.
Together these give a team a current description of a system they may have inherited rather than written, before a single line has been altered.
The approach follows the reverse engineering practice set out in the project's review of static code analysis: parser-driven and model-driven analysis, using ANTLR4 grammars to produce syntax trees for each supported language, then lifting those trees into a common model that can be queried across languages. That matters for estates that are not written in one language, which is most of them.
Formal parsing establishes the structure precisely. Language models then supply the meaning that syntax alone cannot: what a routine is for, which parts belong to the same concern, where an undocumented convention is doing real work. Partner research on extracting knowledge graphs for legacy code understanding sets out how the two are combined, using the parser for exact syntax and the model for semantics, rather than trusting either alone.
The index is updatable, not a one-off snapshot. As the pipeline refactors, benchmarks and re-tests, the index is revised, so the record of the system and the system itself stay in step. That also makes the index the audit trail: every change the pipeline proposes can be traced back to the element it came from, which is what makes a pull request reviewable rather than an opaque diff.
The bill of materials is assured in the same spirit. Because it is machine-readable and complete, it can be checked automatically against known vulnerabilities, deprecated releases and libraries with better-performing replacements, feeding directly into quality, security and energy decisions later in the pipeline.
Almost everything. Static analysis needs the index to attribute findings to elements. Documentation and test generation need it to know what is missing. The benchmarking stage derives its load tests from the indexed endpoints. The energy measurements are attributed back to code constructs through the same index, which is what turns a power reading into an instruction about a specific function.
The practical effect for a maintaining team is that a system becomes legible again. That is the precondition for legacy code modernisation and the reason the later stages can take routine work off the team, which is where accelerated software development comes from. Automated mapping of a complete codebase is one of the deliverables GreenCode will bring out of the project.
To trial the mapping stage on your own codebase, get in touch through the contact page.
