GitLab explains why AI coders need platform context, not just code

Every week brings new demos of AI agents that turn a prompt into a pull request in five minutes. But the demos end at the commit. The PR does not reference the issue it was supposed to fix. The CI/CD pipeline fails because the agent did not know about a new linter rule. The security scan flags a dependency the agent added without checking the organization's approved list. These are context failures, and they decide whether AI coding speeds up delivery or creates rework.

Three levels of context

GitLab published a tutorial with Claude Code and a tutorial with Codex that demonstrate the same pattern: what changes when an AI agent gets more and more platform context.

Level 1: repository code only. You point the agent at the codebase and describe the problem. The agent reads files, proposes a fix and runs the build. The code works locally, but in a vacuum. The agent does not see the acceptance criteria from the issue, does not know the non-functional requirements and has not read the style standards in the CI config.

Level 2: repo code + GitLab issue. Connect the GitLab MCP server and the agent can read the issue before writing code. Requirements, implementation notes, labels and milestones are now visible. The agent adds `Closes #32` to the MR description because it understands the link between the change and the issue. It uses `get_issue` and `create_merge_request` with the correct references. This time the fix matches the team's plan.

Level 3: the agent works inside the merge request. GitLab Code Review Flow leaves feedback automatically. The agent is invoked as an external reviewer to address the comments:

• adds missing tests
• updates documentation
• closes validation gaps
• commits changes directly to the MR branch

The pipeline validates the new commit. The human reviewer sees the result in a single tool, with no context switching. The outcome: fewer review rounds and faster merges.

Context matters most for security

AI coders produce code quickly. More code means more potential vulnerabilities, more scanner findings and more fix MRs to review. The bottleneck used to sit on the security side: scan, prioritize findings, escalate critical ones, wait for fixes. Now the bottleneck is shifting. The workflow moves from "which vulnerability to fix first" to "which AI-generated fix MR to review first."

That decision requires context a local agent does not have: the surrounding application code as a whole, the full data flow, deployment targets and the organization's security policies. With full context, prioritization becomes more accurate. An agent that sees the surrounding code and applicable policies ranks findings by actual exposure in your environment, not by generic severity scores.

GitLab's security layer analyzes findings with full project context, filters out false positives and flags confirmed vulnerabilities. Once a vulnerability is confirmed, agentic SAST resolution automatically creates an MR with a fix. The pipeline validates it. A reviewer approves it. Governance stays intact.

How to get started

Invest in AGENTS.md, a file of custom instructions. Document how the repository works, which commands to run and what quality expectations apply. It is a one-time investment that pays off in every agent session.

Watch how context is consumed. If sessions are slow or results are shallow, the problem lies in the context you feed the model. Structured context through platform integrations works better than raw file dumps.

Make sure all projects are scanned by security tools. Enable Security Configuration Profiles at the group level.

What this means

AI coders work reliably only when the platform gives them context and guarantees that their output passes quality gates. Five-minute demos in a vacuum do not reflect production reality. Organizations that systematize context through the issue tracker, pipeline, security policy and code review standards will gain a competitive advantage.