For builders

GitLab

What I love and hate about building with GitLab

I built two merge-request agents on GitLab, one with Duo Flows and one on the Duo Agent Platform with Orbit. These are the experiences that stuck with me.

2 projects 2 competitions Duo Flows, Duo Agent Platform, Orbit knowledge graph

What I loved

  1. Orbit traced a one-line change to a documentation promise three hops away and an unopened test

    Intent Guard at GitLab Transcend Hackathon, Jun 2026

    What I was trying to do
    Intent Guard is a review bot for GitLab merge requests. A repository declares its product promises in a plain file, INTENT.md: each promise names the function it depends on, the documents that must stay in step with it, and the tests that prove it. When a merge request touches that function, the bot should list everything that may now be out of date. Orbit is GitLab's knowledge graph of a codebase: which function calls which, and what depends on what.
    What happened
    In the demo repository a one-line change narrows who qualifies for full Medicaid coverage. The code compiles and the tests stay green. Intent Guard asked Orbit one question, "what else depends on this?", and walked outward through everything that calls the changed function, and everything that calls those. It found two of the three declared promises only transitively, one of them a documentation guarantee three hops from the changed line, and it named a test that nobody had opened in the merge request and that was now silently asserting the old rule.
    Why I loved it
    That is the map I would otherwise have built by reading code by hand, and Orbit had it already. The graph is genuinely good at code-to-code coupling. What it cannot see is the coupling between code and prose, so the documents still come from the hand-written list in INTENT.md.

    From the Intent Guard write-up

What I hated

  1. Orbit had quiet traps once I used real data

    Intent Guard at GitLab Transcend Hackathon, Jun 2026

    What I was trying to do
    The same project had to query Orbit two ways, locally (Orbit Local, a database on my machine queried with SQL) and against GitLab's hosted graph (Orbit Remote), and run as a flow on the Duo Agent Platform, GitLab's way of running an agent inside a merge request.
    What happened
    Nothing failed loudly; results were simply missing until real data exposed why. Constants defined at the top of a file do not exist in the graph, no node and no call edges, so a policy written as a top-level list was invisible to the traversal and the logic had to move inside function bodies to be traceable. Orbit Local and Orbit Remote speak different query languages, raw SQL for one and a relationship-selector language with required project scoping for the other. The Agent Platform's flow editor expected a different YAML shape than the file committed in the repository. And a graph that has gone stale has to be reindexed by hand before it answers correctly.
    Why I hated it
    Each of these was quiet: no error, just a wrong or empty answer, and every one only showed up once the repository was real instead of a toy. Other entrants ran into the same edges: Orbit's "Query Graph" tool kept reporting "not available" until someone found the MCP endpoint worked instead, and a Duo Workflow outage broke gateway connections mid-event.

    From the Intent Guard project story

  2. Duo Flow's file-reading behavior was unclear enough that v1 hardcoded the policy

    Drift Guard at GitLab AI Hackathon, Mar 2026

    What I was trying to do
    Drift Guard is an agent built with GitLab Duo Flows, which runs an AI agent inside GitLab with tools to read a merge request and post comments on it. It scans the new imports in a merge request against architecture rules, for example that frontend code must not import backend modules. Those rules were supposed to live in a .drift-guard.yml file in the repository so every team could set its own.
    What happened
    I expected the agent to be able to read a file from the repository. From the toolset it was not clear whether it could, so the first version hardcoded the rules into the agent's system prompt. Only after experimenting with the tools did read_file turn out to be the way to load the policy file, and the tool became configurable per repository.
    Why I hated it
    The difference between a demo with rules baked into a prompt and a tool a team can actually adopt was one tool I had to discover by experiment rather than by reading.

    From the Drift Guard project story

Everything I built with GitLab

2 projects from the participation archive, newest first.

  1. Intent Guard

    A one-line change can leave an entire project out of sync. Intent Guard uses GitLab Orbit to find what was left behind.

    GitLab Transcend Hackathon

    Demo Project

  2. Drift Guard

    Drift Guard turns every merge request into a lightweight architecture review, detecting structural drift before it becomes technical debt.

    GitLab AI Hackathon

    Demo Project

GitLab on the participation page All the platforms I built with