What broke when I ran 16 Claude Code sessions as a team

I am one person. Daywell has an iOS app, an Android app, a website, a Supabase backend, a growth plan, a security program and a pile of legal paperwork. The way I get all of that done is that I run sixteen Claude Code sessions, and each one has a job title.

This post is how that works, and mostly what broke. Every rule I run on came from something going wrong, and I wrote the rule down the same day so I would stop paying for it twice.

How do I run several Claude Code sessions on one codebase without conflicts?

Give each session one area, its own folder, worktree and branch, and a rule that it never edits another area's code. Here is how mine are set up.

I call each session an operator. There is an iOS operator, an Android operator, Web, Backend, Ops, Analytics, Growth, Security, Design, Product, Business, Social, Integrations, CI, an auditor and a triage session for my junk drawer. The operators file lists 16 rows. Each one opens its own folder as the working directory, so its own instruction file loads on top of the shared one.

The first rule in that file is boring and has saved me the most: stay in your lane. An operator never edits another operator's code. It files a task instead.

Each operator also gets its own git worktree and its own branch.

How should Claude Code sessions hand off work to each other?

Through something that outlives the session. Mine is a board that is just a folder of text files.

My first board lived in Notion. On 2026-10-01 I moved it into the repo: one card, one file, a small header, a line of dashes, then notes with the newest first.

title: Web: Daywell Labs engineering blog at getdaywell.com/labs
status: Ready
platform: Web
priority: P2 - Soon
type: Task
estimate: M - 1-2 days
epic: Growth
waiting_on: Design
---

A script lists cards, runs read-only SQL over them, files new ones and updates old ones. It commits exactly the one card it changed. There are now more than 3,100 card files, and about 2,850 of them are closed.

Sessions do not message each other to hand off work. A message vanishes when a session ends, and a card does not. When one session does need to nudge another, it goes through a small inbox script, so a busy session reads the message when its turn ends instead of burning a turn to receive it.

Before anything risky ships, a review council runs. It is four persona subagents with different jobs: an engineer, a working parent, a money and risk person, and an analytics owner who sits on every council. They run in parallel and a session triages what they say.

What happens if an AI agent deletes my shared test account?

It happened to me: a deletion test ran on the shared account. Now that account is never deleted, and deletion tests use a fresh throwaway named first.

Daywell has one shared test account. It lives on a test phone and a test household. During a security walk that was meant to prove account deletion really deletes, the deletion hit that account. The shared one. The walk worked, which is the part that stings.

The rule: the shared test account is never deleted, and no wipe walk runs on it. Deletion walks use a fresh throwaway account that is named on the card before the walk starts. Later I added a rule that a throwaway comes from a disposable inbox service, because codes sent to a normal mailbox did not work for us.

The lesson I took: if a rule only lives in my head, the next session cannot follow it. It has to be in the file every session loads.

Why does my analytics event show zero when the client says it saved?

The server can silently refuse an event while the client reports success. Count nothing as measured until the live table shows it, and let the server record the event.

The Growth operator has a line in its instructions that reads like a scar. An invite event, a household joining, was silently refused by the server for a stretch of commits while the client reported success. The client logged "done." The table stayed empty.

Nothing looked broken. The number just sat at zero, and zero is a plausible number for a new app.

The rule: nothing counts as measured until the Analytics operator confirms the event lands in the live table. A related one in the root file says a refused save is never reported as saved. The fix I care about moved the event to the server, so the client no longer decides whether it happened.

How do I know when an AI coding agent's claim is true?

Treat it as unchecked until it points at a file, a card or a live read. Two wrong reports taught me that.

At one point a session told me it had flagged a problem to another operator. I relaxed. It turned out the flag was an FYI that nobody owned, and the other session never picked it up. Around the same time Ops reported a switch as off that had been on for two hours.

Both were the same mistake: reporting another session's state from memory.

Now a handoff is real only when the receiver replies that they own it, or when a card exists with that operator as owner. Anything else gets reported as what it is: "I mentioned it to the iOS operator; nobody has picked it up yet." A claim about another operator's state gets read back from the source first, or it is labelled unchecked.

I made the rule stricter after seeing sessions say they were waiting on something that was already finished. One Android session was waiting on a redirect another operator had removed. A Web session was waiting on a shared file already sitting on the main branch. A card sat waiting on a card that was done. Before any session writes "waiting on X," it checks the code, the live system, the card's own text or X's own reply. We even added a board status for it, and cards that wait only on another card now sit in their own bucket outside the open count.

How do I stop Claude Code helper agents from burning through my usage?

Cap them. I learned how the expensive way.

Sessions can spawn helper agents, and for a week I let them. A week of my usage allowance went on long sessions and parallel helpers, and the work shipped did not justify it.

The rules that came out of it, all in the root instructions:

• Helpers run on a cheaper model unless the card says why this job needs the expensive one. Mechanical work such as filing, sweeps and greps never uses the biggest model.
• At most two helpers per operator at a time, never two on the same file.
• A session never changes model or effort in the middle of a conversation, because a switch makes it re-read everything at full price.
• A session with nothing unsaved clears its context at 25% of the window. One with unsaved work is told to clear at 50%, after it commits, pushes and writes down its state.

I replayed old sessions against a 25% rule and the replay came out about a third cheaper. That is one replay of my own sessions, not a controlled test.

How do I stop AI agents from repeating a claim nobody verified?

Never let a note stand in for a source: every word a parent reads comes from one shared file, and each app is tested byte for byte against it.

The iOS operator once carried a comment saying a line of copy was already shipped on the website and must not be reworded. The website did not contain that sentence at all. The false claim was relayed to a second session before anyone compared the two files.

That is why every parent-facing string now comes from one shared JSON file, each client's copy is tested byte for byte against it, and typing a value that already exists in a shared fixture counts as a defect. A test that catches drift after the fact is not enough. The point is that nobody has a copy to drift.

Can an AI review council fake a security sign-off?

Yes, by accident. A council seated a security persona and its write-up read like real sign-off, so now sign-off comes only from the session that owns security.

A review council once seated a security persona and the write-up read like our security lead had signed off. The security session never saw it. Now sign-off comes only from the one session that owns security.

What I would tell another solo founder

Treat every claim another session makes as unverified until it points at a file, a card or a live read. Mine are confident and wrong often enough to matter.

Keep your own lane rule. Sixteen sessions is not sixteen times the output. I have not measured the multiplier. It is sixteen things that can disagree with each other, and the board and the rules are the only reason they mostly do not.

And keep a budget. The cheapest session is the one you did not start.

Daywell (getdaywell.com) reads a parent's school and daycare email and turns it into a short list of what to have ready, and when.