We’re watching Git melt down in front of our eyes as agents write most of our code.
This is why many people, present company especially, are excited about Jujutsu (jj).
Some observations on Git’s history, why it’s creating problems for an agent-first SDLC, and how jj may help:
A brief history of version control systems:
In the early days of computing, version control didn't exist because it didn't need to. Programs were small enough that a single developer could hold one in their head. As teams grew, early systems like RCS tried to solve coordination with file locks that serialized work one person at a time, but locks created as many problems as they solved.
Centralized systems like SVN and Perforce reframed the question entirely, reconciling simultaneous work through merging rather than preventing it. Then Git arrived in 2005, built by Linus Torvalds in a matter of days and described in its first commit as "the information manager from hell."
What it added was decentralization: every developer got a full local copy of the repo, which made branching trivial and gave the whole system a resilience no centralized tool could match. Even so, Git didn't win on technical merit alone; GitHub understood that version control systems are fundamentally collaboration platforms, and that insight, more than anything else, is what made Git the standard.
Why Git is suboptimal for an agent-first world
Git's well documented (and memed) problems fall into two categories: data structures and UX.
At scale, operations like finding merge bases require walking the entire commit history, and Git's reconciliation algorithms max out at roughly 2-3 merges to main per second. That’s fine for startups, but a hard ceiling for hyperscalers.
The UX problems are more universally felt. Git exposes its internal state model to the user, forcing developers to reason about whether a file is untracked, staged, committed, or stashed, when most people just want their work recorded. Merge conflicts are incredibly frustrating because Git treats them as invalid states that must be resolved before you can continue, with no way to set one aside and come back later.
The maintainers know all this, but Git is load-bearing infrastructure with 20 years of backwards-compatibility requirements, and the core team is severely constrained in what they can change.
Agents make all of it exponentially worse, amplifying Git's limitations by generating code at high velocity, turning hyperscaler edge cases into mid-sized-team problems, and the same state machine complexity that frustrates developers becomes reasoning overhead for agents.
Jujutsu (jj) and why people are excited about it
jj started in 2019 as an experiment towards a next-generation VCS by Martin von Zweigbergk at Google. The core difference is that jj eliminates the staging area entirely; every change is always committed, just like Dropbox, and all the little Git incantations are abstracted away.
Several design choices follow naturally. Undo is a primitive: jj maintains an operation log of every action you've taken, so undoing a rebase is one command, whereas Git users have all lost data hunting through the reflog. Conflicts are first-class, represented in the underlying data structures rather than treated as invalid states, which means you can have a conflicted commit, move it around, and come back later without interrupting your work.
And jj builds its own data structures on top of a storage backend, which today is Git, so you could start using it at work without anyone knowing.
For those nodding along, check out
@erscio. ERSC was started by JJ’s core committers and they’re building the version control system and forge that will take software development into the next 20 years, for humans and agents.