The Growth Project
Is Jujutsu a Git Superpower for AI Coding?
We pulled three days of pipeline data on our own coding agents.
About 60% of our CI runs were burned on rebase churn. About 70% of the friction we counted was rebase wrangling plus worktree sprawl.
Not a model problem. A version control problem.
The Mismatch Nobody Priced In
Git was designed for humans. A human picks up a task, makes a branch, works for a few hours or a few days, opens a pull request, waits for review, merges.
The cadence is slow on purpose. One person, one stream of work, one thing in flight.
Now point a fleet of coding agents at the same repo. They don’t take a few hours. They produce a finished change in minutes. They produce several at once. They produce changes that depend on each other.
The branch model doesn’t break loudly. It degrades quietly.
Every time the trunk moves, every in-flight branch is now stale. Each one needs a rebase. Each rebase needs a CI run. The agents are fast, so the trunk moves often, so everything is always stale, so everything is always rebasing.
You don’t notice it as a single failure. You notice it as a pipeline that’s always busy and never done.
What We Measured
We didn’t theorise this. We instrumented it.
Three days of agent activity, every CI run, every rebase, every branch and worktree created. Then we sorted the wasted time into buckets.
About 60% of CI runs were rebase churn. Re-running the same tests on the same code because the base had moved underneath it. The change didn’t get better. It just got rebased.
About 70% of the total friction was rebase management plus worktree sprawl. Worktrees are the trick people reach for to run agents in parallel: a separate working directory per stream. Run enough agents and you get sprawl, disk filling up, a mess to reconcile.
Two costs, one root cause. The tool assumes one slow human. We were running many fast machines.
| Git Assumes | AI Agents Do |
|---|---|
| One stream of work | Many parallel streams |
| Hours per change | Minutes per change |
| Independent branches | Stacks of dependent changes |
| Manual rebase, when ready | Constant rebase, trunk always moving |
| One working copy is enough | A worktree per agent, then sprawl |
Where Jujutsu Comes In
Jujutsu, or jj, is a version control system that sits on top of a Git repository. Same data, same remotes, same git push. Your hosting doesn’t change. Your teammates on plain Git don’t even have to know.
What changes is the model underneath. Three differences matter for this problem.
Descendants rebase themselves. In jj, every change has a stable identity that survives a rebase. When the trunk moves, the changes built on top of it follow automatically. You don’t run a rebase command per branch. The graph keeps itself consistent. The single most repeated manual step in our pipeline stopped being a manual step.
A stack is one unit. jj treats stacking, a chain of dependent changes, as a first-class thing, not a sequence of branches you babysit. So N dependent changes can be tested together and land together: one test run, one merge, instead of N of each.
That last point is the one that earns the word superpower. The expensive way to make many dependent changes land safely is to build a speculative merge queue, a server that optimistically tests changes stacked on each other so they can merge as a batch. It’s real infrastructure and it’s a pain to operate. jj’s stacking gives you the cheap version of the same outcome on the client side, for free.
One working copy. There’s no staging area in jj, and no need for a worktree per stream. The working copy is itself a change you edit in place. The disk sprawl we measured, the directory graveyard, the reconciliation tax, all of it came from a workaround jj makes unnecessary.
Auto-rebase kills the 60%. Stacking and the single working copy kill most of the 70%.
The Honest Caveat
Here’s where most “switch to this tool” posts stop. They shouldn’t.
jj is a client-side ergonomics win. It changes how change is authored and reconciled on the machine doing the work. That’s exactly the axis our friction lived on, which is why the numbers move.
It does not fix server-side autonomy.
When you run agents that author and land code with minimal human involvement, the hard problems are on the server. How do you decide a change is safe to merge without a person reading every line? (That’s a measurement problem in its own right, and green tests don’t answer it.) How do you stop an agent approving its own work? How do you keep a tamper-evident record of what merged and why? How does the queue stay correct when changes are landing faster than tests complete?
None of that is a jj problem. jj will make your agents author changes more smoothly and still let them merge garbage if your gate is weak. A smoother pen doesn’t make the writing true. We learned this the slow way, and it’s the same lesson as vibe coding versus vibe engineering: the tool that produces output faster is not the tool that makes the output trustworthy.
Two different axes. Author-side ergonomics, server-side governance. A tool that’s excellent on one tells you nothing about the other.
| Author-Side (jj helps) | Server-Side (jj doesn’t touch) |
|---|---|
| Rebasing dependent changes | Deciding what’s safe to merge |
| Worktree and disk sprawl | Stopping self-approval |
| Stacking changes cleanly | Tamper-evident merge history |
| Local reconciliation cost | Queue correctness under load |
Be ruthless about which one you’re buying. The mistake isn’t choosing jj. The mistake is thinking the autonomy problem went with it.
First Thing Tomorrow
You don’t need a migration plan. jj rides on the Git repo you already have.
- Measure your churn first. Before you change anything, count it. How many of your CI runs are re-running tests on code that only changed because its base moved? If you can’t put a number on it, you can’t tell if a tool helped.
- Separate author-side from server-side. List your version-control pain. Sort each item into “happens on a developer or agent machine” versus “happens at the merge gate.” jj only addresses the first column.
- Try jj on one repo, colocated. Colocated just means jj and Git live in the same folder and share the same history, so you can switch back at any time. It coexists with Git. Run one agent or one engineer on it for a week. Watch whether the rebase step disappears from your logs.
- Test the stack, not the change. If your agents produce dependent changes, set CI to validate the whole stack as a unit and merge it atomically. That’s the speculative-queue benefit without the speculative queue.
- Don’t touch your merge gate yet. Whatever decides a change is safe to land stays exactly as strong as it was. A better authoring tool is not a licence to loosen the gate.
The Bottom Line
Our agents weren’t slow. Our version control was.
Git was built for one human moving at human speed. We were running a fleet of machines moving at machine speed, and the branch-and-rebase model spent most of its time re-doing work the agents had already finished.
jj attacks that root. Auto-rebasing descendants, stacks that test and merge as one, a single working copy. On the author-side axis, it’s a genuine superpower, and the numbers move.
It is not magic. It will not decide what’s safe to merge, and it will not keep an autonomous agent honest. That work is still yours.
Pick tools by the axis they solve. Then solve the other axis on purpose.
Running AI agents faster than your pipeline can keep up? We build the systems that let machines ship safely, not just quickly. Let’s talk.