Those two factions, and the terrain both of them stand on, were being worked on at the same time by different sessions on the same copy of the project. That is normal here rather than exceptional. Adam runs several Claude Code sessions at once, in separate editor tabs, every one of them pointed at the same folder. Nothing coordinates them. They do not know about each other, they each hold their own picture of what is on disk, and that picture is taken when the session starts and then goes quietly out of date.
The practice was never designed. It grew because Adam had more things he wanted than one conversation could hold, and the natural response to that is another tab. It buys a great deal and it costs something specific, and the cost is easiest to see in the one rule this project had to learn the hard way: you run one art pipeline at a time, and you do not stop one halfway through.
What it buys
The work here splits naturally. On a given afternoon there might be a problem with how the 3D ground is drawn, a balance pass over the spells, a batch of model generation that is mostly waiting on Meshy's servers, and a documentation sweep. None of those four touches the others' files. Running them one after another means three of them are idle while Adam waits on the fourth, and a lot of that fourth is a progress bar.
Tabs turn that into wall-clock time saved rather than work saved. The heaviest day on this project landed 48 separate changes, in August, and that number is only reachable because several streams of work were in flight while Adam was reviewing the output of a different one. It is the same reasoning that makes fanning a single task out across several agents worthwhile, applied one level up: instead of one session splitting one job, several sessions hold several jobs.
The second thing it buys is cheaper interruption, which matters more here than it would elsewhere, because interrupting is how Adam works. Three new ideas arrive in the middle of something long. They go into a new tab, get answered there, and the long-running work never notices.
What it costs
Two sessions changing the same file is the obvious failure, and it is the least dangerous one, because it announces itself. One session reads something, the other rewrites it, the first tries to edit text that no longer exists, and the edit fails loudly rather than silently.
The dangerous version is the out-of-date picture. A session that has been open for an hour is reasoning about a project as it stood an hour ago, and this one routinely carries a large pile of unfinished work, because several streams are usually mid-flight. A session holding a stale picture and reaching for a destructive version-control command to tidy up would delete work another session was in the middle of, and version control would consider that a completely successful operation. The standing rule is therefore that an unwanted change is reversed with another change, never by discarding, and it exists because the alternative is unrecoverable rather than merely annoying.
Under both of those sits the real problem, which is shared state that version control does not track.
The art pipeline is where sessions actually collide
One command runs the whole art pipeline and then uploads the result to the content delivery network that serves the game's images: pack the small sprites into large combined sheets, compress everything, regenerate the index that maps each file to its current version, then copy it all up. Every one of those stages reads and writes shared state on disk. The packer keeps a cache so unchanged sheets are skipped. The index is a single file rewritten from scratch. Two runs at once interleave through both.
The symptom is not a crash. It is a slow run, or a run that appears to finish and has uploaded a mismatched set, and neither is visible from inside the session that started it. Stopping a run partway through is worse, because it leaves the cache and the index describing a state that never existed.
The command carries the scar tissue from getting this wrong. It copies rather than mirrors, because some art lives only on the network and mirroring from a fresh copy of the project would delete it. It compares files by their contents rather than by their timestamps, and that one was learned expensively.
Comparing by timestamp once skipped a re-compressed image because the copy on the server looked newer. That left the server holding a description file from one packing run and an image from another. Nothing errored. The upload reported success. The description was internally consistent. It surfaced as icons in the interface drawn at the wrong offsets, found by Adam looking at the screen and thinking the buttons looked odd. Because the served art carries a one-year cache header, a mismatched pair that reaches a browser can be cached there effectively forever.
The fix was ordering rather than locking. The upload now runs in two passes, images first and description files last, because the game works out where each image lives by reading its description file. As long as a description is never visible before the image it describes, a player cannot fetch a mismatched pair no matter what raced with what. Making the interleaving harmless turned out to be far cheaper than preventing it, here and everywhere else it came up. The related memory failure, where the same packed sheets took a browser tab out of RAM, is its own story, and the pipeline they run through is another.
Four rules that make a shared project survivable
None of these is specific to agents. They are what any two participants writing to one copy of a project at the same time need, and they hold whatever those participants are.
Split by location, and say so before the work starts. Not "you take the rendering work", which is a topic, but the folder, which is an address. A topic gets resolved independently by each participant and the two resolutions overlap at the edges, which is exactly where the shared file turns out to be. Every brief here names the folders it owns and adds that writing outside them, scratch output included, is out of scope.
Commit by explicit list, never by staging everything. Staging every changed file at once, in a project three sessions are writing to, sweeps their half-finished work into your commit, and your message then describes a fraction of what the commit contains. Six weeks later that commit is unreadable and cannot be undone, because undoing it also undoes another session's unrelated change. Naming the files you actually touched costs a few seconds per commit and removes the entire class of commit that carries another session's broken intermediate state.
Never edit another session's in-progress file. Report the bug to it instead. Fixing it yourself means writing against text that is mid-rewrite, so either the edit fails against a version that has moved or it lands and is overwritten by the next write from the owner. Saying "the loop you are working on is off by one" costs less than either outcome and leaves one participant holding one file. This is the same reason an unwanted change here gets reversed with another change rather than by discarding: the destructive operation cannot tell your mistake from another session's work in progress.
Take turns on anything with a shared cache or a shared index. Ordinary files mostly announce a collision. Build caches, lock files, generated indexes and anything with a single global table do not, and their failure mode is a plausible wrong answer rather than an error. If two runs of a thing would interleave through the same file on disk, exactly one of them runs at a time.
That last rule is the one worth enforcing in code rather than in a habit, and enforcing it is about five lines. Creating a directory is an operation the operating system guarantees only one caller can win, so a run starts by creating a directory whose existence means "a run is already going", exits immediately if it is already there, and removes it on the way out. The part worth getting right is that it also removes it when the run is interrupted, because being interrupted is the case that actually happens.
The coordination cost is linear in tabs, and Adam pays it
Each extra session adds work that only Adam can do. He decides which session owns which area, so two of them do not converge on the same file. He remembers which one is mid-run, so a second upload never starts. He reads two different answers to overlapping questions and picks one. And when a session reports that something is done, he is the one holding the mental model of whether that conflicts with what another tab just did.
None of that is automated, and it does not get easier with more sessions. It gets linearly harder, which is why the practical ceiling is not the tool but Adam. Somewhere past a handful of tabs, the reconciliation costs more than the parallelism returns, and the tell is that Adam starts asking sessions what they have already changed rather than what they are going to change.
There is also a subtler tax, and it is the thing to design around if you try this. Standing instructions are the only thing every session reads, so anything that must be true across sessions has to live there rather than in a conversation. That works, and it is a large part of why running commands without asking each time is safe here, but it means the coordination layer is a text file, and a text file only holds the lessons that were written into it after the last thing went wrong.
