Inspiration

Performance Guardian was inspired by a problem I have seen in modern software development: CI can tell us if code works, but it does not always tell us if the code is becoming slower, more expensive, or harder to maintain.

A merge request can pass all tests while still adding performance risk, like nested loops, blocking I/O, or complex logic inside a critical path. These problems are often found too late, after they affect users or production systems.

What it does

Performance Guardian reviews merge requests for performance risk before the code is merged.

It checks the project against a performance contract written in the repository. If a merge request changes important engine code, the flow looks for issues like:

• Nested loops in hot paths
• Blocking file, database, or network calls
• Expensive repeated work inside loops
• Benchmark budget regressions

When it finds a problem, it creates a clear merge request comment with the rule that was broken, the file and line, the risk, and a suggested fix. This is different from normal AI code review because it is not just giving general advice. It uses project specific rules, deterministic checks, and GitLab platform context to focus on performance governance.

How we built it

We built Performance Guardian as a GitLab Duo custom flow.

The project includes:

• A GitLab Duo flow definition
• A human-readable performance contract
• A machine-readable YAML contract
• Python CLI tools that scan the code
• Example bad merge requests for testing
• Suggested patch generation
• Merge request comment generation
• GitLab Orbit lookup for project memory and proven patterns

The flow runs inside the GitLab workflow and can be triggered from a merge request. It uses GitLab context, project files, and Orbit-backed knowledge to make the review more specific to the repository.

Challenges we ran into

One challenge was making the review useful without making it too broad. Performance problems can be subjective, so we focused on clear rules that are easy to explain and validate.

Another challenge was making the project work even when Orbit is not available locally. To solve this, we added fallback reference patterns so the demo still works in a repeatable way.

We also had to make sure the custom flow matched GitLab’s deployment format, so it could actually be published and used.

Accomplishments that we're proud of

We are proud that Performance Guardian is more than a demo idea. It has a working flow, local validation tools, test fixtures, and merge request output.

We are also proud that it shows a practical use of GitLab Duo and Orbit: not just reviewing code in general, but enforcing a real engineering contract at the point where teams already make decisions.

What we learned

We learned that AI code review becomes much stronger when it is grounded in clear rules and repository context. Instead of asking AI to “find performance issues,” we gave it a contract, critical paths, examples, and deterministic tools. That made the results easier to trust and easier for a reviewer to act on.

What's next for The Winning Project

Next, we would expand the performance contract with more rules, deeper benchmark comparison, and better support for different languages and frameworks.

We would also like to make the Orbit integration richer, so the flow can learn from more past merge requests, successful fixes, and team-specific performance patterns.

Built With

• gitlab
• python