Re:Is anyone else drowning in terminal tabs running AI codin...
by parsak on Thursday March 19, 2026 @12:46PM
(#47442291)
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?
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