Inspiration
AI code review tools are getting better at reading diffs, but they can still miss the wider architecture behind a repository. A small merge request can look harmless locally while silently bypassing an important layer, skipping an existing service, or affecting modules that are not visible in the changed files.
Orbit Guardrail Agent was inspired by this problem: how can GitLab Duo workflows review merge requests with repo-wide architecture awareness, not just local diff awareness?
The goal is not to replace human reviewers. The goal is to give reviewers a clearer architecture-aware briefing before they approve a risky change.
What it does
Orbit Guardrail Agent analyzes a GitLab merge request scenario and generates an architecture-aware guardrail briefing for reviewers.
The MVP focuses on one clear deterministic rule:
Controller should not directly access Model when a Service layer exists.
The expected flow is:
Controller → Service → Model
The risky detected flow is:
Controller → Model
In the demo scenario, InvoiceController::store directly calls InvoiceModel::create, bypassing InvoiceService.
When the agent detects this pattern, it produces a merge request briefing that includes:
- the changed architecture-sensitive file,
- the detected architecture violation,
- the expected flow versus detected flow,
- repo-wide blast radius,
- affected modules,
- suggested test coverage,
- a reviewer checklist,
- evidence context separating dry-run/demo evidence from live GitLab MR posting evidence.
The prototype also posts a real review comment to a GitLab merge request using the GitLab Notes API. The repository includes a redacted live MR run record with posted: true, dry_run: false, a run ID, and a note ID.
How we built it
The project is designed around a small adapter-based architecture.
The prototype uses deterministic local Orbit-style and LynkMesh-style fixtures for the demo scenario. The Orbit-style fixture represents GitLab-native merge request context, while the LynkMesh-style context pack provides architecture and impact context for the guardrail engine.
The core flow is:
Demo MR scenario → Orbit-style context fixture → LynkMesh-style context pack → Guardrail engine → Briefing renderer → GitLab MR adapter → GitLab Notes API comment
The guardrail engine evaluates the architecture rule, and the briefing renderer turns the result into a reviewer-ready merge request comment.
For evidence, the project includes:
- automated tests,
- mock end-to-end flow,
- real GitLab MR posting mode,
- redacted live MR run evidence,
- custom GitLab Duo agent evidence,
- private AI Catalog visibility evidence.
A custom GitLab Duo agent named Orbit Guardrail Agent was also created and tested in the hackathon workspace. It correctly explained the architecture guardrail, separated dry-run evidence from live MR posting evidence, and identified what remains future work.
Challenges we faced
The biggest challenge was avoiding the “AI demo trap”: building something that looks impressive but is unreliable or overclaimed.
Instead of attempting broad automated code generation, we intentionally focused on a narrow and practical workflow: merge request guardrail review.
Another challenge was positioning LynkMesh correctly. LynkMesh is not meant to replace GitLab Orbit. In this prototype, LynkMesh-style context enrichment acts as a repository-aware context layer behind the guardrail workflow, helping the GitLab Duo flow become more architecture-aware.
We also had to keep the evidence clean. The project explicitly separates deterministic dry-run evidence from live GitLab MR posting evidence, so reviewers can see exactly what was proven.
What we learned
We learned that useful developer agents need more than language-model output. They need structured context, deterministic evidence, workflow integration, and clear boundaries.
A good AI reviewer should not only say whether code looks valid. It should help reviewers understand how a change may affect the architecture of the whole repository, what downstream workflows might be affected, and what tests should be checked before merging.
We also learned that evidence design matters. A strong AI developer-tooling submission should show the final output, but also the provenance behind it: run records, note IDs, screenshots, tests, and honest scope boundaries.
What's next
Next, we want to move beyond deterministic local fixtures and connect the workflow to deeper live GitLab context.
Future work includes:
- live GitLab Orbit API ingestion,
- automatic merge request trigger execution,
- public AI Catalog publication,
- production CI/CD enforcement,
- more architecture guardrail rules,
- support for additional repository patterns,
- configurable team-specific architecture policies,
- a richer LynkMesh-backed context graph.
The long-term direction is to make architecture-aware review available directly inside GitLab merge request workflows, so AI-assisted review can help teams catch risky architectural drift before it reaches production.
Log in or sign up for Devpost to join the conversation.