Scott Chacon cofounded GitHub. He wrote the book on Git. Literally. Pro Git has been the default resource for a decade. If anyone has earned the right to say “this is fine,” it’s him.
He didn’t say that. He left and started building something else.
GitButler raised $17 million to rethink version control from scratch. When the person who built the cathedral starts drawing blueprints for something new, you should probably look at the blueprints.
In a recent interview with a16z, Chacon laid out the problem in terms that made me stop scrolling. GitHub was designed for humans. Specifically, for humans working at human speed. And that assumption is baked into everything.
The Pull Request Was Built for People
Here’s the deal with pull requests. They assume someone will read them.
You open a PR. A teammate gets a notification. Maybe today, maybe tomorrow. They click through, scan the diff, leave a comment or two, approve it, and you merge. The whole cycle takes hours or days. Sometimes weeks if the reviewer is busy or the PR is big enough to trigger “I’ll get to it later” energy.
This works when your team is five humans shipping a few PRs a day. It even works at scale, if the scale is more humans. GitHub handled that part beautifully. Issues, reviews, discussions, profiles, stars. The social layer that made open source collaboration feel natural.
But pull requests were never designed for a teammate that generates 200 of them before lunch.
What Happens at a Thousand PRs Per Week
Stripe merged over a thousand agent-generated pull requests in a single week. Let that number sit for a second.
A thousand PRs. In one week. From AI agents.
Now picture yourself as the human on that team. Your GitHub notification count doesn’t just go up. It becomes meaningless. The PR queue isn’t a todo list anymore. It’s a firehose pointed at your inbox.
Code review breaks first. Be honest: when you do code review, do you really read every line? Chacon asked this same question in the interview and the answer is what everyone already knows. Not always. Not even close. At a thousand PRs per week, “cursory glance” becomes “triage by title.” You’re not reviewing code. You’re reviewing your faith in the system that generated it.
Commit history breaks next. Git log becomes a wall of “fix: update component” and “refactor: apply suggestion” with no narrative thread. The story of how your codebase evolved disappears under a flood of mechanical changes. git blame points to an agent. The context that used to live in commit messages evaporates.
Notifications break last, because they were already broken. But now they’re broken at scale. The signal-to-noise ratio doesn’t degrade gracefully. It collapses.
Chacon put it simply in the interview: the whole model assumes human-speed collaboration. When you introduce participants that work at machine speed, the model doesn’t bend. It shatters.
The Pull Request Is the Wrong Unit
Here’s the question I keep coming back to: what replaces the pull request?
Not “how do we make pull requests better for agents.” That’s the wrong question. That’s like asking how to make horse-drawn carriages faster when someone just showed you an engine.
The pull request is a unit of collaboration designed around a specific workflow. One person makes changes. Another person reviews those changes. They discuss. They merge. It’s turn-based. It’s sequential. It’s fundamentally a conversation between two humans about a diff.
When the “person” making changes is twelve agents working in parallel, and they’re generating changes faster than any human can read them, the conversation model doesn’t apply. You don’t need a better conversation. You need a different unit of work.
Chacon’s answer at GitButler is interesting. They built what he calls a “mega-merge” system where multiple branches coexist in a single working directory. Agents can see what other agents are doing in real time. Conflicts surface before they happen, not after someone tries to merge.
That’s a version control answer. But the platform question is bigger. What does the server-side look like? What does collaboration look like when most of the participants aren’t human?
What the Next Platform Actually Needs
I don’t know what the next GitHub looks like. Nobody does. But I can see the shape of the requirements from here.
Real-time conflict detection, not post-merge. GitHub tells you about conflicts when you try to merge. By then, someone (or some agent) has already done the work. In a world with twelve agents writing code simultaneously, you need to know about conflicts as they form. Not after.
Agent provenance. Which agent wrote this code? What prompt generated it? What was the reasoning chain? Right now, the best you get is a commit message that says “Generated by Claude” or “Co-authored-by: Copilot.” That’s like listing “computer” as the author. You need the full trail: the intent, the context, the decision points.
Review at the intent level, not the diff level. Humans shouldn’t be reading thousand-line diffs generated by agents. They should be reviewing the intent: “I asked the agent to refactor the auth module to use JWT instead of session tokens.” Did it do that? Did it break anything? Let another agent verify the diff. The human reviews the goal.
Trust scores on commits. Not every change carries the same risk. A CSS color change and a database migration are not equal. The platform should know this. Flag the high-risk changes for human review. Let the low-risk ones flow through with automated verification.
Parallel visibility. If three agents are working on the same codebase, each one should know what the others are doing. Not through pull requests after the fact. In real time. This is what GitButler’s mega-merge is trying to solve at the local level, but it needs to exist at the platform level too.
None of this looks like a pull request queue. It looks more like air traffic control. Multiple things moving at once, a human watching the board, stepping in when something looks wrong.
The Builder’s Question
GitHub won because it made one thing simple: collaborating on code with other humans. The entire product was built around that idea. It worked brilliantly for twenty years.
The next platform will win by making a different thing simple: collaborating on code with a mixed team of humans and agents. That’s a different design problem. The social features that made GitHub great (profiles, stars, discussions, PR reviews) were designed for people who have attention spans, opinions, and feelings. Agents have none of those.
Chacon said something in the interview that stuck with me. He said the constraint isn’t “can we produce the code” anymore. It’s “can we agree on what we want.” The bottleneck moved from implementation to communication. From typing to thinking.
If that’s true, the next collaboration platform isn’t optimized for code review. It’s optimized for intent. For specification. For making sure twelve agents and three humans are all building the same thing.
I don’t know who builds it. Maybe GitButler expands into the server side. Maybe someone we haven’t heard of yet starts from scratch. Maybe GitHub pivots faster than Chacon expects.
But I’m pretty sure of one thing. When it arrives, it won’t look like a pull request queue.
It’ll look like something we don’t have a name for yet.