Series: Weekend at Claude's — misadventures in building a production app with an AI anyone could mistake for the person who's going to make the whole thing happen
I had Claude Code open in one window, running the app, finding real bugs as it went. I had claude.ai open in another, designing a new feature. Same project, same files, same afternoon. I didn't think about it as a risk. It felt like having two competent people on the team.
It is two competent people on the team. Which is exactly the problem.
The collision
I asked claude.ai to design a Home screen feature. It got numbered "A38" and slotted into the task tracker. Reasonable, except Claude Code had already used A38 — for a real bug, a calendar sync issue it found while actually running the app, hours or days earlier in a session that never touched this chat. Same for A39 and A40. claude.ai had no way to know, because it was working from its memory of the conversation, not a fresh read of the file.
I caught it before anything got overwritten, mostly by accident — I happened to notice the number didn't look right. We fixed it. Renumbered the new feature to A41. Wrote down a rule: always re-read the live file before assigning a new task number, don't trust memory.
That felt like the fix. It wasn't.
The fix that wasn't a fix
"Re-read before writing" protects against one tool trusting stale memory instead of the real file. Real failure mode, worth fixing — but it assumes the file holds still between the read and the write.
It didn't hold still. While we were mid-conversation designing that exact rule, Claude Code added seven more tasks — A41 through A47 — in a separate session running at the same time. Two readers checking the same counter at nearly the same moment will see the same number and both claim it. There's no lock on a markdown file. Whichever write lands last just quietly erases the other.
"Re-read before writing" is a behavioral fix — it depends on remembering, every time, under whatever pressure either tool is working under. That's the same category as "be more careful," which doesn't hold up over a long project. It reduces the problem. It doesn't remove it.
The question underneath the question
Before we got to fixing anything, I asked the more basic version of this: should we just stop running two tools on the same project? Drop claude.ai, do everything in Claude Code, and the collision problem disappears because there's only one writer.
It's a reasonable question to ask, and it's worth taking seriously rather than dismissing. But the answer was no, for a reason that has nothing to do with collisions and everything to do with what each tool is actually good at.
Claude Code finds the calendar bug because it's running the app. It has a feedback loop — write code, execute it, see what breaks, fix it, repeat. That loop is the whole value. It's also exactly why Claude Code isn't the right place to think through whether a consent screen should use an 18+ gate or a 13+ gate, or whether four demo orgs should be read-only or lazily forked per user, or how an API layer should authenticate. Those aren't bugs to find by running code. They're decisions to think through before any code exists, where the cost of being wrong is a wasted afternoon of building the wrong thing, not a stack trace.
claude.ai is good at the second kind of work specifically because it isn't tied to an execution loop — it can hold a wide problem in view, weigh tradeoffs, ask "wait, does this contradict something we already decided," and produce a design before a single line of implementation gets written. That's a different shape of usefulness than "run the app and tell me what's broken," and neither one substitutes for the other.
So the real choice wasn't "one tool or two." It was "two tools doing genuinely different jobs, which means the files they share are going to get touched concurrently, which means I need to actually solve the concurrency problem instead of avoiding it by picking one tool." Dropping to one tool would have made the collision impossible by making half the project's thinking disappear along with it. That's not a fix. That's giving up the thing that was working in order to stop the thing that wasn't.
What actually removes it
The real fix isn't a rule either tool has to remember. It's a structural change that makes the collision impossible regardless of timing.
Give each tool its own counter. claude.ai's design handoffs get their own sequence — AD-1, AD-2, AD-3. Claude Code's bugs and build findings get their own — AC-1, AC-2, AC-3. Neither tool ever reads from the other's counter, so there's nothing to race over. Two sessions can run at the exact same second, add a task at the exact same second, and never collide — not because they're careful, but because they're literally not competing for the same number.
That's the difference between a fix that depends on behavior and a fix that depends on structure. I should have gone there first. I went to "read more carefully" first instead, because it felt like the smaller, more obviously-correct answer in the moment. It was smaller. It wasn't sufficient.
The piece I almost missed
Splitting the sequences solves the collision. It doesn't solve something else that surfaced in the same conversation: once two tools are genuinely concurrent, you lose the ability to reconstruct what happened in what order. The project manifest gets rewritten in place every time something changes — correct for "what's true right now," but the history of how it got there is gone the moment it's overwritten.
So there are two documents now. The manifest says what's current. A new changelog — append-only, never rewritten — says what happened and roughly when. "Keep good project records" turned out to be two separate needs that don't fold into one document cleanly.
What I'm taking from this
The actual lesson isn't "use changelogs" or "use prefixed task numbers." It's that running two AI tools on the same project at the same time is a real concurrency problem, the same shape as any other concurrent-write problem, and it deserves the same category of solution — not better discipline, but a structure where the bad outcome simply can't happen. I had the right instinct to ask "how do we keep you both in sync" before I'd actually seen it fail twice in one conversation. Good thing I asked it the second time, not just the first.
Aphilaty is a privacy-first community coordination app. aphilaty.com