Software Factory aufbauen

Du bist nicht mehr Coder, du bist Team Lead

Der eigentliche Rollenwechsel: Statt jeden Schritt selbst zu tippen, definierst du Rollen, Übergaben und Qualitätskriterien – und lässt mehrere spezialisierte Agents gemeinsam ein Feature von der Idee bis zum Pull Request bringen. Du gibst Richtung vor, du kontrollierst Qualität, aber du sitzt nicht mehr im Maschinenraum.

Die sechs Reifestufen

Stufe 0 ist der Allzweck-Agent – der Ausgangspunkt, mit dem die meisten anfangen. Die sechs Stufen darüber baust du additiv ein, jede löst ein konkretes Problem der vorigen.

Stufe 0: Der Allzweck-Agent

So fangen die meisten an: Eine Claude-Session, die alles macht – planen, coden, testen, committen. Das funktioniert für kleine Tasks, aber ab einer gewissen Komplexität wird es brüchig:

• Conventions werden vergessen, sobald der Context voll ist
• Der Code-Stil driftet zwischen Files
• Tests werden vergessen oder nur halb geschrieben
• Du kannst denselben Workflow morgen nicht reproduzieren

Stufe 0 ist nicht falsch – sie ist der Ausgangspunkt. Aber sie ist nicht das Ziel.

Stufe 1: CLAUDE.md als Verfassung

Die erste Investition ist ein hartes, schriftliches Regelwerk. Nicht nur Tech-Stack, sondern auch Golden Rules – die Prinzipien, an denen jeder Output gemessen wird.

## Golden Rules

- Minimale Diffs, einfach > clever
- Existierenden Patterns folgen, nicht neue erfinden
- Jede Code-Änderung braucht Tests
- Kein neuer Code ohne Plan

Diese Datei ist keine Doku – sie ist die Verfassung des Projekts. Jeder Subagent, den du später spawnst, wird sie als ersten Kontext lesen.

Wann erweitern: Sobald du merkst, dass du dieselben Anweisungen mehrfach pro Woche in den Prompt tippst.

Stufe 2: Slash Commands für wiederkehrende Schritte

Commands sind Markdown-Dateien in .claude/commands/, die als Slash-Befehle verfügbar werden. Sie machen Workflows explizit und reproduzierbar:

• /commit – analysiert Diff, schreibt Conventional-Commit-Message
• /test – mappt geänderte Files auf ihre Specs, läuft sie
• /review – Diff-Review gegen eine Checkliste
• /pr – Push, PR-Beschreibung, gh pr create

Jeder Command ist ein Prompt-Template, kein eigenständiger Agent. Aber du machst aus „dem üblichen Prozess" einen einzigen Befehl – der morgen, übermorgen und in sechs Wochen identisch läuft.

Wann erweitern: Wenn ein Command mehrere Tools braucht und seine Arbeit nicht in einen einzigen Prompt passt.

Stufe 3: Hooks als Sicherheitsnetz

Commands und Skills sind Vorschläge – Claude kann sie ignorieren oder vergessen. Hooks sind anders: sie laufen deterministisch, vom Harness erzwungen, ohne Claudes Zustimmung.

// .claude/settings.json
{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Edit|Write",
      "hooks": [{
        "type": "command",
        "command": "bin/rubocop -A"
      }]
    }]
  }
}

Damit ist Auto-Formatierung garantiert. Style-Diskussionen mit dem Agent entfallen komplett. Hooks sind das Werkzeug für Regeln, die du nicht der Wahrscheinlichkeit eines Sprachmodells überlassen willst.

Wann erweitern: Wenn ein einzelner Allround-Agent zu generisch für die anstehenden Aufgaben wird.

Stufe 4: Spezialisierte Subagents

Hier passiert der eigentliche Mindset-Shift. Statt einem Allzweck-Agent definierst du Rollen:

Der Trick: Tool-Beschränkung als harte Garantie. Ein Planner ohne Edit-Access kann gar nicht implementieren, selbst wenn er „würde wollen". Das ist stärker als jede Anweisung im Prompt.

Jeder Subagent läuft in eigenem Context – das hat den Nebeneffekt, dass dein Hauptcontext sauber bleibt.

Wann erweitern: Wenn die Übergaben zwischen den Rollen so vorhersehbar sind, dass sich eine feste Abfolge lohnt.

Stufe 5: Pipeline-Orchestrierung

Jetzt verkabelst du die Rollen zu einer Pipeline. Ein einziger „Team Lead"-Befehl (z.B. /ship 42) ruft die Phasen in fester Reihenfolge auf:

/ship 42
  ↓
[Phase 1] Planner   (Opus)    → Plan
  ↓
[Phase 2] Developer (Opus)    → Implementation
  ↓
[Phase 3] Tester ║ Reviewer   ← parallel, ein Tool-Call
  (Sonnet)         (Sonnet)
  ↓
[Phase 4] Team Lead → Commit + PR

Zwei Optimierungen, die schnell Wirkung zeigen:

• Parallelisierung: Tester und Reviewer arbeiten an demselben Diff, müssen also nicht warten. Spawn beide in einem Tool-Call.
• Modell-Tiering: Opus für kreative Aufgaben (Planning, Implementation), Sonnet für mechanische Verifikation. Spart Token, beschleunigt die Pipeline.

Wann erweitern: Wenn die Pipeline stabil läuft und du das nächste Qualitätsproblem angehen willst: Agents, die behaupten, fertig zu sein.

Stufe 6: Plan-First und Compliance-Gate

Das letzte Problem, das auch eine geölte Pipeline noch hat: halluzinierte Fertigstellung. Der Developer meldet „done", aber drei Acceptance Criteria sind verschwunden, und niemand merkt es.

Die Lösung ist ein hartes Gate:

1. Der Planner schreibt einen Plan mit expliziten Acceptance Criteria
2. Im Interactive-Modus bestätigst du den Plan, bevor der Developer loslegt
3. Der Reviewer hat einen Plan-Compliance-Mode: er prüft jedes Criterion einzeln gegen den Diff
4. Bei Abweichung geht der Task zurück zum Developer – maximal zwei Runden, dann eskaliert die Pipeline

Ausblick: Adversarial Agents und Scenario Testing

Die Frontier sieht so aus: konkurrierende Agent-Teams (Builder vs. Bug-Finder), End-to-End-Scenarios statt klassischer Test-Suites, und „Digital Twins" von Drittsystemen für unbegrenztes Testen. StrongDMs Setup ist das prominenteste Beispiel.

Für die meisten Projekte ist das aktuell Overkill. Aber es zeigt die Richtung: Qualitätssicherung wird selbst zu einer Pipeline aus Agents, nicht zu einem manuellen Schritt am Ende.

Wo solltest du anfangen?

Eine ehrliche Empfehlung:

Zusammenfassung