AI has access to your code. It doesn't have access to why your code exists.

The context gap

Spend a few hours pairing with an AI coding assistant on a real, long-lived codebase and the gap becomes obvious fast. The model reads the code well. It suggests reasonable implementations. But it has no idea why the architecture is shaped the way it is. It doesn’t know about the customer complaint that drove the last refactor, or the constraint that made the obvious solution wrong three years ago, or the sprint goal that means this particular ticket is blocking everything else.

That context lives in your project management system — in issues, in comments, in sprint boards, in the history of what was discussed before a decision got made. And almost none of it is accessible to AI tooling.

What a GitLab instance actually contains

A self-hosted GitLab that’s been used seriously for a few years is one of the richest sources of development context that exists. Every issue is a record of why something needed to change. Every comment thread is a record of how that decision got made. The sprint board is a real-time picture of what the team committed to and where it’s at. The milestone history is the pattern of what gets estimated correctly and what doesn’t.

None of this is in the codebase. When a developer leaves, most of it goes with them. Making it accessible to AI tools is the same problem as keeping it accessible to humans — it requires a structured interface, not just a place to put text.

MCP as the bridge

Model Context Protocol is a standard for giving AI tools controlled, structured access to external data sources. Instead of copy-pasting issue descriptions into a chat window, an MCP server exposes live project state through a typed interface the AI can query directly — sprint state, issue details, milestone progress, commit-to-issue linkage.

The governance model matters here. Read access to issues is fine. Writing to issues, closing milestones, modifying sprint assignments — those are write operations that should require explicit confirmation, with dry-run defaults and a kill switch. The architecture enforces that split. Read is open; write requires intent.

Three modes for three moments in a sprint

Sprint context isn’t a single question — it’s a different question depending on where the team is.

Kickoff: What are we committing to? The AI reads the milestone, the open issues, and the backlog state, and helps the team understand what’s realistic given velocity and current capacity.

Check-in: Are we on track? Mid-sprint, the same data tells a different story — how many days elapsed, what’s closed, what’s stalled, what needs to be cut or pulled forward.

Retrospective: What do we carry forward? Post-sprint, the data becomes a learning artifact — what got estimated correctly, what didn’t, what patterns emerged. The AI can draft an updated milestone description that reflects what actually happened versus what was planned.

The broader point

Making development context accessible to AI tools is the same problem as making business data accessible to AI tools. The answer is the same: a structured interface with defined permissions, not open-ended access to everything. The difference between AI that helps a team and AI that confidently makes things worse is usually the quality of the context it’s working from.