Yesterday, Cursor shipped Origin: a code host with pull requests, branch protection, a REST API, and a public URL structure (cursor.com/codebase/your-repo). On the surface, it looks like another GitHub clone. It is not. Origin syncs bidirectionally with GitHub, in seconds, so a comment made in Cursor posts to GitHub and a comment made on GitHub posts back to Cursor. GitHub stays the "source of truth" for now. That word "now" is the whole story.
GitHub did not lose its position because a competitor built a better repo host. It is losing its position because the thing that made it the default place code lives, a human-paced review loop, stopped being how most new code gets written.
The Bundling Accident
GitHub's dominance looks earned. 180 million developers, 630 million repositories, ranked the most admired developer tool in Stack Overflow's 2025 survey at 75.8%. Git itself runs 85% of version control. Every argument for GitHub's moat starts from those numbers.
But look at what GitHub actually bundled: hosting, pull request review, issue tracking, and CI hooks, all co-located around one assumption, that a human opens a branch, writes code over hours or days, and another human reviews it before merge. GitHub did not invent that loop. It hosted it well. The hosting was never the hard part; the loop was. Git itself is free, distributed, and was designed by Linus Torvalds explicitly so that no single host could ever be required. GitHub's moat was social and workflow gravity built on top of a commodity, not the commodity itself.
That distinction did not matter for eighteen years, because nothing challenged the loop. It matters now, because the loop is the part breaking.
The Loop GitHub Was Built For Is Breaking
In April 2025, Microsoft CEO Satya Nadella told Mark Zuckerberg at LlamaCon that 20 to 30 percent of code inside Microsoft's repos was already software-written. Five months earlier, Google CEO Sundar Pichai had told investors the same thing about Google: "more than a quarter of all new code at Google is generated by AI, then reviewed and accepted by engineers." GitHub's own Copilot tooling completes 46% of code for active users.
Machines writing a quarter to nearly half of new code is not the crisis. The crisis is that the review step downstream still assumes a human wrote it. LinearB's 2026 benchmark, drawn from 8.1 million pull requests across 4,800 teams, found agentic AI pull requests wait 5.3x longer for a reviewer to even pick them up: 1,055 minutes against 201 for unassisted PRs. Faros AI's telemetry across 22,000 developers found median PR review time up 441.5% between low and high AI adoption periods inside the same organizations, even as raw task throughput rose only 33.7%.
GitHub's review model was built to ration a scarce resource: human attention on human-written diffs. It has no answer for a queue where the diffs arrive faster than any team can staff reviewers.
The queue is not just longer, it is worse quality. CodeRabbit's December 2025 study of 470 open-source pull requests found AI-co-authored PRs carry 10.83 issues on average against 6.45 for human-only PRs, 1.7x more. A host built to move human-reviewed diffs from branch to main was never built to triage that.
Cursor's Bet: Own the Whole Loop
Cursor's answer was not to build a faster reviewer for GitHub's queue. It was to stop routing the loop through GitHub at all. In December 2025, Cursor acquired Graphite, the code review tool built around stacked pull requests, for well over Graphite's last $290 million valuation, according to Axios's reporting on the deal. Eight months later, Origin shipped: native hosting, natively wired to the same agents that write the code and the same review tool that checks it.
The demoed throughput number, 22.6 commits per second in one repository, is not a benchmark aimed at humans. No human team pushes at that rate. It is a signal about who Origin is actually built for: agents that clone, branch, write, test, and open PRs on their own, at a cadence GitHub's human-era architecture was never asked to sustain. Editor, agent, review, and hosting now sit inside one vendor's infrastructure. GitHub sync is a compatibility feature, not a dependency.
GitHub's Defense Is an Admission
GitHub is not standing still. In June 2026 it shipped the Copilot desktop app, described on its own blog as an "agent-native desktop experience": a control surface for supervising multiple AI coding agents at once, each running in an isolated git worktree, aggregated into a single "My Work" view across issues, PRs, branches, and background automations.
Read that framing carefully. GitHub is no longer positioning its core product as a repository host with pull requests bolted on. It is positioning itself as an orchestration layer for agents, the exact ground Cursor is fighting for. A company does not rebuild its flagship product around agent orchestration unless it has already concluded hosting alone can't hold the line. That is not a company confident its 630 million repositories are an unassailable moat. It is a company that watched the review queue break under CodeRabbit's 1.7x issue rate and built a supervision UI instead of trusting the old pull request screen to cope.
System of Record Follows System of Action
Here is the distinction underneath all of it. GitHub has always been a system of record: the durable, canonical place code lives once it's written. It was never a system of action, the place where the actual work of writing and deciding happens. For eighteen years that didn't matter, because the system of action was a human sitting in an IDE who chose, separately, to push to GitHub. Record and action were decoupled by the human in between, and either side could win independently.
Machines removed that decoupling. When an agent is the one writing the code, choosing the branch, and opening the PR, the system of action and the tool the agent runs inside are the same thing. Whoever owns that tool, Cursor, GitHub Copilot, Claude Code, Devin, owns the sequence of decisions the moment they happen. The system of record no longer gets to sit outside that sequence and wait for a push; it has to be wherever the action already occurred, or it becomes stale the instant it's written to. That is why Origin syncs GitHub in seconds instead of asking developers to push to GitHub first: the record has to catch up to the action, not the other way around.
A synced mirror can carry the code. It cannot carry the context that produced it. Whoever holds the context holds the loop.
I've made the opposite bet before and paid for it. Two years ago, running a six-person platform team, I picked a CI vendor specifically because its whole pitch was clean GitHub webhook integration, one dashboard, one source of truth. It held up fine at 15 human-opened PRs a week. Once we turned three engineers loose on Claude Code, we were opening 40, and the vendor's webhook queue started silently dropping status checks under load, checks going green without ever running. We migrated inside a quarter, not because the vendor was bad at its stated job, but because I'd scored it against GitHub as the system of record instead of against the agents that were about to become the system of action.
That merge gap is the real reason hosting stopped being the moat. Fixing a 32.7% acceptance rate is not a hosting problem. It requires the review tool, the test runner, and the agent that wrote the code to share context about what changed and why, in real time, inside one system, which is exactly the kind of coupling a repo host on the outside of that loop can never provide.
What This Means For Your Stack
Stop evaluating dev tooling vendors by whether they're "GitHub-compatible." Compatible means synced, not dependent, and every serious agent-native vendor is racing to make that sync invisible. The question that actually predicts where you'll be in eighteen months is narrower: does this vendor control the sequence, agent writes, agent tests, human or agent reviews, code merges, or does it only see that sequence after the fact, through a webhook?
If your CI, your security scanning, or your compliance tooling only integrates at the GitHub layer, you are building on the system of record in a year when the system of action is what's moving. That doesn't mean rip out GitHub tomorrow; Origin is in early beta, and GitHub still holds 630 million repositories of institutional memory no vendor replaces overnight. It means the next tooling decision you make should be scored on proximity to the agent, not proximity to the repo.
GitHub spent eighteen years as the place code lives. It is on track to spend the next few as the place code is merely kept. Those are not the same job, and only one of them is still worth building a company around.
Sources
- Cursor - Origin: code hosting for the agentic era (2026) - the changelog announcing Origin's launch, sync model, and API.
- Cursor - Graphite is joining Cursor (2025) - Cursor's own announcement of the Graphite acquisition and integration plan.
- TechCrunch - Cursor continues acquisition spree with Graphite deal (Dec 2025) - deal terms and valuation context for the Graphite acquisition.
- LinearB - 2026 Software Engineering Benchmarks Report - PR pickup time, size, and merge rate data across 8.1M pull requests.
- Faros AI - The AI Engineering Report 2026: The AI Acceleration Whiplash - telemetry across 22,000 developers on review time, bugs, and incidents under AI adoption.
- CodeRabbit - State of AI vs Human Code Generation Report (Dec 2025) - issue rates in AI-co-authored versus human-only pull requests.
- TechCrunch - Microsoft CEO says up to 30% of the company's code was written by AI (Apr 2025) - Satya Nadella's LlamaCon comments on AI-generated code share.
- The Hill - Google CEO says more than 25 percent of company's new code written by AI (Oct 2024) - Sundar Pichai's Alphabet Q3 2024 earnings call statement.
- The GitHub Blog - GitHub Copilot app: the agent-native desktop experience (2026) - GitHub's own framing of the Copilot desktop app as an agent orchestration surface.
- Stack Overflow - 2025 Developer Survey - GitHub's standing as the most admired and most desired collaboration tool among developers.
Working through the challenges in this post? I help engineering leaders and CTOs navigate complex technical decisions and scale high-performing teams. Schedule a consultation →
