13 Agenten schließen den Kreislauf aus Tests und Fixes

So funktioniert der Kreislauf mit 13 Agenten

Bemerkenswert ist vor allem die Mechanik: 13 parallele Codex- und Claude-Abonnements werden als Pool spezialisierter Agenten eingesetzt. Einige führen Tests aus und erstellen Fehlerberichte, andere bereiten automatisch Korrekturen vor. Zum Zeitpunkt der Diskussion wurden die Gesamtkosten mit 100 bis 200 US-Dollar angegeben.

Die Stärke dieses Modells liegt nicht in der Zahl der Abonnements, sondern in der Rollentrennung. Ein Testagent beschreibt einen reproduzierbaren Defekt, der korrigierende Agent erhält eine klar begrenzte Aufgabe, und das Ergebnis muss anschließend erneut geprüft werden. So entsteht ein geschlossener Kreislauf statt einer Gruppe von Modellen, die gleichzeitig dasselbe Repository bearbeiten.

Microsoft liefert für diesen Ansatz einen formalen Rahmen mit seiner Referenzarchitektur für Multi-Agenten-Systeme und der Dokumentation zu Multi-Agenten-Mustern. Im Mittelpunkt stehen Orchestrierung, Governance und Nachrichtenaustausch zwischen spezialisierten Agenten, einschließlich A2A für plattformübergreifende Interaktion. Das ist bereits die Sprache einer Produktionsarchitektur und nicht nur die Beschreibung einer eindrucksvollen Demo.

Auch die Idee autonomer Reparatur wurde strenger geprüft. In einer Google-Studie wurde ein agentischer Ansatz an 178 Fehlern aus einem internen Ticketsystem bewertet. Mit 20 Trajektorien und Gemini 1.5 Pro erzeugte Passerine plausible Patches für 73 % maschinell erstellter Berichte und 25,6 % menschlich verfasster Berichte. Ein plausibler Patch ist selbstverständlich noch kein sicherer Merge.

Ich würde zuerst vier Grenzen prüfen:

• die Isolation von Arbeitskopien und Umgebungen;
• den Schutz vor widersprüchlichen Patches;
• die Unabhängigkeit des Testagenten vom Autor einer Korrektur;
• Abbruchbedingungen für eine endlose Schleife aus Tests und Änderungen.

Was sich in der Entwicklung tatsächlich verändert

Der praktische Wandel ist real: Agenten beginnen, Engineering-Arbeit nach Rollen aufzuteilen, statt nur abwechselnd in einem Chat zu antworten. Dadurch lassen sich Defekte suchen, Patches vorbereiten und Änderungen parallel validieren, besonders wenn Aufgaben gut isoliert sind und ausführbare Tests besitzen.

Ein einzelner Kundenfall beweist jedoch keine breite Einführung in Unternehmen. Die Unterlagen von Microsoft und Salesforce zeigen, dass Multi-Agenten-Architekturen bereits für Unternehmenssysteme formalisiert werden. SWE-bench, RepairBench und DevAgentBench bieten zugleich Möglichkeiten, Code-Reparatur, Testgenerierung und Reviews zu messen. Zwischen einem Architekturmuster und einer zuverlässigen autonomen Pipeline liegt weiterhin die Qualitätssicherung.

Das größte Risiko ist dabei ironisch: Die Patch-Erzeugung zu beschleunigen ist leichter, als zu beweisen, dass Agenten nicht gelernt haben, ihre eigenen Fehler gegenseitig zu bestätigen. Echte Autonomie beginnt erst, wenn unabhängige Prüfung mit der Geschwindigkeit dieses Kreislaufs Schritt halten kann.

Wir haben zuvor erläutert, wie parallele Claude-Code-Agenten Pull Requests prüfen und Race Conditions aufdecken können, bevor sie die CI/CD-Pipeline erreichen. Dieser Ansatz ergänzt Multi-Agenten-Workflows für Tests und Fehlerbehebung, die Entwicklungsaufgaben auf spezialisierte LLM-Agenten verteilen.