Could GitLab + Coder = End of GitHub?
[1st Hand] field report on the potential partnership Microsoft should worry about
Hope this letter finds you all well.
So much still to unpack just from the agent conference, let alone trying to keep up with the lightspeed pace of AI running on more affordable hardware. (Unrealized local potential from models like Gemma 4b, Qwen 27b..)
But one of my most memorable encounters from the conference, (read this letter if you are not up to speed: [So I Went to Manhattan for the AI Agent Conference [2026]) was with a 30 year dev that now works for Coder.com and sold me at the booth. Keep in mind, anyone that walks around is getting sold by the workers at the event; of which, coder.com was one. This guy was kind of just like…no need to sell. Which caught my attention.
Come to find out, he was one of the original developers behind the initial release of Xbox Live itself via Kubernetes.
He told me that GitLab and Coder.com are in real talks to merge…which is why I am now writing this letter to you; to explain how this marriage could end a hallmark like GitHub.
What he described, when I pushed, was not a product roadmap. It was a structural argument. The forge GitHub built its empire on is an authentication and collaboration layer for human contributors. Every assumption it ships with, from rate limits to permission scopes to seat based pricing to the very shape of the pull request, encodes the constraint that contributors are humans typing at human speed.
The instant that constraint breaks, and it is breaking now, the forge stops being an asset and starts being a liability. The replacement, he said, was going to be self hosted source control fused with self hosted, policy bound development environments. In plain English: GitLab plus Coder (which…does not yet exist).
I went home and pulled on the thread. The more I read, the harder it was to argue with him. This is what I think is happening…and why I think the window for incumbents to respond is shorter than everyone is acting like it is:
THE REAL PROBLEM IS NOT VOLUME, IT IS PRINCIPALS
The easy version of this argument, the one you hear at every agent panel, is that agents commit more code than humans so the forges will get overwhelmed. That framing is correct but shallow. The volume problem is real and fixable. The deeper problem, the one that is not fixable inside the existing architecture, is that agents are not high speed humans. They are a different category of actor entirely.
GitHub’s identity model has one kind of citizen: a user, with an email, a 2FA device, and OAuth scopes. Everything else, deploy keys, fine grained tokens, GitHub Apps, the coding agent itself, is a hack bolted onto that single primitive. There is no first class concept of a non human principal that can be born, given a narrow mandate, watched while it works, killed, and have its actions automatically attributed back to the human who authorized it. The platform was not built with that abstraction because in 2008 there was no need for it.
In 2026, it is the only abstraction that matters.
An agent loose on your codebase is closer in kind to a contractor with elevated privileges than to a faster developer. It needs a scoped identity, a sandboxed environment, an explicit task, an expiration time, an audit trail, and a chain of accountability back to a human. None of those exist as first class objects in GitHub. They exist informally, glued together with personal access tokens and webhook secrets, and that glue is exactly where every credible piece of offensive security research in the last twelve months has found purchase.
This is why the architectural fight is happening below the application layer and not inside it. You cannot bolt non human principals onto a platform that was designed around the assumption of a human at every endpoint. You can only build the abstraction from scratch, or you can buy a platform that already has it. GitLab’s single application model and Coder’s workspace primitive, taken together, are the only combination on the market right now that gives an enterprise both halves.
WHY GITHUB CANNOT JUST FIX THIS
The standard rebuttal here is that Microsoft is the most resourced software company on earth and if there is a gap they will close it. They will ship features, yes. They have already shipped some. But the structural reasons they will not close the gap on the timeline that matters are worth being explicit about, because most analysts are still treating Microsoft’s response as a foregone conclusion.
First, GitHub is six products federated under one brand. GitHub.com, Actions, Packages, Codespaces, Advanced Security, and increasingly Azure for the parts that GitHub does not cover. The product was assembled through acquisition and organic growth, not designed.
Second, GitHub’s revenue model is structurally hostile to the agent era. Seat pricing assumes a roughly fixed ratio of contributors to value generated. The instant one developer is dispatching ten agents, that ratio breaks. Microsoft has two options and both are bad. Charge per agent and watch enterprises slow walk adoption to manage cost. Eat the cost and watch margin compress at the exact moment Copilot is already squeezing margin from the other side. GitLab’s pricing, which is built around CI minutes and compute rather than seats, sits much more comfortably in a world where most contributors are code, not people.
Third, Copilot is undermining the bundle from the inside. Every quarter Copilot wins on its own, the customer learns that the model vendor and the forge vendor can be separated. That lesson, once internalized at the CTO level, generalizes. If the model is detachable, why is the IDE not detachable? If the IDE is detachable, why is the CI runner not detachable? If the CI runner is detachable, what exactly am I paying GitHub Enterprise for that I could not get from a forge whose entire pitch is that I own the pieces? Microsoft is winning the model fight, briefly, at the cost of teaching its customers how to unbundle the platform underneath the model.
Fourth, the on premise version of GitHub, GitHub Enterprise Server, lags the cloud product by months and is treated internally as a tax rather than a strategy. The customers who care most about agent governance are exactly the customers who cannot use GitHub.com as it is built today. Microsoft would have to invert itself, become an on prem (local) first company for its most lucrative segment, to win that fight head on. They will not. They will ship VPC variants and dedicated tenancy and call it sovereign. The customers who matter will see the difference.
WHAT GITLAB ACTUALLY IS
GitLab is the boring incumbent whose obituary the industry has rewritten every two years and kept being wrong about. Here is what is actually true about it.
It is a single application. One codebase. One database. One permission model. One audit log. Inside that single application you get source control, code review, CI, package registry, container registry, security and dependency scanning, secrets detection, issues, planning, wiki, deployment, and an AI assistant that talks to all of the above. You can self host the whole thing with one Helm chart. You can air gap it. You can run it in a SCIF. You can deploy it on a submarine if you have the right people and a bad enough afternoon.
In the human era this was an acquired taste. Buyers tolerated GitHub’s federation because nobody was forcing them to write the unified governance query.
In the agent era, the unified governance query is the product. Every regulator currently drafting a rule about AI in production code, and there are several, is going to demand a version of it. The platform that can answer it with one SQL statement against one database is going to look fundamentally different from the platform that needs to compose six APIs and reconcile three identity systems to produce the same answer.
This is why the boring incumbent is suddenly interesting. The thing GitLab has been right about for ten years, and largely punished for in the public markets, is the thing the next ten years is going to reward.
WHAT CODER ACTUALLY IS, AND WHY THE CODESPACES COMPARISON MISLEADS
Coder gets compared to Codespaces or Gitpod, and the comparison is shaped right but pointed in the wrong direction. Codespaces is a SaaS workspace. You click a button, Microsoft hands you a VM in their cloud, you write code, they bill you. The compute is theirs, the boundary is theirs, the policies are theirs.
Coder is not a workspace. Coder is a control plane. You install it on infrastructure you already own, Kubernetes or VMware or bare metal or AWS or whatever sovereign cloud your jurisdiction requires, and you define a workspace as a Terraform template. Base image, resource limits, network policies, egress allowlist, secret injection, identity binding, lifecycle.
When a developer or agent needs a workspace, Coder provisions one from your template, on your infrastructure, under your policies, with your observability hooks attached. When the task ends, the workspace evaporates and the credentials it held expire with it.
If you read those previous two paragraphs carefully you will notice it has almost nothing to do with developer experience and almost everything to do with how you would build an isolation primitive for a non human principal. That is the point. The agent era is not primarily a DX problem. It is a blast radius problem. Whoever ships the cleanest answer to “where does an agent live, what can it touch, how do I watch it, and how do I kill it” wins the layer of the stack that every other layer is going to depend on.
WHAT THE DEAL MUST CONTAIN TO MATTER
He did not tell me a deal was signed. He told me the shape of one. Here is what a serious GitLab and Coder partnership would have to ship, beyond co marketing, to actually move the market.
A workspace primitive native to the GitLab project. Open a repository, click a button, get an isolated, policy bound environment with the repo cloned, dependencies installed, secrets injected, and egress restricted. The template lives in the GitLab repository alongside the code. Platform teams own it. No drift, no bootstrap script that the agent has to negotiate from scratch, no surprise dependency that the agent installs because a model decided it was a good idea.
Federated identity with short lived, narrowly scoped tokens. The workspace gets a GitLab token bound to one project, one branch namespace, and a lifetime measured in minutes. When the workspace dies, the token is already invalid. A prompt injected agent that tries to pivot to another repository, exfiltrate to an external host, or persist credentials finds itself holding a token that does not authorize anything and a network that does not route.
Unified audit at the workspace identity level. Every file read, every command run, every commit pushed, every merge request opened, every pipeline triggered lands in the same audit log under the same identity as the workspace that produced it. The CISO query becomes a one liner. The compliance officer gets a real answer instead of an apology.
Cost attribution on infrastructure the customer already owns. The bill is a line item on a Kubernetes cluster the company already pays for, not a surprise SaaS invoice that scales with however many agents your engineering org decided to spawn this quarter. At fleet scale this is the difference between a sustainable platform and a budget incident.
That is the floor. The ceiling, if both companies execute, is an operating system for agent driven development. One place where you declare what agents are allowed to do, where you watch them do it, where their work is reviewed, and where the work that survives review becomes a deployment.
THE REGULATORY TAILWIND NOBODY IS PRICING IN
The reason I think this lands faster than the consensus expects is that the regulatory environment is about to do most of the selling for them, and almost no commentary I have read is taking that seriously yet.
The EU AI Act’s obligations for high risk systems came into force this year, and “code generation systems that materially affect production deployments in regulated sectors” is going to fall under high risk in every reasonable interpretation.
NIS2 requires demonstrable supply chain control for critical sectors across the EU and the deadline has passed. DORA, in financial services, demands operational resilience that explicitly extends to your software delivery pipeline.
In the US, federal procurement is quietly moving toward attestation requirements that no public SaaS forge can satisfy without operating a separate, lagging variant of its own product. Across regulated industries in roughly every G20 jurisdiction, the legal answer to “where does your code live and who can see it” stopped being “in the cloud, who cares” sometime in the last eighteen months and most procurement teams have not caught up.
The buyer for the forge has quietly changed. Five years ago the VP of engineering picked the forge and the CISO was a stakeholder. Today the CISO is the picker, and the VP of engineering is the stakeholder, and the CFO is auditing the agent line item every quarter because it is the fastest growing one. Once that is the buying committee, “single application, self hosted, single audit log, workspace level isolation, cost attributable to infrastructure we already own” is not a feature list. It is a procurement requirement.
This is the part Microsoft cannot beat with a better model. The model is not what the new buyer is buying.
THE FORCING FUNCTION
The reason the Coder dev said this was coming faster than people think is that the catalyst is not a product launch. It is an incident. The first time a publicly traded company has to disclose that a prompt injected agent inside a SaaS forge exfiltrated source code, pivoted to production, opened a backdoor merge request that got auto approved, or accepted a poisoned dependency that the model had no incentive to scrutinize, the agent governance conversation stops being a thought experiment at every other publicly traded company in the same week.
I do not know when that incident happens. Neither does anyone else. What I do know is that the surface area is growing exponentially, the offensive research is public, the median agent in production today is running with permissions a security review in 2019 would have rejected on sight, and the base rate for “this kind of incident occurs within eighteen months of conditions like these” is, historically, very high. Pick your favorite supply chain compromise of the last five years. The version of it that uses an agent as the delivery vehicle is shorter, cheaper, and more deniable.
When the incident lands, the companies that already have an answer for “agents run in Coder workspaces under GitLab policy on infrastructure we own” win the next two budget cycles of enterprise procurement. The companies that do not are going to spend those budget cycles writing memos explaining why they did not move sooner.
WHAT 2028 LOOKS LIKE IF THIS LANDS
Open source stays on GitHub. The network effect on public code is genuinely unbreakable on any reasonable horizon. Linus does not move the kernel. The npm ecosystem does not move. Hugging Face does not move. Your weekend project does not move. GitHub.com remains the global town square for public code and Microsoft remains a trillion dollar company that earned its place. Nothing in this thesis predicts otherwise.
The enterprise bifurcates. Banks, hospitals, defense, telcos, large law, pharma, and the upper tier of every regulated industry quietly migrate to a self hosted GitLab plus Coder stack and decommission GitHub Enterprise, Codespaces, hosted Actions runners, and Advanced Security in the same wave. The pitch writes itself: vendor consolidation, cost reduction, governance gain, regulatory defensibility. The first three reference customers are the hardest. After that it is a stampede, because in regulated industries nobody wants to be the company that did not move when their peers did.
The workspace becomes load bearing the way the container did after 2014. Today most teams do not have a name for the layer between “my laptop” and “production.” By 2028 they do, and the people who own that primitive own the workflow that runs on top of it.
GitLab’s AI story stops being an apology and starts being the product. Duo today is a Copilot chaser. Duo in a world where GitLab is the system of record for every agent action across the enterprise becomes something Copilot structurally cannot be, because Copilot does not have the unified data model underneath it. The model quality fight is the wrong axis. The right axis is “whose system can answer the questions a CISO actually has to ask,” and on that axis GitLab is positioned and GitHub is not.
The job called developer changes shape. Not “describe intent in plain English and a magic robot ships your product.” That fantasy will keep selling tickets at conferences and keep being wrong in practice. The actual shape is closer to fleet operator. You dispatch agents into governed workspaces, you review the diffs that survive policy, you merge what passes review, you deploy what ships. The IDE becomes a review surface. The forge becomes an orchestration layer. The number of people called developers does not shrink as much as the doomers think. The work each one does changes entirely.
WHAT TO WATCH OVER THE NEXT TWELVE MONTHS
Three signals.
One. A real GitLab and Coder integration. Not a co marketing webinar. Not a logo on a slide. A product. Templated workspaces tied to GitLab projects with token federation, policy enforcement, and unified audit. If that ships in 2026, the thesis is live and you should be paying close attention.
Two. A regulated industry reference customer. A name brand bank, a top ten hospital system, a major insurance carrier, a defense contractor publicly moving off GitHub Enterprise onto a self hosted GitLab plus Coder stack and citing agent governance as the reason. The first one is the hardest to land. The second one is the stampede.
Three. GitHub’s response. Specifically, whether Microsoft ships a true on premise, agent first, single application product, or whether they keep bolting features onto GitHub.com. The former means the fight is on. The latter means they are losing a segment without realizing they are losing it, which is how incumbents usually lose segments.
The forge was not built for this. Somebody is about to build the one that is. The person I met at the conference believes it is going to be them and GitLab, together.
After researching and building myself, I am inclined to believe him (i have 0 shares of anything coder or gitlab whatsoever, i get nothing out of sharing this)…
What do you think?
God-Willing, see you at the next letter
GRACE & PEACE