Loading today’s stories
Build1 distinct publisher3 min readPublished
A near-miss in one developer's repository: an agent planned a production build from a branch that only looked authoritative. What stopped it was a peer agent, and then written rules.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
A git worktree per session buys separation of working files and not much past that [8][19]. Everything that broke, or nearly broke, sat in a namespace the worktree does not cover [19]. Container image tags are global to the registry, so two sessions building different content as 1.0.399 produce a silent overwrite, and the author reports a chained command error that pushed new content onto an old tag, so the behaviour survived the rollback [13]. Branch authority is the same class of shared fact: main looked like the base and was not, because production tracked a dedicated deployment branch that main trailed by dozens of versions [4].
Read the near-miss as an operations failure rather than an agent failure. Session B's plan was internally coherent, which is to say it announced a frontend build of 1.0.399 from main [3], and it was wrong only because of a repository convention that had never been written anywhere the agent could read it [15]. Session A caught it, B stopped before pushing and cherry-picked onto the deployment branch instead [6], and the human found out afterwards from the logs [7]. A correct diff on the wrong base would have taken weeks of shipped features out of production [5].
The arithmetic decides how far any of this scales. Coordination is pairwise: three sessions have three channels to keep straight, five have ten [18]. Going from three agents to five roughly triples the number of relationships every rule has to hold across, while the cost of adding each agent stays flat. That curve is why human teams grow process, and the recipes here are that process. Territory is assigned by directory, with talk components to the voice session, broadcast to streaming, and callgw to the phone session [9]. Shared trees get a hard check of branch and git status before any commit, adopted after one session nearly committed another session's staged changes [10].
The item I would lift out of the seven [17] is the shape of the stand-up. Sessions declare not only the files they will touch but the ones they will not, and the author credits that second half with nearly eliminating file conflicts [11][12]. Declaring intent is cheap. Declaring abstention is what lets a peer keep working without asking permission. It is also the only outcome the post reports, and it is a qualitative one [12].
The durable fix is the ledger. Put what is running where into Kubernetes manifests and commit the tag update with each deploy, and any session can read the current state out of the repository instead of querying the cluster [16]. A registry check by API before deploying does the same job for tags [14]. Both moves convert an ambient fact into a versioned one, which is the only form a peer with no memory of yesterday can be trusted to read. This is one team's operating experience, originally published in Japanese and carried on dev.to as a follow-up to an earlier piece on worktrees [20], and it comes with no collision counts on either side of the rules.
Ranked by verification strength, evidence, and original report placement.
The author ended up with 3 to 5 Claude Code sessions simultaneously developing the same microservices, which he describes as having become actual team development rather than parallel execution of tools.
Session B (streaming) messaged that it was about to build the frontend as version 1.0.399 based on main, while Session A (voice) was mid-refactor.
In that repository the authoritative branch for production was not main but a dedicated deployment branch; the latest features from the past few dozen versions existed only in the deployment branch, and main was outdated.
Had Session B deployed an image based on main, weeks' worth of features would have been rolled back in production.
Session A sent a warning, Session B halted the build before pushing, then cherry-picked its changes into the deployment branch and rebuilt the image.
The exchange was handled autonomously between the agents via session-to-session messages, and the human author only learned of it later from the logs.
Follow any of these and your For You feed starts watching them — no settings page required.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Detailed but uncorroborated first-person account
The narrative is unusually specific for a practitioner post — named sessions, directory ownership, image tags 1.0.399 and 1.5.1072, a concrete recovery sequence — which raises internal plausibility. But everything traces to one self-published, translated article by the operator himself: no logs, manifests, registry records or second observer are published, no incident dates are given, and the effectiveness claims are unquantified. Prescriptive recipes are well specified; empirical support is thin.
One practitioner's workflow, no external uptake data
The only adoption fact is the author's own disclosed use of 3–5 parallel Claude Code sessions on one microservices repo, plus incidents inside that same environment. Nothing in the cluster indicates other teams running the pattern, no download, seat, release or vendor-usage numbers appear, and the recipes are not shipped as tooling anyone else could be observed adopting.
Modest overstatement in the framing, not the recipes
The recipes and the incident report are conservative and concretely bounded. The overstatement sits in the interpretive layer: calling multi-session operation 'team development', asserting that human-team practices transfer almost identically, and reporting that scope declaration 'nearly eliminated' conflicts — all from one repository with no measurement. The article also does not confront that its two real failures happened in shared state that its headline control, per-session worktrees, does not isolate.
Self-promotional cross-post, no disclosed vendor stake
The piece is the author's own content republished from his site and explicitly funnels readers to a prior article of his, so there is a visible audience-building incentive and a bias toward presenting the method as working. There is no evidence in the cluster of vendor sponsorship, paid placement, or a commercial product being sold, and the article volunteers its own failures — including a tag overwrite that survived a rollback — which cuts against pure promotion.
Coherent single-witness report
Confidence is limited by structure rather than content quality: one publisher, one witness, one repository, no dates on the incidents and no external check on any specific. The claims are internally consistent and the mechanisms described (registry tag namespace collisions, divergent authoritative branches, agents lacking documented deployment context) are ordinary and mechanically plausible, which supports moderate rather than low confidence in the operational lesson while leaving the generalisations unresolved.
build
The hard part of running five coding agents is not the model, it is the process tree1 distinct publisher
build
Thirteen tasks green, then "give up (Recommended)" on the one that needed understanding1 distinct publisher
build
Your reviewing model is reading the diff when it should be reading the session1 distinct publisher
build
Exit 0 is not a health check: three weeks of macOS backups that copied nothing1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 26, 2026