git — jd:/dev/blog

Merge Queues Were Built for Humans. Agents Don't Wait.

Tue, 30 Jun 2026 00:00:00 GMT

Mitchell Hashimoto thinks merge queues stop working once you point a swarm of AI agents at your repository. I sell merge queues for a living. He's half right, and the dishonest move would be to pretend he isn't.

He said it on the Pragmatic Engineer podcast, in a stretch about Git and monorepos. The setup is a line I've been repeating for years: hitting the merge button is the easiest step. Everything expensive happens around the merge, not at it. Getting the code reviewed, keeping main coherent, maintaining forever what you just shipped. Undergraduates can hit the button, as he puts it. The rest is the job.

Then he gets to the queue:

You constantly rebase. Merge queues solves that to a certain extent. I think merge queues works for humans at a certain scale, but merge queues could get quite deep. But then if you sort of 10x that, conservatively, I think 10x that, and then if you buy into hype cycles and you 100 or 1,000x that, I think it gets completely untenable.

(That's the transcript, grammar and all.)

He's right about the naive version. A merge queue that exists to serialize rebases (take one PR, rebase it on main, run CI, merge, repeat) was built around human throughput. Humans open a few pull requests a day. The queue could be deep and still drain by lunch. Multiply the inflow by ten, then by a hundred, and a queue that only knows how to go one at a time becomes the exact bottleneck it was supposed to remove.

So yes. The human-scale queue strains under agent churn. Grant it and move on, because the interesting part is what you conclude from there.

What actually breaks

Hashimoto lists "a confluence of problems": the merge queue, disk space, and branching/review. I'd pull them apart. Disk space is real (Git clones the world) and it's a separate fight. The one I care about is the queue, and the thing that breaks there isn't the queue. It's the loop the queue sits inside.

He names the failure mode exactly:

Every time you pull, you can't push, because every time you pull there's another chain. Every time you push it's rejected.

The host adds the obvious: there's a lot of parallel work happening at once.

That's not a queue failing. That's contention. Between the moment you decide to integrate a change and the moment main accepts it, the tree moved underneath you. With humans the window was minutes and the traffic was light, so a serial queue could absorb it. With agents the window is unchanged but the traffic isn't, and the one place every change has to pass through, main, is saturated. (The 100x and 1,000x numbers are his hype-cycle hypotheticals, not measurements. The direction is the point.)

People look at that and conclude the chokepoint is the problem, so rip it out. I'd argue the opposite. Serialization is a throughput constraint, not a law of physics, and the chokepoint is the only place left where you still get to decide what "main" means under that load. You don't beat contention by deleting your one point of coordination. You beat it by making that point fast, cheap, and parallel. What actually broke is everything that assumed the loop around it was cheap: one PR, one CI run, one human looking at it, merge, move on. Your CI pipeline was never sized for that.

A queue that goes one at a time is the toy version

Talking about a stealth company he advises, Hashimoto names the real shape:

The amount of churn that these agents is causing is so much greater than humans. And it's not an AI review problem. It's really just like a release problem, like managing the merge queues, humans getting access to the right set of data in the repository.

A release problem. That's exactly it, and release engineering already has answers for "serial doesn't scale." We've just never had to point them at ordinary feature work, because ordinary feature work never moved this fast.

A queue that takes PRs one at a time and rebases each on the last is the toy. The version that survives agent load does what every high-throughput build system already does:

It speculates. Don't wait for #1 to land before testing #2. Build the optimistic chain and test #1+#2+#3 in parallel as if they'll all pass, falling back only when one doesn't. Zuul has done this for OpenStack for over a decade; GitHub's own merge queue and Bors do a version of it.
It batches. Merge a run of green PRs as one unit and run CI once for the batch instead of once per PR.
It bisects on failure. When a batch goes red you don't drop all of it. You find the offender and let the rest through. Uber's SubmitQueue and Google's TAP are built around exactly this.
It treats CI cost and latency as the real constraint. Under agent load the binding limit isn't "can the queue order things." It's whether you can afford to run the suite hundreds of times a day, and how fast each run comes back. Speculation and batching pull against that directly: optimistic chains multiply CI spend, and a failure high in the chain throws away everything below it. Flaky tests, which explode under agent churn, wreck the bisection you were counting on. This is the unglamorous core of it, and it has no clever Git answer.

Here's the honest tension, and the thing Hashimoto's stealth company is really selling against. These techniques are known. Running them without Google's build infrastructure and Google's CI budget is not. That gap is the actual frontier, and it's why the problem lands on tooling rather than on a team of five wiring up speculative pipelines by hand. (Disclosure, if it wasn't obvious: I run Mergify, which builds this kind of thing. Discount me accordingly.)

What the queue does not fix

I'm not going to pretend the queue solves all of it. Green is not coherent. Ten agent PRs can each pass CI alone, pass again as a batch, and still be a mess together: three flavors of the same helper, two designs pulling in opposite directions, a thousand lines no human read. A merge queue keeps main buildable. It does not keep main good. That half of Hashimoto's worry survives untouched, and it isn't a release problem, it's a review problem, and review is exactly the thing agents have made scarcest.

There's also a future where I lose this bet outright. If someone ships an optimistic, eventually-coherent model of main with no single serialization point to defend, the queue as we know it goes with it. I don't think that's where this lands. I think the forge itself bends first.

The most interesting release problem in fifteen years

The line that stuck with me wasn't about queues at all. Asked whether Git survives the agent era, Hashimoto said this is the first time in twelve to fifteen years anyone asks the question without laughing.

That's the signal. The primitives we treated as settled (Git, branches, the pull request, the merge queue) are load-bearing again, and some of them will bend. The merge queue is the one I'd bet on. Not because I sell it, but because the job it does, keeping a shared main coherent while many actors race to change it, gets harder under agents, not easier. You answer more contention by making coordination faster, not by deleting it.

Hitting the merge button is still the easiest step. Agents just turned everything around it into the most interesting problem on the board.

Twenty Years of Stacking Commits

Tue, 28 Apr 2026 00:00:00 GMT

In twenty years, I've used four different code review tools. Each was supposed to fix the previous one. None of them changed the fundamental question they were trying to answer: what is the right unit to review?

The answer hasn't moved. The world around it has.

I started on git format-patch and git send-email in 2006, threading patches into mailing lists the way the Linux kernel did. I moved to Gerrit at OpenStack when it arrived. I tried to bring its workflow to GitHub myself, and failed. I watched GitHub turn every branch into a wall. And now I'm watching agents push code faster than humans can read it. Each era taught me the same thing: the unit of review is the commit. We just spent a decade pretending otherwise.

[PATCH 2/5] from a patch series I sent to the XCB mailing list in 2010. Each patch was its own review unit. Stacking has been here the whole time.

Gerrit got it right

OpenStack ran on Gerrit. Google had built it in 2008 for Android, the brainchild of Shawn Pearce as a fork of Guido van Rossum's Rietveld. Projects looking for serious code review followed.

Every commit you pushed got a Change-Id, a SHA-like footer Gerrit used to track that commit across rebases. One Change-Id was one review. Push six commits, get six review threads. Amend one and the others stayed untouched. Reviewers commented on the commit they cared about and ignored the rest.

The UX was hostile. You pushed code with git push HEAD:refs/for/master, a syntax that felt designed to keep newcomers out. Discussions happened in a web UI that loaded slowly even on fiber, or over a JSON-over-SSH API for the brave. You clicked through three screens to leave a comment. Senior contributors had Vim macros to make it bearable. Newcomers gave up.

But the model underneath was right. Each commit was a thought, and each thought got reviewed on its own terms. When you submitted a five-commit feature, reviewers could approve the refactoring commits while still arguing about the new abstraction in the last one. The work moved forward in pieces. Nobody waited for everything to be perfect before anything could land.

Compare this to what most teams do now. A reviewer opens a 1,500-line PR, scrolls for a while, picks a few things to comment on, and either approves or sends it back as a single block. There's no granularity because the unit doesn't allow it.

Gerrit knew this in 2008. It just didn't know how to make people enjoy it.

git-review proved the UX was the wall

OpenStack built git-review to wrap Gerrit's six-step push ritual in one command. git review did the right things in the right order. Fetch the latest target branch, rebase your commits on top, validate Change-Ids were present, push to the magic ref, print the URLs of the resulting reviews. That was it.

It got adopted across OpenStack within months. Within a year it was the default step in every contributor tutorial. Not because the tool was clever (it wasn't), but because the friction it removed was the difference between people contributing and people giving up after their first push.

That was the lesson I carried out of OpenStack. A tool can have the right semantics and still lose if the UX is hostile. UX isn't decoration. It's part of correctness. The model that wins is the one a tired developer at 6pm can use without thinking. Gerrit's model was right, but its surface area pushed everyone toward GitHub the moment GitHub got good enough.

GitHub turned every branch into a wall

GitHub got good enough around 2014. Faster UI, easier setup, and a model anyone could understand: one branch, one pull request. That model worked for solo contributions and small features. It collapsed the moment you tried to ship anything in pieces.

The problem is structural. GitHub's PR is anchored to a branch. If you want five reviewable units, you need five branches. Each one rebased on the previous. Each one's PR retargeted when the one below it lands. If the bottom of the stack changes, you rebase the world. Nobody does this. People give up and ship one giant PR instead, or they ship one PR per day for a week and pretend it's fine.

I ranted about exactly this in 2013, back when most of the industry was busy convincing itself GitHub had solved code review. The argument hasn't aged. GitHub's PR model fights you the moment you try to ship more than one thought at a time.

I tried to fix it myself in 2016 with git-pull-request, a small Python CLI that turned commits on a single branch into chained GitHub PRs. It worked for me. It didn't go anywhere. A one-person CLI can't paper over a structural mismatch. The branching, the chaining, the dependency tracking, the smart updates when you amend a commit mid-stack, all of that has to live somewhere both halves of the workflow agree on. Client-side scripts work on your machine and break on someone else's.

Years later we built Mergify Stack because the problem hadn't gone away and the team was bigger than just me. One local branch, every commit becomes its own PR, the tool handles the chaining so amending mid-stack only updates the affected reviews.

A nine-PR stack from our ongoing Rust port, posted as a comment on every PR in the chain. Each row is one commit, one PR, one review unit. The arrow points at the PR you're currently looking at.

We weren't the only ones who noticed the gap. Graphite bet a whole company on it, building an IDE around stacked diffs that effectively replaces GitHub's review surface. Meta open-sourced Sapling's ghstack. Google open-sourced jj, a Git-compatible VCS where stacks are first-class. There's spr, stack-pr, half a dozen others. Different shapes, same admission: GitHub's PR model doesn't fit how serious teams ship.

My day-to-day hasn't really changed since I was patching Xorg, or awesome, or filing bugs against Debian packages I maintained. One branch. Commit small. Interactive rebase to fix something three commits down. mergify stack push to send the whole stack up. The only difference is GitHub showing seven separate review threads instead of a mailing list showing six.

This was the missing layer. Stack semantics, GitHub surface. For a while, that was enough.

And then the agents arrived

Until last year, the bottleneck on a software team was the human writing the code. A senior engineer could ship maybe two or three thoughtful PRs in a day. Junior engineers shipped less. Reviewers mostly kept up. The whole pipeline was sized for human output.

That bottleneck is gone. With Claude Code in front of me, I can produce in an afternoon what used to take a week. Not because I'm typing faster. Because I'm not typing at all. I'm planning, briefing, reviewing, redirecting. The agents do the typing. They don't get tired.

I've written about how this shifts the bottleneck downstream. The reviewer is now the choke point, and the reviewer's tools haven't kept up. They're still being asked to read 1,500-line PRs the way they did when those PRs took someone a week to write. They skim. They miss things. They approve and hope.

Stacks don't shrink the work. They make partial progress possible. A reviewer who can't approve all of it can still approve half of it. Two reviewers can split the stack and work in parallel. A bug found in PR five doesn't roll back PR one. The total volume is unchanged. The blast radius and the cognitive load per review are not.

A couple of weeks ago I shipped an API surface refactor across our backend and frontend. I had a plan with seven steps: add a new /merge-queue/branches endpoint, remove a deprecated old one, migrate the web app's branch selector, drop a dead related surface, add a sister /stats/branches endpoint, migrate the stats filter, deprecate the old union endpoint. I briefed the agents. I reviewed the work. Six seconds after I ran mergify stack push, GitHub had seven open pull requests linked in dependency order.

Combined, those PRs touched roughly seven thousand lines across seventy-five file changes. As a single PR, no human would have read it carefully. As a stack, each one was a single logical move. The first landed two days later, when the lowest-risk piece (deleting the deprecated endpoint) was approved. One contested API addition cycled through a couple of rounds of dismissed reviews before landing. The last merged nine days after the push. Five different reviewers touched the stack across that window, picking up whichever links they had context for. Nobody had to load the whole refactor into their head.

Try that as one PR and tell me what happens. Seven thousand lines mixing four backend moves with two frontend migrations. A reviewer who needs to understand all of it before approving any of it. Anything wrong anywhere triggers a full revert. The work either ships as a brick or it doesn't ship at all.

Stacks aren't free and they aren't universal. Exploratory work that changes shape mid-stream wants a single branch, not seven. Tightly coupled changes where commit five only makes sense once you've read commit four don't decompose neatly. Bug fixes are usually one PR. The skill is knowing which kind of work you're doing before you start. If your team can't write atomic commits or doesn't trust interactive rebase, stacks make things worse, not better. The model demands discipline. The bet is that AI removes enough of the writing tax that the discipline becomes affordable.

Gerrit knew this in 2008. The unit of review is the commit. The PR was always a workaround for tooling that couldn't track commits properly. It took agents writing code faster than humans can read it for the rest of the industry to admit it.

In January, GitHub stopped denying it. They announced native Stacked PRs in private preview, with the gh stack CLI and an AI agent integration shipped as a skill.

GitHub's own stack-navigator preview from the gh-stack landing page. The PR map on the right is what reviewers have been asking for since 2014.

The PR model GitHub spent a decade enforcing as the right unit of review is being quietly retrofitted to admit it wasn't. They couldn't say so until everyone else had already built the layer they should have shipped in 2014.

The tools change every five years. Gerrit. git-review. Mergify Stack. Graphite. GitHub Stacked PRs. Whatever ships next. Each generation looks like a step forward and most of them are.

The unit of review hasn't moved in twenty years. It's the commit. It always was. We just had to wait for the rest of the pipeline to break before we noticed.

How Entire Works Under the Hood

Thu, 12 Feb 2026 00:00:00 GMT

In part 1, I covered why Entire raised $60M and what problem they're solving. Now let's look at the actual code.

I pointed Claude Code at Entire's open source CLI and asked it to explain how things work. The architecture is more interesting than I expected — they've essentially built a session-aware metadata layer on top of git using nothing but git's own primitives.

The Big Picture

Entire hooks into two things: your AI agent (Claude Code, Gemini CLI) and git itself. The agent hooks capture what's happening during a session. The git hooks capture what the developer commits.

Agent hooks (Claude Code)         Git hooks
  SessionStart                     prepare-commit-msg
  UserPromptSubmit                 post-commit
  Stop                             pre-push
  PreToolUse / PostToolUse
         │                              │
         └──────────┬───────────────────┘
                    │
            ┌───────▼────────┐
            │   Strategy     │
            │                │
            │ SaveChanges()  │
            │ Rewind()       │
            │ Condense()     │
            └───────┬────────┘
                    │
         ┌──────────┴──────────┐
         │                     │
    Shadow branches      Metadata branch
    (local, temp)        (shared, permanent)
    entire/<hash>        entire/checkpoints/v1

How Agent Hooks Get Installed

Running entire enable writes hook entries into .claude/settings.json. Seven hooks, covering the full session lifecycle:

SessionStart/SessionEnd — track session boundaries
UserPromptSubmit — fires before the agent starts working (captures human edits)
Stop — fires after the agent finishes a turn (triggers checkpoint save)
PreToolUse/PostToolUse[Task] — track subagent spawning
PostToolUse[TodoWrite] — capture task state

Each hook is just a shell command: entire hooks claude-code stop. The CLI parses the agent's transcript to extract everything it needs.

The Transcript Is the Source of Truth

This is the key insight. When the Stop hook fires, Claude Code passes two things via stdin: a session_id and a transcript_path. That transcript — the JSONL file where Claude logs every message, tool call, and response — is the single source of truth.

The CLI mines it for:

Modified files — scans for tool_use blocks where the tool is Write, Edit, etc., and extracts the file_path
User prompts — finds type: "user" entries
Token usage — sums input_tokens, output_tokens from response metadata
Summary — grabs the last assistant message

No magic, no APIs. It just reads the same JSONL file that Claude Code writes to disk.

Shadow Branches: Snapshots Without Commits

Here's where it gets clever. When the agent finishes a turn, Entire needs to save a snapshot of the working tree. But it can't commit to your branch — that would mess up your history.

So it creates shadow branches: refs like entire/2b4c177-a5e3f2 that live in your local repo but never touch your working branch.

The name encodes two things:

2b4c177 — first 7 chars of HEAD when the session started
a5e3f2 — hash of the worktree ID (to support git worktree)

The snapshot is built entirely in memory using go-git's plumbing APIs:

Take HEAD's tree (the full repo structure)
Apply the agent's changes (add/remove/modify blobs)
Attach the metadata directory (.entire/metadata/<session-id>/)
Create a commit on the shadow branch

No checkout, no stash, no visible side effects. The user and agent don't even know it happened.

Deduplication is automatic: if the tree hash matches the previous checkpoint, it skips the commit. Git's content-addressable storage means identical files share blobs across checkpoints.

The Condensation Model

Shadow branches are local scratch space. The real metadata lives on entire/checkpoints/v1 — an orphan branch (no common ancestor with your code) that's pushed alongside your regular branches.

The flow:

Agent works → checkpoints saved on shadow branch (local)
You commit → post-commit hook fires
prepare-commit-msg adds a trailer: Entire-Checkpoint: a3b2c4d5e6f7
Shadow branch data gets condensed — copied into the metadata branch
Shadow branch gets cleaned up

The checkpoint ID (a3b2c4d5e6f7) is 6 random bytes, not a git SHA. It's sharded into a directory path on the metadata branch:

entire/checkpoints/v1  (orphan branch)
└── a3/b2c4d5e6f7/
    ├── metadata.json          # summary, attribution, token usage
    ├── 0/
    │   ├── full.jsonl         # complete session transcript
    │   ├── prompt.txt         # user prompts
    │   └── context.md         # generated context
    └── 1/                     # additional sessions if any

That one-line trailer in your commit — Entire-Checkpoint: a3b2c4d5e6f7 — is the bidirectional link. From the commit you find metadata via the sharded path. From the metadata you find the commit by searching for the trailer.

Attribution: Who Wrote What?

This is the piece that matters for engineering leads. Entire tracks line-level code attribution: what percentage was agent-written vs. human-written.

The trick is the UserPromptSubmit hook. Every time you type a new prompt — before the agent starts working — the CLI snapshots the worktree diff against the last checkpoint. This captures exactly what you changed between agent turns.

By commit time, it has:

Agent lines: changes from the last checkpoint's tree
Human added: lines you added between prompts
Human modified: lines you edited in agent-written code
Agent percentage: the ratio

The result is stored in initial_attribution in the metadata:

{
  "agent_lines": 150,
  "human_added": 25,
  "human_modified": 10,
  "agent_percentage": 85.7
}

It even uses a LIFO heuristic for self-modifications — if you add lines then remove lines from the same file, it assumes you're removing your own first, not penalizing the agent's contribution.

Multi-Developer: Conflict-Free by Design

The metadata branch gets pushed during git push (via the pre-push hook). Multiple developers push to the same entire/checkpoints/v1 branch.

This works because checkpoint IDs are random — two developers will essentially never produce the same 12-hex-char ID. Merging is just a tree union: flatten both trees, combine entries, done. No merge conflicts possible.

If a normal push fails (non-fast-forward), the CLI fetches the remote, merges trees, creates a merge commit, and retries.

What's Missing

The architecture is solid engineering, but a few things stood out:

Transcript privacy. Session transcripts (full agent conversations) get pushed to a branch anyone with repo access can read. For private repos, maybe fine. For orgs with varying access levels — that's a problem.

Squash merges break links. If a PR with 5 commits (each with Entire-Checkpoint trailers) gets squash-merged, those trailers disappear. The metadata exists but the bidirectional link from the merged commit is broken.

The metadata branch grows forever. Every session from every developer, including abandoned PRs and throwaway experiments, accumulates on entire/checkpoints/v1. There's an entire clean command for local shadow branches, but no retention policy for the permanent metadata. For a large team over months, that'll bloat.

No PR linkage. The branch name is stored, but there's no PR number or URL. You can't easily ask "show me all sessions related to PR #42."

The Smart Parts

What I genuinely admire:

Git as a free database. Shadow branches store full repo snapshots, but git's content-addressable storage means only changed blobs cost anything. You get atomic snapshots, deduplication, and transport for free.

In-memory tree building. Checkpoints are created through go-git plumbing APIs — no worktree checkout, no stash, nothing visible. Zero disruption to the developer's flow.

Attribution at prompt boundaries. Capturing human edits before the agent contaminates the worktree is the cleanest measurement point possible.

Shadow branch migration. If you rebase or pull (HEAD changes), the shadow branch name automatically updates. Your session continues seamlessly. This handles a common workflow that would otherwise silently break.

So What?

Entire doesn't solve a burning problem today. Most of us are fine with agent-written code landing in our repos without detailed provenance. But the trajectory is clear: as agents write more code, the audit trail becomes essential.

The approach of storing session context alongside code in git — rather than in a separate system — is the right architectural bet. Git is already where your code lives, where your CI runs, where your reviews happen. Adding a metadata layer inside git itself (instead of a SaaS dashboard somewhere) means the context travels with the code.

Whether Entire is the company that turns this into a platform worth $300M is above my pay grade. But the engineering is genuine, the problem is real, and the timing feels right.

I'll be watching.

Agent-Written Code Needs More Than Git

Wed, 11 Feb 2026 00:00:00 GMT

The former GitHub CEO just raised $60M at a $300M valuation for a seed round. For a CLI tool. Let that sink in.

Thomas Dohmke left GitHub and launched Entire, a developer platform built from scratch for the age of AI coding agents. It's the largest seed round in dev tools history.

My first reaction was "that's insane." My second reaction was "wait, I've been solving the same problem with duct tape and hooks."

The Problem Is Real

If you're using AI agents like Claude Code or Gemini CLI daily — and I am — you've already felt it. Git was built for humans writing code. It assumes you know what you changed and why. It assumes your commit messages mean something. It assumes the person who wrote the code will remember what they were thinking.

AI agents break all of that.

When Claude Code rewrites a module for me, the commit message says what happened, but not why. There's no trace of the conversation that led there. No record of the three approaches the agent considered and rejected. No way to know if the prompt was "refactor this for clarity" or "make this 10x faster and I don't care about readability."

The transcript — the actual reasoning behind the code — lives in a terminal session that vanishes when you close the tab.

My Duct Tape Solution

I ran into this a few weeks ago when I wanted to resume a Claude Code session after a reboot. The session was gone, and I had no idea what context the agent had when it made certain decisions.

So I did what any engineer would do: I wrote a hook. A simple Claude Code hook that links each commit to its session ID via a git trailer. Nothing fancy — just enough that I can trace a commit back to the conversation that produced it.

Combined with Mergify's CLI for stacking PRs, it made my workflow usable. But it's duct tape. It doesn't capture the transcript, doesn't track attribution, doesn't handle multi-session work.

Which is exactly the gap Entire is going after.

What Entire Actually Claims to Be

Beyond the buzzwords in the press release, Entire is shipping three things:

Checkpoints — an open source CLI that captures session context (prompts, transcripts, reasoning) alongside every commit, stored in git without polluting your history
A semantic reasoning layer — meant to let multiple AI agents collaborate on the same codebase with shared context
An AI-native UI — designed for agent-to-human collaboration rather than human-to-human

They're not claiming to have a finished product — and they're upfront about it. The Checkpoints CLI is the first concrete thing they've shipped, and it's open source. The rest is where the $60M goes. Fair enough — let's look at what actually exists.

Why $60M for This?

The bet isn't that the current CLI is worth $300M. The bet is that the developer tooling stack needs to be rebuilt for a world where most code is written by agents, and the first company to nail the foundation wins.

Think about it: if 99% of code is agent-written in two years (which is where things are heading), then the code review, debugging, and understanding workflow we have today is fundamentally broken. You can't review AI-written code the same way you review human-written code. You need the context — what was the agent trying to do, what constraints did it have, what alternatives did it consider.

That's a platform opportunity, and $60M is the price of a credible attempt at it. Whether Entire is the one to build it is a different question — but the problem is real and urgent.

My Take

Dohmke knows exactly where GitHub's limits are (he ran it). The investor list — Felicis, Madrona, Olivier Pomel — signals real conviction. And the core insight, that agent context is as important as the code itself, is something I believe in my bones because I've been hacking around it myself.

Their long-term ambition seems to involve moving beyond git. I'm more dubious about that part. Git is unkillable. My bet is that the reality will be hooks and duct tape around git for the next few years — and honestly, that's probably enough. Git's data model bends a lot further than people think before it breaks.

There's a deeper tension, though. Entire's model assumes humans are still in the loop — driving agents, reviewing output, caring about attribution. But that's already not quite how it works. I haven't written a line of code in months. I describe what I want, the agent writes it, I tell it to fix its mistakes, and it does. I'm not a developer anymore — I'm a director.

And the trajectory is obvious: agents won't need directors much longer either. If agents are fully autonomous, who's the audience for commit context and session transcripts? The agent doesn't need to remember what it was thinking — it can just re-derive it. The human who never touched the code doesn't need line-level attribution.

That could go either way for Entire. Maybe full autonomy makes provenance more critical — precisely because no human was involved, you need a machine-readable audit trail. Or maybe it makes the whole problem vanish — agents that manage their own context don't need git hacks to preserve it.

Either way, if you're leading an engineering team right now, you should be thinking about how you'll audit, understand, and trust the code your agents produce — whether there's a human in the loop or not.

Next up, I'll dig into the actual source code and show you how Entire's Checkpoints CLI works under the hood. It's a clever piece of engineering that abuses git internals in ways I genuinely admire.