GreenLint

Dashboard View
Code Analyser
Automatic detection of anti-patterns through static analysis.
Instant analysis feature on the dashboard for ease-of-use.
AI-generated suggestions from code hot-paths (**not** just sending all the code to AI!!!)

Inspiration

We've all been there. You're almost acing the SIG OA, but just when you run the test cases for the last time, you see your worst nightmare: "Time Limit Exceeded".

But here's the thing, inefficient code isn't just a performance lag - it’s a carbon tax on the planet.

We live in a world where "just add more RAM" has become the default answer to sloppy optimisation. But in high-stakes environments - from government infrastructure to high-frequency trading - unoptimised code drains budgets and spikes CO2 emissions.

That's where we come in. We built GreenLint, a code analysis tool that leverages AI to improve code efficiency (on multiple fronts), reduce energy consumption, and make every line accountable.

What is Greenlint?

GreenLint is a linter, static analyser, and sustainability consultant that fits neatly into your CI/CD pipeline.

It can:

Detect structural inefficiencies in code (deeply nested loops).
Locate sub-standard memory management/allocation.
Implement best practices for safe, modern code.
Estimates energy, cost, and CO2 impact of various code patterns.
Suggests or auto-applies optimisations without breaking existing logic.
Tracks improvements over time with a dashboard.
Integrates seamlessly into Git workflows through hooks.

What's Under the Hood?

Greenlint had a lot of things it needed to get right, but we can split them into 3 major components.

Greenlint has 3 core components:

The Core Engine: Responsible for static analysis, AST (abstract syntax tree) parsing, IR (intermediate representation) promotion, etc...
The Consultant: Handles and interfaces with various data sources (eg; the Electricity Maps API or Green Software Foundation's public APIs) to generate as-accurate-as-we-can predictions for carbon costs.
The Brain: Receives our IR (along with some metadata), and locates the exact hot-spot in the source code (ie; deeper than just the function, but rather the actual "anti-patternistic" lines) to optimize using AI.

Because we promote our code to an IR, Greenlint is super extensible. It is extremely easy to add support for your favourite language, as all it really entails is mapping the important constructs to our API.

For a lot of development, we used a local CodeLlama instance to handle the heavy lifting of semantic transformations. Running it locally means we aren't leaking proprietary logic to a third-party cloud, but also saved us a lot of credits ;).

We also aggregated data from thousands of repositories to identify "energy hotspots" - specifically looking for O(n^k) complexity in critical paths and redundant memory allocations that spike CPU cycles. In addition, we're able to solve much more than just structural anti-patterns - for low-level languages like C++, we can detect sub-optimal memory allocation strategies, pass-by-value when you should pass-by-reference, using C-arrays or C-pointers instead of the STL, etc...

Even cooler is that to make the environmental consultant even more accurate, we also developed a heuristic model to translate algorithmic complexity and execution frequency into physical units: kWh, £/€ cost, and CO2 emissions.

The backend is built in Python to make our core engine API as accessible as possible, while the React dashboard gives us a high-level view of the "Green Debt" across the project. We also prototyped a git-pre-commit hook extension to get these metrics in front of the dev before they even hit your repo! What that means is that right after committing your code, Greenlint will automatically scan your git-diff for new code, traverse it, optimize anything, and report on carbon savings! Awesome!

The Hard Parts

Hackathons are basically 90% fighting your environment and 10% actually building.

For us, that meant development-environment hell. Setting up a consistent dev environment across WSL, Windows and MacOS for Python and the frontend was a nightmare, and we spent way too many hours just getting the git hooks to trigger correctly across the subsystem boundary (this is why you use Nix, folks!).

We also hit a massive wall with decision paralysis. Early on, we spent way too much time debating whether to build a full-blown AST-based analyzer for every edge case or stick to a faster heuristic model. We eventually went with a hybrid approach, but that early architectural back-and-forth cost us some serious dev time.

Then there was the "Accuracy vs. Speed" trade-off. Predicting CO2 impact is tricky - it's easy to be "kind of" right, but much harder to be accurate when you're factoring in different hardware profiles. We had to pivot several times to make sure our "consultant" wasn't just hallucinating numbers.

Our Biggest W's

It actually works: We successfully built a hybrid engine that doesn't just "talk" about optimisation - it actually parses code, promotes it to our IR, and generates refactors that don't break the build. Imagine how much better your code would be if you had a code review for every commit - that's what Greenlint can give you!
The "So What?" Factor: We didn't just show a diff; we showed actionable consequence. Seeing a 20% reduction in estimated energy use after a single refactor made the "carbon tax" feel real - because it is!
Zero-Friction DX: Getting the tool working as a pre-commit hook was a huge win. If a dev doesn't have to change their habits to be sustainable, they'll actually do it. It makes adopting our tech (and, by extension, being more aware of energy anti-patterns) crazy easy.
Extensibility-First: Greenlint was built with a module-system and extensibility first. It is super easy to upgrade and extend with your own ideas and languages, and could allow for a massive ecosystem.

What we Learned

AI needs a leash: LLMs are great at brainstorming, but for something like C++ optimisation, you need deterministic guardrails to ensure you aren't introducing memory leaks while trying to save energy.
The Scale of Inefficiency: A "small" O(n^2) loop in a microservice isn't small when it's called a billion times. Optimisation at the source is the only way to scale.
Green Program Analysis is a Frontier: There is a massive gap in current tooling for energy-aware development. Most linters care about style or security; almost none care about the planet.

What's Next for Greenlint

Greenlint as an Agent: Moving Greenlint from an optional hook to an agent that can actively partake in PR/issue discussions on Github would be a huge accessibility win.
Language Expansion: Since we already use an IR, adding support for languages like Rust and Go or C# and Java is at the top of our list.
Granular Hardware Profiles: Refining our heuristic models with hardware-specific data (e.g., ARM vs. x86) for even more accurate energy auditing.
The Greenlint Marketplace: A community-driven set of "Green Rules" for specific industries, from FinTech to embedded systems.