GitButler After Git: I've Seen This Movie Before.
Here's the thing: when someone tells you they've raised $17 million to build "what comes after Git," my first thought isn't "innovation." It's "technical debt, but with a fresh coat of paint and a VC-funded marketing budget." This is the promise of GitButler after Git, a new venture from GitHub co-founder Scott Chacon. GitButler just pulled in a Series A from a16z, Fly Ventures, and A Capital. Their pitch? Git is 20 years old, it's not built for modern dev, and it's certainly not ready for AI agents. They want to fix the "context loss and chaos" that comes from the "one person, one branch, one terminal, linear flow" model.
I get it. Git can be a pain. We've all been there, wrestling with a rebase that went sideways at 2 AM, or trying to untangle a feature branch that became a monolith. (I've seen PRs this week that don't even compile because the bot hallucinated a library, so the chaos is real). But the problem isn't just the UI; it's the fundamental model. And I'm skeptical that a new layer on top of Git, no matter how shiny, truly changes the game. History is littered with projects that promised to be "what comes after Git" only to become another abstraction layer or fade into obscurity. From Mercurial to Fossil, many have tried to offer alternatives, but none have achieved Git's ubiquity, largely because they failed to address the core distributed consensus challenges or simply offered a different flavor of the same underlying paradigm. GitButler, while well-funded, faces this same uphill battle.
The Illusion of Control: GitButler's Stacked Branches
GitButler's current technical preview, a CLI tool released last week, focuses on improving the developer experience with existing Git projects. They talk about "stacked branches," "multitasking," and "easy undo functionality." This sounds like a better local Git client, which is fine, but it's not "what comes after Git." It's a better interface for Git. The core idea of stacked branches is to break down large changes into smaller, dependent commits, each on its own branch. This isn't new; it's a workflow pattern many teams already use with tools like git rebase -i or specialized CLI extensions. GitButler aims to make this native and easier.
Here's how I imagine a simplified GitButler workflow might look, based on their claims of managing changes and supporting stacked branches:
The "Cool Part" is the promise of better local organization and "context-aware version control." The "Dealbreaker" is that it still relies on Git under the hood. You're still pushing Git branches to a Git remote. The complexity of Git's DAG (Directed Acyclic Graph) doesn't vanish; it's just abstracted away by GitButler's CLI and service. This means you're adding another layer of abstraction, another potential failure mode, between the developer and the actual source of truth. While a smoother local experience is welcome, it doesn't fundamentally alter the challenges of distributed collaboration or the inherent complexities of Git's data model. For more details on their approach, you can visit the official GitButler website.
The AI Agent Problem: More Noise, Not Less
Their vision includes "AI agents fully aware of other agents' and team members' ongoing work." This is where my alarm bells really start ringing. The problem with AI agents in development right now isn't that they lack awareness of other agents; it's that they generate a flood of low-quality, context-poor code. Giving them "awareness" within a version control system sounds like a recipe for a monoculture risk, where a single flawed AI model could propagate bad patterns across an entire codebase, undetected until it's too late. We're already struggling with human-generated technical debt. Adding AI agents that are "aware" but not necessarily competent or accountable to the version control system just expands the blast radius. The causal linkage between an AI agent's "understanding" of a codebase and its ability to produce stable, maintainable code is weak. The model found correlation in training data, not mechanism for solid software engineering. A true solution for AI in version control would involve semantic understanding, formal verification, and perhaps even intent-based merging, rather than simply granting more "awareness" to potentially flawed generative models.
What Truly Comes After Git? Beyond GitButler.
"What comes after Git" isn't a better Git client or a service that wraps Git in a friendlier UI. It's a fundamental rethinking of how we manage code changes, especially in a world with distributed teams, continuous delivery, and increasingly, autonomous agents. That means addressing the underlying data model, the distributed consensus mechanisms, and the trust boundaries. A genuine successor would likely move beyond the file-based, snapshot-oriented model of Git. Imagine a system built on Conflict-free Replicated Data Types (CRDTs) that allow for true concurrent editing without complex merge conflicts, or a content-addressable system that uses stronger cryptographic primitives than SHA-1, ensuring integrity and provenance in a more robust way. Such a system would need to offer semantic versioning at a deeper level, understanding the meaning of code changes rather than just their textual representation.
GitButler's approach feels like a sophisticated patch, not a rewrite. It's a $17 million bet on improving the developer experience within the constraints of Git, rather than breaking free from them. While it might offer a more pleasant local workflow, it doesn't solve the fundamental challenges of distributed version control at scale, nor does it provide a truly novel paradigm for the future of collaborative coding with AI. For now, we're still stuck with Git. And adding another layer of tooling, no matter how well-intentioned, just means another system to debug when things inevitably go wrong. My take? GitButler is building a better frontend for Git. That's a valuable product, sure. But it's not GitButler after Git in the sense of a true replacement. It's just more Git, albeit a more polished version.
