Claude Code als reine Bewertungs-Engine über den gesamten SDLC ausführen

Ein Entwickler auf r/ClaudeAI beschrieb sein monatelang optimiertes Setup mit Claude Code (der Laufzeitumgebung mit Tool-Nutzung und Multi-Turn-Schleife) über den gesamten Softwareentwicklungslebenszyklus Tickets, Cross-Repo-Implementierung, Code-Review, Merge-Requests und einer persistenten Wissensebene.

Wichtige Architekturentscheidung: Claude Code nicht in die Orchestrierung einzubeziehen. Reines Python übernimmt alle mechanischen Arbeiten: Jira-API-Aufrufe, Git-Operationen, Testläufe, Linting, Dateiverschiebungen. Claude Code wird nur für Urteilsfindungen herangezogen Code schreiben, Review-Ergebnisse bewerten, zwischen Architekturmöglichkeiten wählen. Der Autor fand heraus, dass die Vermischung beider Aufgaben (den Agenten über Tool-Nutzung orchestrieren zu lassen) die erste Version langsam, teuer und nicht deterministisch machte.

Konkreter Lebenszyklus eines Tickets:

• Python Orchestrator: Ruft das Jira-Ticket ab, durchsucht das lokale Wiki nach verwandten Architekturentscheidungen, richtet einen Worktree auf einem neuen Branch ein, erstellt ein 30–50-zeiliges Implementierungs-Briefing (Abnahmekriterien, Zieldateien, Aufrufer modifizierter gemeinsamer Funktionen, relevante Standards). Ausgabe: ein JSON-Bundle.
• Claude Code: Liest das Briefing und schreibt den Code. Dies ist der einzige Schritt mit signifikantem Token-Verbrauch.
• Python + Review-Subagent: Führt Tests, Linting, Formatierung durch. Bei Fehlschlag wird an den Implementierungsagenten zurückgegeben (max. 3 Wiederholungen). Dann wird ein Code-Review-Subagent gestartet, der keine Bearbeitungs- oder Schreibberechtigung hat er kann nur lesen und Ergebnisse melden.
• Python: Erstellt einen Vorschlag in einem Dashboard. Nach manueller Genehmigung pusht der Orchestrator und erstellt den Merge-Request.

Spezifische Claude-Code-Techniken, die wichtig waren:

• Subagenten-Isolation. Der Review-Agent läuft in seinem eigenen Kontextfenster mit einer Deny-Liste (Bearbeiten, Schreiben). Die Trennung von Review und Implementierung deckte Verhaltensänderungen in gemeinsam genutztem Code auf, die der Implementierungsagent ständig übersah.
• Vorgefertigte Briefings schlagen dynamische Erkundung. Früher ließ man Claude Code die Codebasis vor der Implementierung erkunden, was deutlich mehr Token verbrauchte als ein fokussiertes Briefing, das von Python zusammengestellt wurde (Jira-Fetch, Wiki-Suche, Abhängigkeitsanalyse).
• Skill/Befehlsrouting über YAML anstatt der Agentenentscheidung. Die Zuordnung von /ticket, /review, /standup etc. zu Orchestratoren ist explizit, sodass Fähigkeiten überprüfbar statt emergent sind.
• Hooks steuern Commits. Ein Pre-Commit-Hook führt Linting und Formatierung vor jedem commit durch, den Claude Code versucht. Verstöße blockieren den Commit; der Agent muss sie beheben.

Wiki-Ebene: Markdown-Seiten mit drei Vertrauensstufen (verifiziert, abgeleitet, von Menschen bereitgestellt) und feldbezogenen Veralterungsschwellen. Ohne die Abstufung behandeln Agenten ihre eigenen früheren Ableitungen als Wahrheit und addieren Halluzinationen zu autoritär wirkendem Wissen.

Herausforderungen, die noch gelöst werden müssen:

• Cross-Repo-Funktionen: Der Agent verliert die Kohärenz, wenn eine Funktion mehrere Dienste umfasst, selbst mit strukturierter Change-Set-Verfolgung.
• Vage Tickets: Der Agent liefert vernünftige, aber oft falsche Implementierungen aus mehrdeutigen Spezifikationen. Der Autor markiert mehrdeutige Tickets nun als Blockierer.
• Scope Creep: Überengineering-Instinkt erfordert ständige Kalibrierung durch Standards und den Review-Agenten.
• Lange Sitzungen: Früherer Kontext fällt aus der effektiven Aufmerksamkeit; die Reinitialisierung zu Sitzungsbeginn mildert das Problem, beseitigt es aber nicht.