Self-Hosted AI-Assisted Development Workflow

Project Overview

AI assistance in IDEs is common now. The interesting gap for me was the orchestration layer: wiring self-hosted GitLab, a planning app I built called Backlog, and Cursor agent behaviour into something consistent. Backlog is a planning and tracking application with richer context than the GitLab issue UI. This workflow is also how I learn to build MCP and agentic-AI tooling against that GitLab instance—including an early attempt to recreate a GitLab MCP—and use it to move small project tickets forward that would otherwise not receive time.

The automation is organised around three named roles—Heimdall, Thor, and Mímir—deliberate hats so humans and automation know which kind of work is in flight:

• Heimdall — in Norse myth, the Watchman of the Bifrost Bridge: always vigilant, deciding what may cross. Here he owns orchestration and triage: what to pick up, in what order, under which constraints.
• Thor — the action-taker who gets things done. Here he owns execution: implementation, tests, commits, and merge request preparation.
• Mímir — keeper of the Well of Wisdom (Mímisbrunnr), holding accumulated knowledge. Here he owns the knowledge layer: rules, skills, documentation, and context that keep the other roles aligned.

They are not separate products—they are named responsibilities so automation and human review share a clear vocabulary.

Why It Was Built

Infrastructure work genuinely interests me, and it applies at work, so it wins my attention. Programming projects are either already usable or not something I need day to day, so their development stalls. I disliked that pattern.

This workflow exists to fix programming throughput. Self-hosted GitLab, Backlog, and Cursor rules are the constraint I design around—not the reason I started. The reason is getting more real code shipped when the interesting default is platform work. Cloud models remain part of how I work; the self-hosted pieces are GitLab, Backlog, and the integration tooling around them—not a claim that every model runs on-prem.

The gaps I needed to close:

• Issue tracking off-repo — GitLab issues alone did not carry enough product context; Backlog fills that role but needed tool access from the IDE
• No trigger model for agents — labelled issues and mentions needed a reliable pickup path into Cursor
• SaaS mismatch — cloud-centric tools do not see private GitLab, private Backlog, or homelab deployment constraints

Where Delegation Stops Working

Fully handing tickets to an automated worker sounds appealing until latency shows up. Without babysitting, one small AI misunderstanding—or an imprecise ticket I wrote—produces wrong code. Steering via comments on the ticket meant long waits; a full automated rewrite was hard to get right.

Complex work needs many corrections. Async correction through tickets and merge requests is expensive. Working with the AI in the IDE (seconds per correction) beats ticket/MR delegation for anything that needs judgment.

I own that: ticket precision matters, and imprecise tickets are partly on me. The worker still keeps small, well-scoped work moving so my attention stays on the work that actually needs me in the loop.

Core Components

Self-Hosted GitLab

GitLab remains the system of record for source code, merge requests, and CI/CD. Agent work is expected to land as branches and MRs, not direct edits on running systems.

GitLab Backlog

Backlog holds richer issue context—priorities, labels, notes, and cross-project visibility—outside the narrow GitLab issue UI. It is the planning surface agents and I share.

Backlog MCP

A Backlog MCP server exposes that tracker to Cursor: list and fetch issues, suggest work branches, create merge request payloads, and resolve the current repository to the right Backlog project. That removes copy-paste between the tracker and the editor.

Reusable Cursor Rules and Skills

Shared rules encode non-negotiables: git commit style, container-only test commands, homelab safety, secrets handling. Skills encode repeatable procedures—GitLab MR workflow, SOPS secrets, compose-based testing. Together they make agent sessions predictable across repositories.

TypeScript Worker (Cursor SDK)

The automation piece is a TypeScript worker built on the Cursor SDK that runs against the self-hosted GitLab instance. It picks up work from labels and mentions, fetches issue and repository context, applies the relevant rules and skills, and reports back through issue notes or merge request updates.

That closes the loop between Backlog planning, GitLab execution, and Cursor-assisted implementation for work that is small enough to run without constant steering—while I stay in the IDE for everything that is not.

What It Produced

• A Backlog MCP image and configuration usable from Cursor across my projects workspace
• A shared rules and skills bundle linked into multiple repositories
• Label and mention conventions that I and the worker both understand
• Repeatable MR workflow—branch from issue, conventional commits, explicit git add, pipeline awareness
• Early worker automation for issue pickup, scoped edits, and MR hygiene on the self-hosted GitLab instance

Lessons Learned

• Triggers must be explicit. Labels and mentions beat free-form chat for knowing when an agent should act.
• MCP is the glue. Without structured Backlog access, agents invent issue state.
• Rules are the contract. Skills and rules do more for consistency than a larger model does.
• Delegation has a latency floor. Complex work needs IDE-speed correction; the worker earns its keep on scoped tasks that free my attention.