Git assumes you're a human. It assumes you commit deliberately, resolve conflicts the moment they appear, and work on one thing at a time. Nobody designed these as constraints. They were just obvious in 2005.
They're not obvious anymore. The actor is changing. I've been building FormalTask, which orchestrates parallel Claude Code agents with quality gates you define in YAML. The problems I hit building it are what led me to jj.
Run five AI agents on a codebase at once. Each one makes changes. The changes conflict. In git, a conflict stops everything until someone fixes it, so you need five LLM calls to resolve five conflicts, and the resolutions create new conflicts with agents still running. The coordination costs more than the work itself.
Worktrees help, but only partially. Each agent gets its own copy, but now you have five branches that all touched the same files, and git has no idea how they relate. You're on your own merging them.
Frequent commits should help you roll back failures, but git's commit is three steps — stage, message, execute. An agent doing trial-and-error might need fifty checkpoints a minute. The commit ceremony becomes the bottleneck. Most teams just let agents leave dirty state everywhere and hope nothing crashes.
The common thread is that git was built for how humans work. The assumptions are baked in: conflicts are errors that need immediate human attention. Commits are deliberate pauses. Branches need human-readable names. Undo is rare. One working copy, because one person has one pair of hands. (For now — once BCI lets us explore the nullspace of our motor neurons, we'll have more hands than we know what to do with.)
Agents break all of these. They produce conflicts constantly, need checkpoints every few seconds, don't read branch names, and treat undo as their most common operation. They work in parallel by default.
The right tool would make checkpointing automatic and free — the working state is always a checkpoint, no staging or ceremony required. Conflicts would be data, not errors: when two agents touch the same file, the system records the conflict and keeps going. Every operation would leave a trail in a structured, queryable log — not git's reflog, which tracks branch tips and expires after ninety days. Changes would have stable identity: you can rebase a change, squash it, split it, and it's still the same change, unlike git where rebase gives you a new hash. And everything would be non-interactive — every operation is a function you can call from a script.
It turns out someone built this. Martin von Zweigbergk, an engineer at Google, started Jujutsu (jj) in 2019. He wasn't thinking about agents — he was just trying to make version control less painful for humans. But the decisions he made (kill the staging area, make conflicts first-class, log every operation, give changes stable IDs) happen to be exactly what agents need. The things that annoy git power users are the same things that break when agents use git. Power users can work around them; agents can't.
A few technical points worth noting. Git can't store a conflict as data — conflicts in git are just text markers that exist during a merge, while jj stores them as values in the commit itself. Git can't give a change stable identity — content hashes change on every rewrite, while jj's change IDs don't. Git can't log operations because it has no concept of "operation." These aren't features you can add to git; they require a different data model. But jj stores its data in git under the hood, so you keep your remotes, your CI, and your GitHub.
What gets interesting is what this enables beyond just handling conflicts:
-
Training data from process, not just code. A complete operation log captures how agents navigated the codebase — which sequences of edits, undos, and rebases led to working code. Today we train agents on code. This would let you train them on problem-solving process.
-
Speculative execution. If checkpointing is free and conflicts don't block, agents can try three approaches in parallel and keep the best one. Depth-first search through the solution space becomes breadth-first. Someone should expose jj tools directly to an agent and run SWE-bench. Does it actually branch and explore? Does the score go up? I haven't seen anyone test this yet — if you have, let me know.
-
Conflict batching. Every conflict an agent resolves is an LLM call. Ten agents, five conflicts each, fifty unplanned calls per cycle. When conflicts are data you can batch them — one pass, fifty conflicts, full context. Roughly 10x less in token costs.
-
VCS as coordination protocol. Agents can communicate through the commit graph itself instead of a separate messaging layer. One agent's change is immediately visible as a conflict in another's working copy — no polling, no queue, no orchestrator relaying state.
-
Decision bisection. With every operation logged, you can bisect not just commits but agent decision sequences. When something went wrong, you can trace back through the exact series of edits and undos to find where the reasoning broke.
-
No locks. Git's index.lock means one writer at a time. Jj has no index and no lock — multiple agents can write to the same repo concurrently without blocking each other.
Git isn't going anywhere — jj runs on top of it. But the local workflow was built for a person at a keyboard, and the teams already using jj will be ready when everyone else is still writing wrappers around git.