One of the things I admire about GitLab is its relentless monthly cadence. Every month, a new release. Sometimes they’re small tweaks that barely ripple the surface. Other times, like the drop on September 18th—version 18.4—they carry weight. This one matters, not because it’s flashy, but because it changes the control levers for platform teams in three areas that define where we’re all headed: AI policy, code discoverability, and repo hygiene.
On paper, the features don’t scream headlines. But look closer and you’ll see something bigger: GitLab Duo Model Selection goes GA, the GitLab Knowledge Graph arrives as a new foundation project, and a subtle but important toggle lets CI/CD job tokens authenticate Git push requests. Together, they form the kind of release that won’t light up TechCrunch but will change how platform engineers build guardrails in an AI-driven, automation-heavy world.
AI Policy Gets Centralized: Duo Model Selection
Let’s start with GitLab Duo. For months, Duo’s AI features have been rolling out in beta form, powered by large language models (LLMs). Great—but messy. Each team, each IDE, each context seemed to carry its own model preferences. It was a recipe for drift, cost sprawl, and compliance headaches.
With 18.4, Duo Model Selection is now generally available at the org and group level. That means platform teams can set the defaults—“this is the model we use for code completion,” “this is the model approved for chat”—and know it sticks. Developers still get flexibility, but it’s within the guardrails of approved models.
This is how you scale AI responsibly. You don’t want every developer (or every AI assistant) bringing their own brain to production. You want a policy. With Model Selection GA, the policy lives in GitLab, not in the wild.
For platform engineers, the play is clear: Codify these defaults in your internal developer portals and golden path templates. Don’t leave it up to chance. Document exceptions. Define who approves an override. And remember—AI copilots can be brilliant, but they can also be expensive. Brokered model choice isn’t just governance; it’s cost control.
As I like to put it: AI copilots shouldn’t be BYOB—bring your own brain. Someone has to decide which brains are allowed in the system.
Knowledge Graph: Context as Infrastructure
The second headliner is GitLab Knowledge Graph—a new project that treats your repos as a graph of relationships, dependencies, and ownership. On the surface, it’s just metadata. But in practice, it’s the substrate for something bigger.
We’ve been talking about inner-sourcing for years. Letting teams discover and reuse code across silos. Golden paths that guide developers to do the right thing by default. The problem? Most of our portals are static. They rely on teams to keep catalogs up to date. Spoiler: they don’t.
A knowledge graph changes that equation. Imagine a graph that knows which services depend on which libraries, who owns what, and where the hotspots are. Now plug that graph into your IDP or Backstage portal. Suddenly, scaffolding templates aren’t just arbitrary—they’re grounded in reality. Developers don’t just get a path; they get a map.
Is Knowledge Graph production-ready today? No, it’s early. But directionally, it’s important. Platform teams should start experimenting now. Pick a portfolio of critical services, wire the graph into your portal, and see how it changes discovery and reuse. Don’t overpromise “AI omniscience.” Do use it to strengthen your golden paths.
We’ve been promising golden paths for years. A graph finally gives us the asphalt map beneath those roads.
Safer Automation: Job Tokens for Git Push
The third change is quieter but may end up the most impactful: projects can now (optionally) allow their own CI/CD job tokens to authenticate Git push requests.
If you’ve ever wired up automation to make repo changes—dependency bumps, version updates, code formatting—you know the pain. Historically, that meant sprinkling personal access tokens (PATs) across runners. PATs are long-lived, broad in scope, and terrible for security.
Now GitLab lets you flip a switch (off by default) that allows a project’s own job tokens to push to its own repo. Scoped. Ephemeral. Limited blast radius. It’s a small feature, but it mirrors the same best practices we’ve seen with OIDC ephemeral auth in GitHub land. Bots need credentials too, but now they can have just enough, for just long enough.
Platform engineers should tread carefully here. Keep it off by default. Enable it only where automation is vetted. Pair it with branch protection and signed commits. But if you’ve been looking for a cleaner way to let bots push code without hoarding PATs, this is the path forward.
From PATs to Ephemeral Push
The Old Way
- Long-lived PATs sprinkled across runners.
- Broad scopes, minimal oversight.
- A single leaked token = disaster.
The New Way
- Scoped, ephemeral job tokens tied to a single project.
- Opt-in, off by default.
- Safer automation for repo hygiene.
Lesson: treat GitLab job tokens the same way we treat OIDC creds—short-lived, least-privileged, policy-first.
Risks and Realities
Let’s not sugarcoat it. These features solve problems, but they also introduce new ones:
- Model policy drift. Letting end users override AI models is good UX, but risky for cost and compliance. Keep an eye on it.
- Knowledge Graph hype. Useful, yes. Magic, no. Start small, measure, and scale carefully.
- Token push misuse. Enabling job-token pushes without branch protection is asking for trouble.
Shimmy’s Take
GitLab 18.4 won’t get splashy headlines. But in the trenches of platform engineering, this is a consequential drop.
- Duo Model Selection GA gives you a real lever to govern AI at scale.
- Knowledge Graph lays the foundation for smarter discovery and golden paths.
- Job Token Git Push offers a safer way to let bots do their job without sprinkling long-lived secrets everywhere.
If the last era of DevOps was about speed, this one is about control. Control over which AI models get to touch your code. Control over how developers discover and reuse code across the org. Control over how automation interacts with your repos.
GitLab just handed platform teams three new levers. The question is: Will you pull them?