# Is Jujutsu a Git Superpower for AI Coding? — Pilot to Production

> AI agents generate changes faster than Git branches can track. We measured the cost: ~60% of CI wasted on rebase churn. The tooling fix, and its limits.

Canonical: https://thegrowthproject.com/podcast/jujutsu-git-for-ai/

*Pilot to Production*, the Growth Project podcast — hosted by Sam and Maya.

- Listen: https://thegrowthproject.com/podcast/jujutsu-git-for-ai/
- Read the article: https://thegrowthproject.com/blog/jujutsu-git-for-ai/
- Audio: https://thegrowthproject.com/audio/podcast/jujutsu-git-for-ai.m4a?v=aed3717c

## Transcript

**Sam:** We pulled three days of pipeline data on our own coding agents. Sixty percent of our CI runs were burned on rebase churn.

**Maya:** Same tests, same code, re-run for no reason. The change never got better. It just got rebased.

**Sam:** Welcome to Pilot to Production, from the Growth Project. I'm Sam.

**Maya:** And I'm Maya. Today: why your AI pipeline is always busy and never done, and the version control tool that fixes half of it.

**Sam:** Okay. Sixty percent. Tell me that's not a model problem.

**Maya:** It is not a model problem. The agents were fine. The version control was the bottleneck.

**Sam:** Walk me through how that happens.

**Maya:** Git was built for one human. You pick up a task, make a branch, work for hours, open a pull request, wait, merge. Slow on purpose. One stream of work, one thing in flight.

**Sam:** And then you point a fleet of agents at the same repo.

**Maya:** Right. They don't take hours. They finish a change in minutes. Several at once. Changes that depend on each other.

**Sam:** So the branch model just snaps.

**Maya:** It doesn't snap. It degrades quietly. Every time the trunk moves, every in-flight branch is stale. Each one needs a rebase. Each rebase needs a CI run.

**Sam:** And the agents are fast, so the trunk moves constantly.

**Maya:** So everything is always stale, so everything is always rebasing. You don't see one big failure. You see a pipeline that's always running and never finished.

**Sam:** You said sixty percent was rebase churn. Was there a second number?

**Maya:** About seventy percent of the total friction was rebase management plus worktree sprawl.

**Sam:** Define worktree sprawl for me.

**Maya:** A worktree is 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.

**Sam:** Two costs, one root cause.

**Maya:** The tool assumes one slow human. We were running many fast machines.

**Sam:** So where does this Jujutsu thing come in. What is it?

**Maya:** jj. A version control system that sits on top of your 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.

**Sam:** So what actually changes underneath?

**Maya:** Three things. First, descendants rebase themselves. Every change has a stable identity that survives a rebase, so when the trunk moves, the changes built on top follow automatically. The single most repeated manual step in our pipeline stopped being a manual step.

**Sam:** That alone kills the sixty percent.

**Maya:** That alone kills the sixty percent. Second, a stack is one unit. A chain of dependent changes gets tested together and lands together. One test run, one merge, instead of N of each.

**Sam:** That's the part that sounds like a superpower.

**Maya:** It is. The expensive way to do that is a speculative merge queue. A server that optimistically tests changes stacked on each other so they merge as a batch. Real infrastructure, a pain to operate. jj gives you the cheap version of that outcome on the client side, for free.

**Sam:** And the third thing?

**Maya:** One working copy. No worktree per stream. The working copy is itself a change you edit in place. The disk sprawl, the directory graveyard, the reconciliation tax, all of it came from a workaround jj makes unnecessary.

**Sam:** This is the part of the episode where I get suspicious. It sounds too clean.

**Maya:** Good. Here's the honest caveat. jj is a client-side ergonomics win. It changes how change is authored and reconciled on the machine doing the work. It does not fix server-side autonomy.

**Sam:** Meaning what, concretely?

**Maya:** When agents author and land code with minimal humans, the hard problems live on the server. How do you decide a change is safe to merge without a person reading every line? How do you stop an agent approving its own work? How do you keep a tamper-evident record of what merged and why? jj touches none of that.

**Sam:** So it'll happily let a fast agent merge garbage.

**Maya:** It 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.

**Sam:** Two different axes.

**Maya:** Author-side ergonomics, server-side governance. A tool that's excellent on one tells you nothing about the other. The mistake isn't choosing jj. The mistake is thinking the autonomy problem went with it.

**Sam:** Okay. First thing Monday. What does someone actually do?

**Maya:** 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.

**Sam:** Then?

**Maya:** Try jj on one repo, colocated. That just means jj and Git share the same folder and the same history, so you can switch back any time. Run one agent or one engineer on it for a week and watch whether the rebase step disappears from your logs.

**Sam:** And the warning.

**Maya:** Don't touch your merge gate. 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.

**Sam:** Our agents weren't slow.

**Maya:** Our version control was. jj attacks that root, and the numbers move. It will not decide what's safe to merge, and it will not keep an autonomous agent honest. That work is still yours.

**Sam:** This has been Pilot to Production, from the Growth Project. If your agents are shipping faster than your pipeline can keep up, that's the gap we close, at thegrowthproject.com.

**Maya:** Thanks for listening. See you next time.