Ich habe lange Vibe-Coding gemacht. Eine Claude-Session, ein vager Prompt, ein Feature. Das fühlt sich schnell an – und ist brüchig.
Conventions werden vergessen, sobald der Context voll ist. Tests sind „später". Style driftet von File zu File. Und reproduzieren kann ich den Workflow morgen schon nicht mehr.
Irgendwann habe ich kapituliert und das Problem ehrlich angeschaut: Es ist nicht Claude, das versagt. Es ist mein Setup. Ein einzelner Allround-Agent ist in jedem realen Engineering-Team ein offensichtlicher Anti-Pattern.
Also habe ich angefangen, das Team zu bauen.
Die Pipeline auf einen Blick
Was heute in einem Rails-Projekt läuft, an dem ich aktuell arbeite: Ein einziger Befehl – /ship 42 – nimmt eine GitHub-Issue-Nummer und schiebt sie durch vier Phasen bis zum Pull Request.
↓
[Phase 1] Planner (Opus) → schreibt Plan
↓
[Phase 2] Developer (Opus) → implementiert
↓
[Phase 3] Tester ║ Reviewer ← parallel
(Sonnet) (Sonnet)
↓
[Phase 4] Team Lead → Commit + PR
Vier Rollen, klar abgegrenzt, jede mit eigenem Job. Das ist der ganze Trick.
Die vier Rollen
Planner
Der Planner liest die Issue, exploriert die Codebase, legt einen Branch an und schreibt einen strukturierten Plan: Files-to-modify, Implementation Steps, Testing-Strategy, Acceptance Criteria. Modell: Opus.
Wichtig: Der Planner hat keinen Edit-Zugang. Er kann lesen und greppen, aber nicht schreiben. Damit ist garantiert, dass er nicht „kurz mal" anfängt zu implementieren – er muss seinen Plan abgeben.
Developer
Der Developer bekommt nichts außer dem genehmigten Plan. Keine Issue-Diskussion, keine Vorgeschichte, kein Spielraum. Er arbeitet inkrementell – Migrations, Models, Services, Controllers, Specs – und lässt nach jedem logischen Chunk die Tests laufen. Modell: Opus.
Tester
Der Tester mappt die geänderten Source-Files auf ihre Specs (app/models/foo.rb → spec/models/foo_spec.rb), läuft die Specs, lässt den Linter drüber und macht Playwright-Screenshots, wenn Views betroffen sind. Modell: Sonnet – mechanische Verifikation braucht kein Opus.
Reviewer
Der Reviewer prüft den Diff gegen eine feste Checkliste: Code Quality, Rails Best Practices, Security, Tests. Aber er reportet nicht nur – er fixt direkt. Und er hat eine zweite, härtere Aufgabe: Plan-Compliance verifizieren. Jedes Acceptance Criterion aus dem Plan muss im Diff abgedeckt sein. Halluzinierte Fertigstellung wird hier abgefangen.
Tester und Reviewer laufen parallel – beide in einem einzigen Tool-Call gespawnt, beide auf denselben Diff. Spart Wartezeit ohne Qualitätsverlust.
Die Standing Orders
Über allem liegt eine CLAUDE.md, die jeder Subagent als Kontext zieht. Keine Doku – eine Verfassung:
- Minimale Diffs, einfach > clever
- Existierenden Patterns folgen
- Jede Code-Änderung braucht Tests
- Nach jeder Implementation: /test → /review automatisch
- Niemals force-push, niemals amend
- git add selektiv, niemals -A
Diese Regeln stehen über allem anderen. Wenn der Developer sie verletzen würde, verliert er den Review – und das weiß er, weil dieselbe Datei auch Teil seines Kontextes ist.
Der Hook, der nie vergisst
Eine Sache habe ich nicht den Agents überlassen: Code-Formatierung. Ein PostToolUse-Hook in .claude/settings.json formatiert nach jedem Edit oder Write automatisch:
"matcher": "Write|Edit",
"hooks": [{
"command": "docker compose exec -T app bundle exec rubocop -A",
"timeout": 30
}]
}]
Style-Diskussionen entfallen komplett. Der Hook ist deterministisch, der Linter ist nicht-verhandelbar, und niemand muss Claude erinnern.
Was ich daraus gelernt habe
1. Spezialisierung schlägt Allzweck. Vier Rollen mit schmalen Jobs liefern besseren Output als ein Generalist mit allen Tools.
2. Constraints sind Features. Der Planner ohne Edit-Access ist mächtiger als ein Planner mit „bitte nicht implementieren" im Prompt. Tool-Beschränkungen sind harte Garantien, Prompts sind Wahrscheinlichkeiten.
3. Plan-Compliance ist das wichtigste Qualitätsgate. Halluzinierte Fertigstellung ist der Failure-Mode, der am meisten kostet – und gegen den nur ein expliziter Compliance-Check hilft.
4. Hooks fangen, was Agents vergessen. Was nicht von der Wahrscheinlichkeit eines Sprachmodells abhängen darf, gehört in einen Hook, nicht in einen Prompt.
Wann sich das lohnt
Nicht für jedes Skript. Wenn du einmal etwas ausprobierst, ist Vibe-Coding genau richtig. Aber sobald ein Projekt feste Konventionen, regelmäßige Issues und ein bestehendes Spec-Setup hat, lohnt sich die Investition – und zwar schon nach wenigen Features.
Die ersten drei Stufen reichen für die meisten: CLAUDE.md, ein paar Slash Commands, ein Auto-Format-Hook. Alles darüber baust du erst, wenn die Komplexität es verlangt.
Du baust nicht mehr Software. Du baust die Pipeline, die deine Software baut.
Wenn du systematisch durch die Reifestufen gehen willst, habe ich das im Knowledge-Bereich beschrieben: Software Factory aufbauen.
Fragen oder dein eigenes Setup zeigen? Schreib mir auf LinkedIn.