Git Wasn't Built For This
By optimizing for a world that's fading you miss building for one emerging
Two weeks ago while sitting at the airport en route to San Francisco I stoked a mild controversy with a post on LinkedIn challenging the present state of software versioning in light of current SOTA agent codegen.
It’s essence: current version control systems were designed for humans writing thoughtful commits. Not AI agents writing code in minutes based on declarative specification changes. So might we be due for a replacement? Or a complement?
In retrospect a hook using the words "git is no good…" rightly asked for criticism. I concede. Its not about trying to “throw out” the time and battle tested git.
But many outright dismissed the notion that our tools need to evolve.
That's OK. I've been here before and I suspect you have too.
Often Critics Don't Get It, and That's OK
Some insisted that "feature complete commits are an anti-pattern" and the core of many pains I described weren’t about tools but rather workflow: just use trunk-based development.
They’re absolutely right. For the world we’ve known.
But the world of software development will soon not look like what we’ve known for the past 20 years.
This July study on the AI Productivity Paradox from my friend Vitaly who runs Faros AI validates much of what I’ve heard firsthand and the pains that catalyzed my post in the first place:
While AI codegen tools accelerate individual developer output by 21% they also increase length of time to merge by 91% creating severe bottlenecks in collaborative workflows (no not for the enlightened using trunk based flows).
The average PR size is ballooning by 154%. Meaning its becoming easier and more tempting to generate code and putting huge pressure on those who must review it and,
Despite all the individual speed there has been no measurable improvement in organizational-level DORA metrics.
This is Amdahl's Law playing out in real time. We’re throwing more “processing power” at problems, the bottleneck shifted and complexity is just getting sloshed around, not compressed.
When someone sarcastically suggested using "a blockchain to coordinate all these agents" and "ape-themed gif" identifiers I admit, I laughed.
Dismissive humor is a defense mechanism that’s easy to recognize and goes hand in hand with every paradigm shift I've witnessed during my short time on earth. Have you been following Gary Marcus?
But in this particular topic’s neck of the woods struggles from yesteryear are also well documented. A tiny sampling:
Simon Tatham's 2004 is a standout recounting the difficulty in migrating PuTTY from CVS to Subversion. It required custom Python scripts and months of manual intervention. But in the end, hey “not so bad”?
Years later, resistance emerged when teams moved from Subversion to Git: old Eclipse Community surveys show it took until 2014 for Git (originally released in 2005) to surpass SVN adoption.
History of course rhymes.
Tools Should Adapt to Our Workflows
My take is that we’re trying to force agent first development into Git because there's no better alternative yet. Heck even Anthropic has an article about using Git Worktrees to parallelize agents. From experience it leaves much to be desired.
One commenter noted they "only read and write specs now" and that "the AI acts as a mere spec compiler". That person is describing the future that's already here and not fully distributed.
This is contrasted by another who said "the answer is not more new tech, its changing the way you work."
Well sure some get this. Folks from GitHub recently released Spec Kit treating specifications as artifacts with a four-phase approach: Specify → Plan → Tasks → Implement. That flow is something I’ve written about at some length before here.
Finally a commenter rhetorically asked, "If we really gained 20 - 100x productivity and agents are truly autonomous as claimed, why isn't this solved?"
Keep in mind how fast things pass by and are gone—those that are now, and those to come. Existence flows past us like a river: the “what” is in constant flux, the “why” has a thousand variations. Nothing is stable, not even what’s right here. The infinity of past and future gapes before us—a chasm whose depths we cannot see. — V. 23
Simply put present tools are hindering the workflows that are rapidly becoming natural to us. They consume rather than reduce cognitive load. And these tools need to disappear into the background.
They should not force you to think in their paradigm but rather adapt to yours.
Forcing square pegs into round holes is certainly part to blame for why we’ve haven’t gained much of the elusive productivity. No, this isn’t just about more tech.
Git was revolutionary at the time because it understood how developers actually wanted to work: with cheap branching and local-first distributed development. It works become we reconcile intent in the code. At the line level.
Now we need tools that understand how we work and will work with AI agents:
Through conversation, specification and rapid iteration.
That may or may not continue to be local first.
That will require a different mental model than “version a changeset”.
Philosophically its core contrast looks something like this:
So yeah, some of the critics don't get it because it doesn’t quite exist yet and that's OK.
But in continuing to optimize for a world that's fading you miss building for one that's emerging.
And history shows these transitions take time.
I'll see you on the other side.