Programmieren ist nicht tot – Teil 3: Multi-Agent ohne Extra-Tool

Multi-Agent-Workflows mit Claude Code oder Codex CLI – das klingt nach etwas, das man installieren muss. Ein Orchestrierungs-Tool, vielleicht eine Plattform, eventuell ein Dashboard. In der Praxis braucht es das nicht.

Weder Claude Code noch Codex setzen voraus, dass ein separates Tool die Agenten koordiniert. Beide Systeme können Code lesen, editieren und Befehle ausführen. Claude Code unterstützt darüber hinaus Subagents und Agent Teams als Muster für delegierte Aufgaben und parallele Workstreams. Codex CLI läuft als lokaler Agent im Terminal, mit interaktiver Steuerung und konfigurierbaren Läufen.

Der entscheidende Punkt ist aber ein anderer: Multi-Agent ist zuerst ein Denk- und Workflow-Modell. Erst dann ein Feature.

Wer das sauber aufzieht, braucht oft kein separates Tool. Gebraucht wird die Bereitschaft, Rollen wirklich zu trennen – und das konsequent durchzuhalten.

Warum ein Agent allein unter Druck gerät

Der häufigste Fehler bei der Arbeit mit Coding Agents ist nicht mangelnde Modellleistung. Es ist, dass ein Agent gleichzeitig zu viele Rollen übernehmen soll: Architekt, Implementierer, Tester, Reviewer und QA in einem.

Bei kleinen Aufgaben funktioniert das. Bei größeren Änderungen kippt es zuverlässig – nicht weil das Modell schlecht ist, sondern weil zu viele konkurrierende Ziele im selben Kontext landen.

Was dann typisch passiert: Der Agent plant schon während der Implementierung um, weil sich im Prozess neue Überlegungen ergeben. Das Review wird weich, weil derselbe Kontext seine eigene Arbeit bewertet. Tests decken vor allem ab, was gerade gebaut wurde – nicht das, was leicht kaputtgehen kann. UI- oder Integrationsprobleme tauchen zu spät auf.

Das ist kein Fehler des Agenten. Es ist ein Strukturproblem. Und Strukturprobleme löst man nicht mit mehr Modellleistung, sondern mit mehr Trennung.

Die Grundstruktur: fünf Phasen

Eine sauber aufgebaute Multi-Agent-Struktur braucht keine exotische Architektur. Die Grundstruktur ist simpel:

Das ist im Kern bereits Multi-Agent. Selbst wenn am Ende technisch dieselbe Engine läuft – es sind getrennte Rollen mit getrennten Aufgaben, getrennten Eingaben und getrennten Erfolgskriterien.

Isolation vor Parallelisierung

Viele denken bei Multi-Agent sofort an mehrere Agenten gleichzeitig. Das ist oft gar nicht der erste Hebel.

Der größere Gewinn kommt aus Isolation:

• Der Planer soll noch nichts bauen.
• Der Reviewer soll nichts fixen.
• Der Tester soll nicht rechtfertigen, warum etwas „eigentlich passt”.
• Die QA soll nicht implementieren, sondern Mängel sichtbar machen.

Das klingt banal. In der Praxis ist es aber der Unterschied zwischen „fühlt sich produktiv an” und „liefert verlässlich bessere Ergebnisse”.

Isolation bedeutet dabei nicht nur getrennte Fenster. Es bedeutet getrennte Ziele, getrennte Eingaben und getrennte Erfolgskriterien.

Was jede Rolle braucht – und was nicht

Ein Reviewer braucht nicht die ganze Welt. Er braucht: Anforderung, Plan, Diff, ggf. Testergebnisse. Mehr ist Rauschen.

Ein Tester braucht: Anforderungen, geänderte Dateien oder Diff, relevante Laufbefehle, klare Testziele. Er braucht nicht die Implementierungsdiskussion, die dazu geführt hat.

Ein Architekt braucht: Problem, Codebasis, Constraints, bestehende Konventionen. Er braucht nicht das spätere Review und auch keine halbfertige Implementierung im Kontext.

Acht Prinzipien für den Aufbau

1. Immer mit einer reinen Planungsphase starten

In Claude Code und Codex ist die Versuchung groß, direkt zu sagen: „Baue Feature X.” Für kleine Dinge ist das okay. Für relevante Änderungen ist es ein Risiko.

Besser: zuerst eine Phase, die nur analysiert und strukturiert.

Analysiere die Änderung, aber implementiere noch nichts.

Ziel:
[Beschreibung]

Liefere:
1. betroffene Dateien
2. technische Vorgehensweise
3. Risiken und Edge Cases
4. notwendige Tests
5. offene Annahmen

Keine Code-Änderungen. Kein Schreiben. Nur Plan.

Warum das stark ist: Der Agent muss zuerst strukturieren. Dadurch wird aus implizitem Denken ein explizites Artefakt – und genau dieses Artefakt wird später an Implementierung, Review und Tests übergeben. Das ist einer der größten Qualitätshebel in der Arbeit mit Coding Agents.

2. Implementierung strikt an den Plan koppeln

Nach der Planungsphase: neue Session oder klarer Phasenwechsel. Nicht einfach weiterschreiben.

Implementiere basierend auf diesem Plan.

Plan:
[Plan einfügen]

Regeln:
- halte dich an bestehende Konventionen
- ändere nur betroffene Bereiche
- dokumentiere Abweichungen vom Plan explizit
- führe relevante Checks und Linter aus

Wichtig ist hier nicht nur „implementieren”, sondern: Scope eng halten, Abweichungen sichtbar machen, Ergebnisse prüfbar machen. Der Coding-Agent soll nicht stillschweigend die Architektur verändern, weil ihm unterwegs etwas besser vorkommt. Wenn sich etwas ändern muss, soll er es benennen.

3. Review immer als eigene Rolle fahren

Einer der häufigsten Fehler: der Coding-Agent soll nach dem Bauen „noch mal kurz reviewen”. Das bringt etwas, aber nicht genug. Besser ist ein eigener Review-Schritt mit anderer Zielsetzung.

Reviewe diese Änderung kritisch.

Input:
- Anforderungen
- Implementierungsplan
- Diff / geänderte Dateien

Prüfe besonders:
- Korrektheit
- Edge Cases
- Security
- Performance
- unnötige Komplexität
- Brüche mit bestehenden Konventionen

Regeln:
- nichts implementieren
- nur Probleme und konkrete Verbesserungsvorschläge liefern
- priorisieren in: kritisch / mittel / gering

Ein Agent, der gerade gebaut hat, neigt dazu, das Gebaute zu verteidigen. Ein Agent, der nur reviewt, schaut viel eher auf unvollständige Fälle, stille Seiteneffekte, unerwünschte Kopplungen und fehlende Absicherung.

4. Tests nicht als Nebenprodukt behandeln

Ohne gesonderte Test-Rolle schreiben Agents oft Tests, die vor allem bestätigen, dass der eigene Code ungefähr das tut, was sie gerade im Kopf hatten. Das ist kein echtes Sicherheitsnetz.

Erstelle eine Teststrategie und dann konkrete Tests.

Input:
- Anforderungen
- Diff
- Implementierungsplan

Ziel:
- nicht nur Happy Paths
- besonders Regressionen, Randfälle und Fehlerszenarien
- vorhandenes Testmuster des Projekts übernehmen
- Lücken in der Testbarkeit benennen

Noch besser: Testen in zwei Teile trennen. Erst Testdesign – welche Risiken müssen überhaupt abgedeckt werden? Dann Testimplementierung – welche konkreten Tests entstehen daraus? Das verhindert, dass Tests bloß „noch schnell dazu” geschrieben werden.

5. Fix-Loops bewusst einbauen

Ein gutes Multi-Agent-Setup ist nicht linear, sondern hat Rückkopplungen. Der wichtigste Loop:

Reviewer / Tester → Coder → erneut prüfen

Praktisch bedeutet das: planen, implementieren, reviewen, gefundene Punkte gezielt fixen, testen, bei Fehlschlag erneut fixen, finaler Review. Das lässt sich auch ohne Spezial-Orchestrierung diszipliniert manuell machen. Der Trick: jeder Loop bekommt nur das relevante Material.

Behebe nur die folgenden Review-Punkte:

[Liste]

Regeln:
- keine zusätzlichen Refactorings
- keine Scope-Erweiterung
- Änderungen kurz begründen
- anschließend relevante Tests ausführen

Das hält den Korrekturschritt klein und reduziert neues Chaos.

6. Für UI-Arbeit immer eine eigene QA-Perspektive vorsehen

Gerade bei Frontend oder Designsystemen reicht Code-Review nicht. Gefragt ist eine Rolle, die fragt: Sieht es in mehreren Breakpoints richtig aus? Ist die Interaktion konsistent? Ist die Semantik sauber? Ist Accessibility mitgedacht? Hat sich visuell etwas verschoben?

Das ist oft der Punkt, an dem aus „funktioniert technisch” ein „taugt wirklich” wird. Eine eigene QA-Phase, in der der Agent nicht mehr baut, sondern anhand von Screenshots, DOM-Inspektion, Accessibility-Befunden oder manuellen Prüfpunkten kontrolliert, ist auch ohne Zusatz-Tool umsetzbar.

7. Übergaben immer schriftlich, kurz und standardisiert machen

Der häufigste Workflow-Fehler ist nicht fehlende Modellleistung – es sind schlechte Handoffs. Jede Rolle sollte ein kleines, standardisiertes Ergebnis liefern:

Output des Planers: Ziel, betroffene Dateien, Umsetzungsidee, Risiken, Tests.

Output des Coders: was geändert wurde, Abweichungen vom Plan, offene Punkte, ausgeführte Checks.

Output des Reviewers: kritische Mängel, mittlere Mängel, kleine Mängel, empfohlene Fixes.

Output des Testers: Teststrategie, hinzugefügte oder angepasste Tests, nicht testbare Risiken, Ergebnis der Testläufe.

Sobald das standardisiert ist, wird der gesamte Ablauf stabiler. Jeder Folgeschritt weiß exakt, was er bekommt.

8. Rollen klein halten, nicht granular werden

Theoretisch lassen sich zwölf Agentenrollen bauen. Das ist selten sinnvoll. Für die meisten Setups reichen vier:

• Planner – Analyse und Plan
• Coder – Implementierung
• Reviewer – kritische Prüfung
• Tester – Absicherung

Optional kommen hinzu: UI/Design QA für visuelles und interaktives Prüfen, Researcher für unbekannte Bibliotheken oder API-Änderungen, Refactorer für gezielte Nacharbeit.

Mehr Rollen erhöhen Koordinationsaufwand, aber nicht automatisch Qualität. Eine neue Rolle ist dann sinnvoll, wenn sie ein anderes Ziel und einen anderen Blickwinkel hat – nicht weil ein weiterer Agent irgendwie attraktiv erscheint.

Parallel nur dort, wo Arbeit wirklich unabhängig ist

Parallelisierung lohnt sich nur, wenn Teilaufgaben wirklich entkoppelt sind: Backend-Änderung und Dokumentation gleichzeitig, mehrere unabhängige Bugfixes, mehrere Teilbereiche in einem großen Refactoring, Research zu drei möglichen Lösungsansätzen.

Nicht gut parallelisierbar sind stark gekoppelte Architekturänderungen, alles, was denselben Kerncode gleichzeitig verändert, und Schritte, die logisch aufeinander aufbauen.

Anthropic beschreibt Agent Teams explizit als geeignet für unabhängige Workstreams, Subagents als fokussierte Teilaufgaben mit Rückgabe einer Zusammenfassung. Das deckt sich gut mit dem hier beschriebenen Modell.

Claude Code und Codex konkret

Claude Code

Für kleine bis mittlere Tasks reicht eine schlichte Phasenstruktur:

• Planungsphase
• Implementierungsphase
• Reviewphase
• Testphase

Das lässt sich mit neuen Sessions oder bewusst getrennten Prompts umsetzen.

Für größere Tasks: Planner als Hauptsession, Subagent für Research oder Teilanalyse, getrennte Session für Review, Agent Teams nur dann, wenn echte unabhängige Stränge existieren.

Anthropic unterscheidet intern zwischen paralleler Arbeit, Subagents und Agent Teams – also zwischen mehreren unabhängigen Aufgaben, fokussierten delegierten Teilaufgaben und koordinierten Multi-Agent-Workstreams. Dieses Modell passt sehr gut zum hier beschriebenen Ansatz: Subagents für eng abgegrenzte Hilfsaufgaben, separate Review- und Test-Sessions für echte Kontrolle, Agent Teams nur bei größeren, klar teilbaren Arbeiten.

Codex CLI

Codex ist als lokaler Coding-Agent im Terminal ausgelegt – Agent Mode, interaktive TUI, Slash-Commands, Konfiguration über CLI und Config-Dateien. Das reicht, um sehr diszipliniert in Phasen zu arbeiten.

Empfehlenswerter Ansatz: eine Session nur für Analyse, eine für Implementierung, eine für Review, eine für Tests. Hier ist weniger wichtig, ob etwas offiziell „Subagent” heißt. Wichtiger ist, dass nicht alles in einem Lauf vermischt wird.

Für Codex ist deshalb oft der praktisch beste Weg: mehrere kleine, klar definierte Läufe, Diff-basierte Übergaben, Review und Tests als unabhängige Nachläufe.

Standard-Workflow auf einen Blick

Die häufigsten Fehler

Alles in einer Session machen. Dann verwischen Rollen, und der Agent bleibt in einer Denkweise hängen.

Reviewer darf sofort fixen. Dann wird aus Review wieder Implementierung. Die Trennung ist aufgehoben, bevor sie Wirkung entfaltet.

Tester bekommt zu viel Kontext. Dann prüft er implizit die Denkweise des Coders statt die Anforderungen.

Keine expliziten Handoffs. Dann hängt alles an unsauberem Gesprächskontext, der sich von Phase zu Phase verschiebt.

Parallelisierung zu früh. Dann steigt Chaos schneller als Produktivität.

Tests nur am Ende schnell nachziehen. Dann sichern sie das Gebaute ab – nicht das Risiko.

Was das in der Praxis bedeutet

Der reife Multi-Agent-Ansatz ohne Zusatztools lautet nicht: „Nimm möglichst viele Agenten.” Er lautet:

Trenne Denken, Bauen, Prüfen und Absichern konsequent voneinander.

Genau dann entsteht der Effekt, den viele mit „Multi-Agent” meinen: weniger Betriebsblindheit, stabilere Qualität, bessere Tests, weniger Scope-Drift, nachvollziehbarere Entscheidungen.

Das geht heute mit Codex und Claude Code sehr gut – auch ohne eigenes Orchestrierungs-Tool. Bei Claude Code etwas direkter durch Subagents und Agent-Patterns, bei Codex eher als sauber strukturierter Mehrphasen-Workflow im Terminal. Der Unterschied ist klein. Das Prinzip ist dasselbe.