git — jd:/dev/blog

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.