Brain-Worker Pattern¶

vibecodingisold was built using a Brain-Worker Hybrid orchestration pattern that we believe generalizes to any large multi-phase content build — technical handbooks, compliance documentation, training material, knowledge bases.

The full methodology lives at methodology/brain-worker-orchestration.md in the repo (962 lines, standalone-readable, skill-convertible).

This page is the orientation summary.

The pattern in one paragraph¶

One Opus session as Brain (plans, briefs, reviews, consolidates — never executes); seven claude --dangerously-skip-permissions Sonnet terminals as Tiefe-Research-Worker (one per role, parallel, self-contained prompts); Adversarial-Review subagents inside the Brain session (each worker output gets challenged by a different model perspective before acceptance); Synthesis subagents (final consolidation across roles, conflict resolution, profile-derivation); Distribution subagents (re-render canonical content into each tool's native config format). Total wall-clock time for V1: roughly 3 weeks of Brain-time plus ~80 worker-terminal-hours running in parallel.

Why this pattern exists¶

Complex AI-coding tasks fail in predictable ways when run in a single chat window:

Context-window exhaustion mid-task — model forgets earlier requirements.
Output-quality drift — Item 1 is excellent, Item 30 is generic.
Hallucinated sources — when the model is under token pressure.
Poor parallelization — two independent sub-tasks run sequentially and take 2x as long.
Loss on crash — an hour of work gone because the session died.
Inconsistent outputs across sub-tasks — Role A has 30 items in format X, Role B has 12 in format Y.

These have three structural causes:

Token concentration. A single model run has to plan, research, write, and review at the same time — the PM and the engineer simultaneously. That's cognitively overloaded even for frontier models.
Missing briefing discipline. AI tools get sloppy prompts ("research production-readiness"). Without rigid format constraints, output drifts naturally.
Missing recovery architecture. When a sub-task crashes or produces bad output, there's no "read the last safe-state and continue" — typically you restart from scratch, burning tokens and frustrating the user.

The Brain-Worker pattern addresses all three: separate the planning (Brain) from the doing (Workers), give each Worker a precise self-contained briefing with identical output format, have Workers write incrementally to files, and have the Brain review at every phase boundary.

Brain — the role¶

The Brain terminal is the architect and reviewer. Its responsibilities:

Strategy and scope — what's being built? Which phases? Which workers?
Briefing creation — every Worker gets a Markdown file with precise instructions.
Worker orchestration — which Workers run in parallel? Which sequentially? Which dependencies?
Quality gates — review Worker output against minimum standards before it flows into subsequent phases.
Conflict resolution — when two Workers produce contradictory results, the Brain decides.
Consolidation — final synthesis of all Worker outputs into the master artifact.

What the Brain NEVER does:

Write production output (that's Worker work).
Conduct deep research itself (that's Worker work).
Detail-implementation (that's Worker work).

Reason: if the Brain does deep work itself, its context window exhausts and it can't consolidate cleanly or catch conflicts. Brain holds its context window clean for strategic decisions.

Worker — the role¶

A Worker is an isolated AI instance with these properties:

Its own context window (typically 200k-1M, depending on model and setup).
Its own tool availability (Read, Write, Edit, Bash, WebSearch, WebFetch, etc.).
Self-contained briefing — Worker reads only its briefing file and knows nothing else about conversation state.
Writes its output artifact directly to a designated path.
Returns a short status report at the end — not the full output.

Workers can be:

A separate terminal window with claude --dangerously-skip-permissions (or Cursor Composer in Agent-mode, Cline-session, etc.).
A subagent call inside the Brain session (e.g., Claude Code's Agent tool).

Both are valid; they have different trade-offs (subagents have lower setup cost but share Brain context; separate terminals have full isolation but higher orchestration overhead).

The 5 build phases¶

vibecodingisold V1.0 was built in 7 phases over ~25 hours wall-clock. The first 5 are the orchestration backbone:

Phase 1 — Role research (7 Workers in parallel terminals, each producing one role file with 30-50 items, ~15-20 hours wall-clock).
Phase 2 — Role review (Brain reads each role file against the 9-field quality gate; rejections returned to Workers with named issues).
Phase 3 — Adversarial review (a separate adversarial subagent per role file, surfacing gaps; 21 cross-cutting gaps surfaced and patched).
Phase 3.5 — Conflict resolution (Brain decides 9 cross-role ownership conflicts; produces _conflict-resolutions.md with 8 binding Numerical Contracts).
Phase 4 — Synthesis (final consolidation: master PLAN-REQUIREMENTS.template.md + 6 profile files + cross-reference graph).

Phases 5-7 are distribution and launch-readiness — see the full methodology doc.

Why this pattern works for content builds¶

Three properties make Brain-Worker the right fit for multi-role content:

Independence between roles. The 7 senior-engineering roles (architect, backend, database, security, devops, sre, qa) are largely orthogonal. Each Worker can produce its role file without coordinating with the others. The Brain handles cross-role conflicts in Phase 3.5 once.
Identical output shape per role. All 7 roles produce items in the same 9-field template. The Brain's quality gate is mechanical: count fields, check sources, verify the failure-mode-category mapping. This makes Worker output verifiable without re-doing the research.
High parallelism. 7 Workers in 7 terminals run in true parallel (independent processes, independent context windows, independent rate limits). 80 Worker-hours compress to ~15 wall-clock hours when fanned out.

The pattern would not work as well for tightly-coupled tasks (e.g., refactoring a tangled codebase where every file depends on every other). For those, single-window execution with careful planning is still better.

Where to learn more¶

The full methodology document is the canonical artifact:

methodology/brain-worker-orchestration.md — 962 lines, includes:
The full Brain vs Worker role definitions
3 architecture variants (Pure Subagent, Hybrid, Pure Terminal) with trade-off analysis
The Worker-briefing template (with hard minimum requirements)
Quality-gate enforcement patterns
Resume-marker convention for crash recovery
Adversarial-review pattern
Synthesis pattern
Distribution pattern
Lessons learned from V1.0 (6 named pitfalls and how to avoid them)

If you want to apply this pattern to your own content build, the methodology doc has the full pattern in standalone form. The vibecodingisold build is the worked example; the methodology is the transferable artifact.

Multi-AI stack¶

The V1 build used a multi-AI stack, not just Claude:

Claude Opus (Brain) — strategic reasoning, briefing creation, quality-gate enforcement, conflict resolution.
Claude Sonnet (Workers) — deep role research, item drafting, self-verification.
Codex (adversarial review) — second-opinion challenges on Worker output.
Goose / Gemma / OpenCode (execution) — for downstream tasks where Brain orchestration was overkill.
Semgrep / Snyk (static security review) — when individual items needed CVE-scanning verification.
ChatGPT (prompt variant generation) — A/B testing of Worker briefing wording.

Gemini was deliberately excluded (model-quality reasons, not philosophical). Shannon (autonomous web pentester, AGPL, sandbox-only) is reserved for a one-time staging pentest in V1.x post-launch.

The multi-AI stack matters because it eliminates single-model bias. If a defect would be invisible to Claude Opus but obvious to Codex (or vice versa), the second-opinion catches it at Phase 3.