release: v3.30.0 - 10 advanced patterns documentation

5 new files (plan-challenger, adr-writer, audit-codebase, first-principles, event-driven-agents),
4 workflow files enriched (iterative-refinement, agent-teams, ultimate-guide x3 sections),
reference.yaml updated with 9 new entries. Fact-checked via 9 Perplexity searches (March 2026).

Patterns covered: modular CLAUDE.md architecture, session invariants, auto-ADR, adversarial
plan review, worktree dependency coordination, auto-fix loops (Ralph Loop), Linear/Kanban
event-driven agents, codebase audit scoring, deployment automation (Vercel + Infisical).

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
Florian BRUNIAUX 2026-03-03 06:27:28 +01:00
parent 01283fafec
commit d9187ba17b
13 changed files with 1540 additions and 17 deletions

View file

@ -117,6 +117,30 @@ Agent teams represent the evolution from "single agent" to "coordinated teams" p
| **Over-delegation** | Context switching cost exceeds gains | Active human oversight on critical decisions |
| **Premature automation** | Automating workflow not mastered manually | Manual → Semi-auto → Full-auto (progressive) |
### When Large Teams ARE Justified
The ">5 agents" rule above is a sensible default, but it breaks down in specific scenarios where the math favors larger teams. The real question is not "how many agents?" but "is the coordination overhead less costly than the context overflow?"
**Context window as the deciding factor**: A single Claude Code agent on a 50K+ line codebase fills 80-90% of its context window just loading the relevant files (source: atcyrus.com). At that point, the agent has almost no room left for reasoning. Splitting across multiple agents keeps each one at ~40% context usage, which leaves headroom for actual problem-solving.
| Scenario | Single Agent | 3-Agent Team | 5-Agent Team |
|----------|-------------|--------------|--------------|
| 10K line codebase | ~30% context, comfortable | Overkill | Overkill |
| 50K line codebase | 80-90% context, degraded reasoning | Ideal split | Justified if truly parallel modules |
| 100K+ line codebase | Context overflow, agent misses files | May still overflow per agent | Justified, consider even more |
**When more agents make sense**:
- Independent modules with zero shared state (no coordination overhead to pay)
- Parallel refactoring across isolated file trees (frontend vs backend vs infra)
- Read-heavy analysis where each agent covers a different subsystem
- The codebase physically cannot fit in one agent's context with room to spare
**When more agents hurt**: If agents constantly need to read each other's output or modify shared files, adding agents adds merge conflicts and coordination messages that eat into the very context you were trying to save.
> **Note on model selection per role**: As of March 2026, all agents in a team run the same model (Opus 4.6, required for Agent Teams). The community has requested role-based model selection where the team lead runs Opus for planning, implementation agents run Sonnet for speed, and test agents run Haiku for cost efficiency. This is not yet supported. The current workaround is spawning separate Claude Code processes with explicit `--model` flags, but you lose the built-in coordination and shared task list. Track this as a community feature request.
For broader industry context: Gartner predicts 40% of enterprise applications will incorporate task-specific agents by end of 2026. The team coordination patterns being established now in Claude Code and similar tools will likely become standard practice.
### Cost-Benefit Analysis
**Agent Teams** vs **Multi-Instance Manual**: