Git is holding us back

In plain English

Git is the tool most software teams use to save and share versions of their code. Theo says he likes it, but argues it is awkward to use and was designed for a time when only people wrote code.

He points to problems such as messy conflicts when two people change the same part, and awkward chains of changes that depend on each other.

He then covers the Zed editor company, which has raised money to build a new way of tracking work. Their idea is that conversations and edits stay attached to the code, with AI agents included. He says he is excited but has not tested it yet.

Three ideas worth keeping

• Git works well at saving finished work, but it handles in-between states badly, such as a half-resolved conflict or a chain of dependent changes.
• Theo wants finer-grained history, including the steps before a formal save, so you could step back without losing work.
• Zed’s planned approach would keep discussions, including with AI agents, linked to the exact code they are about, instead of scattered across chat tools.

What it means for your business

If your software team complains about their tools, it can be a real cost, not just grumbling. Time lost to managing version history is time not spent on your product. As AI agents start making changes too, the way work is tracked and reviewed will matter more. It is worth asking your team where changes get stuck.

What it means for software teams

Theo says Meta uses a different tool built around stacked changes, and mentions Jujutsu (jj) as a Git-compatible option that records conflicts and handles stacks better. He also criticises GitHub’s review experience. He says he had not used jj much when recording, so treat his comments on it as first impressions.

What we found, and what we did

We measured the friction before changing anything. Over three days, about 60% of our automated test runs were wasted re-runs, and about 70% of the friction came from one cause: agents constantly catching up with newer code (rebasing) and spreading work across many copies of the code.

We moved how our agents write changes to Jujutsu (jj), a tool that works alongside Git, so chains of dependent changes update themselves and the rest of our pipeline didn’t have to change; see Is Jujutsu a Git Superpower for AI Coding?.

We were honest about its limits: jj doesn’t make a change safe to merge, and agents sharing one working copy still lost work until each had its own. We also moved away from long-lived branches for each agent, as explained in To Branch or Not to Branch.

Worth watching

• 04:32: a clip of Casey Muratori complaining how much programmer attention goes into managing version control.
• 10:55: Theo’s example of why merge conflicts are painful in Git.
• 15:49: his picture of the gap between a single edit, a save and a full review request.
• 28:27: Zed’s plan for linking conversations to code.