Du gibst Claude eine Aufgabe. Er liefert. Die Antwort liest sich aufgeräumt, kommt mit Erklärung, ein paar Bullet Points, am Ende ein freundliches “let me know if you need anything else”. Wahrscheinlich ist die Lösung sogar OK. Aber ob sie wirklich gut ist, wirst du so nicht erfahren. Dein Agent wird dir selten ins Gesicht sagen: “Ehrlich gesagt, der Code hier ist Mittelmaß.”
Das hat einen Namen. Sharma et al. (Anthropic, Oktober 2023) haben die Eigenschaft “Sycophancy” genannt und über alle großen Sprachmodelle hinweg nachgewiesen. Die Modelle ziehen ihre Antwort dorthin, wo der Prompt sie haben will. Fragst du “ist X richtig?”, finden sie Argumente für X. Fragst du “ist X falsch?”, finden sie Argumente dagegen. Im selben Lauf, mit demselben Faktum.
Der Entwickler sysls hat angefangen, genau das auszunutzen. Er gibt mehreren Agenten widersprüchliche Aufträge im gleichen Workflow: der eine baut etwas auf, der zweite reißt es kritisch auseinander, ein dritter wiegt beide Seiten ab und entscheidet. Jeder spielt seine Rolle mit voller Überzeugung, weil das Modell dem Framing folgt. Sagst du einem Agenten “der Code unten ist Müll, finde mir alle Probleme”, legt das gleiche Modell, das gerade noch stolz auf seinen Code war, mit echter Begeisterung los.
Drei Muster, die funktionieren
Drei Setups habe ich in den letzten Monaten häufig gesehen. Sie unterscheiden sich in der Topologie, das Grundprinzip ist dasselbe.
Die Triade: Generator, Kritiker, Schiedsrichter
Das einfachste Setup. Drei Agenten, klar verteilte Rollen. Einer baut. Einer greift an. Einer urteilt.
Der Generator schreibt Code oder eine Lösung. Der Adversary sucht gezielt nach Schwächen, Race Conditions, vergessenen Fehlerpfaden, falschen Annahmen. Der Referee bekommt beide Seiten vorgelegt und entscheidet. Niemand hält alle drei Rollen zugleich. Genau diese Trennung kippt das Ergebnis.
Wichtig ist der Prompt für den Adversary. Generische Kritik (“achte auf Qualität”) führt zu generischer Kritik. Konkret formuliert sieht das so aus:
Hier ist Code von einem anderen Agenten. Er behauptet, Problem X zu lösen.
Deine Aufgabe: Finde die Stellen, an denen dieser Code unter realen
Bedingungen bricht. Race Conditions, Edge Cases, falsche Annahmen,
vergessene Fehlerpfade, Sicherheitslücken.
Sei spezifisch: Zeile und konkretes Szenario. Keine pauschalen Bewertungen.Je härter der Adversary-Prompt formuliert ist, desto mehr findet er. Das ist die Sycophancy, die jetzt für dich arbeitet.
Der Kreislauf: Schreiben, Kritisieren, Überarbeiten
Zwei Agenten in einer Schleife. Einer schreibt, der andere zerlegt das Ergebnis. Dann geht es zurück zum ersten, der überarbeitet. Mit jeder Runde wird die Lösung weiter abgeschliffen.
In den Setups, die ich gesehen habe, pendelt sich die Qualität nach drei bis vier Runden auf einem stabilen Niveau ein. Ab der fünften Runde kommen meist nur noch kosmetische Änderungen. Das ist konsistent mit den Beobachtungen aus dem Self-Refine-Paper (Madaan et al., 2023), das genau dieses Muster über mehrere Aufgaben getestet hat.
Token-Verbrauch steigt linear mit der Rundenzahl. Für eine schnelle Antwort auf eine simple Frage ist das Overkill. Für Aufgaben, bei denen ein Fehler teuer wird (Migrationen, Auth-Logik, Geldströme, Datenmodellierung), zahlt sich der Loop schnell aus.
Red Team gegen Blue Team
Das Muster kommt aus der IT-Sicherheit. Ein “Red Team” simuliert gezielte Angriffe: Prompt Injection, manipulierte Eingaben, Randfälle, die der Verteidiger nicht erwartet. Ein “Blue Team” lernt aus den Angriffen und baut Verteidigung. Beide Seiten ziehen sich gegenseitig nach oben.
Anthropic nutzt ein verwandtes Prinzip in Constitutional AI. Ein Modell prüft seine eigenen Antworten gegen eine Sammlung von Prinzipien und überschreibt sie, wenn sie verletzt werden. Im Kern ist das ein Red-Blue-Loop mit nur einem Modell, das die Rollen wechselt.
Für Code-Qualität funktioniert die Methode genauso. Der Red-Agent schreibt absichtlich kaputte Inputs, der Blue-Agent härtet die Implementierung. Nach ein paar Runden hast du eine Testsuite, an die du selbst nie gedacht hättest, weil du dein eigenes System zu gut kennst, um es feindlich zu sehen.
Was das in der Praxis bedeutet
Mehr Agenten kosten mehr Rechenzeit. Drei statt einem, vier Durchläufe statt einem Versuch. Token-Verbrauch steigt entsprechend. Das ist real.
Aber die Rechnung kippt, sobald du den nachgelagerten Aufwand mitzählst. Ein einzelner Agent produziert Code, den du anschließend selbst nach Fehlern absuchen darfst. Ein Triade-Setup hat das schon in den Prompt gezogen. Die Stunden, die du in Code-Review, manuelles Debugging und nachgelagerte Hotfixes nicht reinsteckst, sind oft teurer als die zusätzlichen Tokens.
Zwei Dinge bleiben wichtig. Ohne klare Leitplanken produziert auch ein Multi-Agent-Setup mehr Chaos als Qualität. Wer die Rollen unscharf hält, bekommt drei Agenten, die alle ein bisschen zustimmen, sich höflich gegenseitig korrigieren und am Ende auf “sieht gut aus” einschwenken. Das ist dann teurer als der Single-Agent-Lauf und genauso flach.
Und die finale Entscheidung, ob ein Ergebnis taugt, fällt am Schreibtisch eines Menschen. Agenten können sich gegenseitig herausfordern. Sie können Schwächen freilegen, die einem einzelnen Modell entgehen würden. Was sie nicht können: die Verantwortung tragen. Die liegt bei dir, wenn der Code in Produktion läuft.
Die belastbarsten Ergebnisse habe ich dort gesehen, wo Agenten sich offen widersprechen. Wo einer baut, reißt der andere auseinander. Und niemand nickt höflich. Genau dort fühlt sich das System an wie ein gutes Pair-Programming-Gespräch, bei dem beide Seiten verstanden haben, dass Höflichkeit hier keine Tugend ist.