The DevEx Flow Orchestrator

• 

  managing issues on merge requests.

🌊 The Inspiration: Killing the Bureaucratic Context Switch

Let’s be real: context switching is the enemy of developer productivity. You’re in the "flow state" writing code, and suddenly you have to stop, navigate to a GitLab board, manually create a ticket, link your commit, and transition a bug to closed. While creating a Merge Request is technically a context switch itself (unless you use the GitLab CLI), I wanted to completely eliminate the bureaucratic paperwork. The goal was simple: let developers stay in their editor. Thanks to the GitLab IDE extension, a dev can view their assigned issues, write their code, drop standard git commits in their terminal, and let an AI handle the entire issue lifecycle in the background.

🏗️ How I Built It

I built The DevEx Flow Orchestrator natively on the GitLab AI Agent framework using an ambient environment Flow.

I created a headless "MR-Sweep" architecture. When a developer pushes their branch and opens a Merge Request, they simply mention or assign the bot. The Orchestrator wakes up, fetches the MR context, and batch-processes the commit history, routing each commit through specific logic:

• The Creator Path: If it sees a commit like ticket(database): Update Redis Cache, it autonomously creates a brand new formatted issue.
• The Librarian Path: If it sees conventional commits (like fix: or feat:), it fuzzy-searches for existing open issues, leaves a note linking the commit, and automatically closes the issue if it was a bug fix.
• The Report: It finishes by posting a clean, single-comment Master Report to the MR thread summarizing everything it created, linked, and closed.

🚀 The Future Vision: True Pipeline Autonomy

Right now, the Orchestrator sweeps and closes issues when the MR is opened. However, the true "fully autonomous" endgame for this tool is pipeline-driven execution.

In a production environment, issues shouldn't officially close until the maintainer actually merges the code into a target branch (like main or dev). In the future, by utilizing native GitLab Pipeline Triggers, this Flow will run completely silently. The moment a maintainer hits "Merge" and the pipeline succeeds, the AI will automatically trigger, read the merged commits, and reconcile the issue board without a single human @mention required unless needed for some.

🚧 The Challenges (And the Pivots)

Building this in the hackathon sandbox was a massive learning experience because it mimics a locked-down enterprise environment.

• Role-Based Access Control (RBAC) Pivot: Because we were provisioned with standard Developer access rather than Maintainer access, I was locked out of those pipeline triggers and custom CI/CD hooks I needed for the "Future Vision" mentioned above. I pivoted to the "MR-Sweep" model using Mention/Assign triggers. Honestly, this ended up being a highly token-efficient workaround—batch-processing an entire MR in one go is much cheaper than pinging an LLM on every single micro-commit.
• The Phantom Schema Errors: The backend catalog sync validator was incredibly strict. It kept throwing a phantom tool_name is missing here! error. After digging into the open-source schemas, I realized the MR-specific tool I was trying to use wasn't in the platform's whitelist yet. I adapted by swapping to a generic list_commits tool.
• Fixing API Over-fetching: Using that generic commit tool introduced a new problem: it fetched the entire branch history. In one test, the bot tried to process all historical commits instead of just the new ones! I had to engineer "prompt-level blinders"—strict instructions forcing the LLM to filter commits by the MR creation date so it wouldn't hallucinate actions on old, already-merged code.

💡 What I Learned

This project taught me that building a resilient AI agent is about a lot more than just stringing tools together. It requires building around strict CI validators, managing API load (preventing over-fetching), and designing workflows that respect real-world enterprise permissions.

My absolute favorite takeaway was seeing the LLM's semantic reasoning in action. I proved that a developer could write a messy commit like fix(frontend): resolve the 504 gateway bug, and the AI was smart enough to natively fuzzy-match that to a formal ticket titled Browser times out when fetching statements.

It bridges the gap between developer shorthand and formal project management, completely friction-free.

Built With

• gitlab
• gitlab-ci
• gitlab-duo
• prompt-engineering