Skip to main content

2 posts tagged with "git"

View all tags

Two Writers, One Working Tree: Concurrency Control for Human-Agent Co-Editing

· 10 min read
Tian Pan
Software Engineer

You are halfway through renaming a function when the file reloads under your cursor. The diff you were staging no longer matches the working tree. Your dev server hot-reloads twice for no reason you can see, and a test that passed ten minutes ago now fails in a file you never opened. Nothing crashed. Nothing warned you. You and your coding agent have just been editing the same working tree at the same time, and you found out the way most teams find out: through mystery diffs.

Databases solved this problem fifty years ago and gave it a name — concurrency control. Two writers touching shared mutable state need either a lock, an isolation boundary, or a merge protocol, and the choice among those is a design decision with known trade-offs. Yet most engineering teams adopting coding agents never make that decision explicitly. They drop a second writer into a single working tree, keep the habits of a single-writer world, and then file the resulting weirdness under "AI being flaky." It is not flakiness. It is a race condition, and you are one of the racers.

The Branch State Your Coding Agent Forgot to Check

· 10 min read
Tian Pan
Software Engineer

Your coding agent does not know which branch it is on. It thinks it does. It saw a git status output twelve turns ago, it has a CLAUDE.md in its context that mentions the branch name the session opened against, and it watched a tool result list five files that were the right files at the time. The agent has been quietly reasoning against that snapshot ever since. Meanwhile, in a second terminal, you ran git checkout main. The agent's diff lands cleanly on the file system because the OS does not care which branch the bytes belong to. The diff is semantically wrong because the agent's mental model of the branch is stale by three hundred commits and the parent it was reasoning against no longer exists in your working tree.

This is branch-state drift, and it is the coding-agent analog of a read-modify-write race in a database. The agent reads the world at turn N, modifies its plan across turns N+1 through N+k, and writes back to disk at turn N+k+1 — and somewhere in that window the world changed underneath it. No exception fires. No tool returns an error. The patch applies. The harm shows up downstream: a PR opened against the wrong base, a hand-written commit that silently reverts an intervening fix, a feature implemented against a schema that was migrated yesterday.