[nachocoll]

The 300k line monorepo with 3-6 CLI agents running simultaneously across git worktrees is an interesting production deployment of multi-agent coding. Most discussions are about single-agent workflows; the coordination problems at multi-agent scale are different and less explored.

The key insight in your description is the worktree-per-agent isolation pattern. Without that isolation, agents would interfere with each other's changes unpredictably. With it, you get parallel throughput but the coordination overhead shifts to you — when do worktrees get merged? How do you handle when two agents modify overlapping code?

The Agile Vibe Coding Manifesto's concerns about accountability and traceability become especially important at multi-agent scale. "Every change has traceable intent" is harder to maintain when six agents are generating changes in parallel. The manifesto's argument would be that the investment in architectural constraints and explicit context for each agent is what prevents the throughput gains from creating an unmaintainable diff explosion.

Curious what your PR/merge workflow looks like — that seems like where the real complexity lives: https://agilevibecoding.org

[parsak]

the way i handle it in pane: every pane is one worktree, and the diff viewer + keyboard shortcuts (squash, rebase, merge) are right there before you ever push. so the review step isn't a context switch -- it's just... the next thing in the same window

the harder problem you're pointing at is agent-to-agent coordination. i don't try to solve that at the orchestration layer. i keep it simple: one agent per feature, and they don't touch each other's worktrees. when feature A needs something from feature B, i merge feature B first. boring, but it doesn't blow up

the ADR / architectural governance point from agilevibecoding.org is interesting though -- have you seen teams actually ship something like that in practice? or is it mostly theoretical at this scale?