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. Sagst du einem Agenten “der Code unten ist Müll, finde mir alle Probleme”, legt dasselbe 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 den Schwächen, die der Generator übersehen hat. 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.
Zwei Setups, die du heute bauen kannst
Die drei Muster sind die Topologie. Wie sieht das aus, wenn du es selbst aufsetzt? Zwei Setups lohnt es sich, fast eins zu eins zu übernehmen.
Der Council: fünf Perspektiven für teure Entscheidungen
Manche Fragen haben echte Konsequenzen. Welches Produktformat. Welcher Preis. Eine neue Person einstellen oder den Workflow automatisieren. Die Architekturentscheidung, die du in sechs Monaten nicht billig zurückdrehst. Ein einzelnes Modell gibt dir darauf eine glatte Antwort, und glatt ist hier das Problem.
Ole Lehmann ruft für solche Fragen einen Council auf. Fünf Berater, jeder mit einer Haltung, die den anderen ins Gehege kommt:
- Contrarian. Nimmt an, deine Idee hat einen fatalen Fehler, und sucht ihn, bis er ihn findet.
- First Principles Thinker. Wirft dein Framing weg und baut das Problem von unten neu auf. Was löst du hier eigentlich?
- Expansionist. Sucht das Upside nebenan und fragt, ob du nicht zu klein denkst.
- Outsider. Kennt dich nicht, kennt deine Branche nicht, prüft nur, ob die Value Prop für einen Fremden trägt.
- Executor. Will nur eins wissen: die konkrete Aktion, die du Montagmorgen ausführst.
Der Trick steckt im Ablauf. Die fünf antworten parallel, blind füreinander. Dann werden ihre Antworten anonymisiert, A bis E, Namen weg. Fünf Reviewer lesen alle fünf und beantworten drei Fragen: Welche Antwort trägt am weitesten? Welche hat den größten blinden Fleck? Was haben alle übersehen? Erst danach liest ein Chairman das Ganze und fällt ein Urteil.
council this: [dein Kontext, so ausführlich wie möglich]
5 Advisors → antworten parallel, blind füreinander
anonymisieren → Antworten A bis E, Namen versteckt
5 Reviewer → stärkste Antwort? größter blinder Fleck?
was haben alle fünf übersehen?
Chairman → ein Urteil, die Risiken beim Ignorieren,
genau eine nächste AktionDie Anonymisierung ist wichtiger, als sie aussieht. Wüssten die Reviewer, dass Antwort C vom Contrarian stammt, würden sie sie als “die negative” abhaken. Ohne Label müssen sie das Argument selbst wiegen.
Über die Schärfe entscheidet der Advisor-Prompt. Generisch formuliert bekommst du fünf höfliche Varianten derselben Meinung. Der Contrarian zum Beispiel:
Du bist der Contrarian. Geh davon aus, dass diese Idee scheitert.
Finde den einen Grund, an dem sie zerbricht: das übersehene Risiko,
die Annahme, die nicht hält, den Moment, in dem die Realität
zurückschlägt. Sei gnadenlos, sei konkret.
Eine Schwäche, präzise benannt, schlägt fünf vage Bedenken.Was der Council mit dir macht, ist fast wichtiger als das Urteil. Die glatte Single-Agent-Antwort fühlt sich gut an, weil sie deinem Framing folgt. Fünf Berater, die sich gegenseitig widersprechen, nehmen dir das gute Gefühl. Bei einer teuren Entscheidung willst du genau das.
Die Pipeline: ein Feature über Nacht
Zodchi hat dasselbe Prinzip auf Code übertragen. Statt einem Agenten, der ein Feature in einem Rutsch baut, schieben vier Spezialisten es durch eine Kette: Spec, Implementierung, Tests, Review. Am Morgen liegt ein Branch da, plus ein Review-Report. Du entscheidest, ob er rausgeht.
Im Repo sieht das so aus:
.claude/
agents/
planner.md # Opus, plant, schreibt nur die Spec
coder.md # Sonnet, implementiert exakt die Spec
tester.md # Sonnet, schreibt Tests und führt sie aus
reviewer.md # Opus, read-only, misstrauisch
commands/
ship.md # orchestriert die vier
.pipeline/
spec.md # Planner schreibt, alle anderen lesen
changes.md # Coder dokumentiert, was er angefasst hat
test-results.md # Tester legt das Ergebnis ab
review.md # Reviewer fällt das UrteilJeder Agent kennt nur seine Rolle und seine Files. Der Planner liest den relevanten Code und schreibt eine präzise Spec: betroffene Files, Signaturen, Edge Cases, Patterns. Was unklar bleibt, landet ganz oben als OPEN QUESTIONS. Der Coder liest nur die Spec und implementiert genau das, ohne kreativ zu werden. Der Tester deckt Happy Path, jeden benannten Edge Case und mindestens einen Failure ab, führt die Tests aus und stoppt, sobald etwas rot ist.
Der Reviewer ist der interessanteste. Er bekommt alles und vertraut nichts:
Du bist Reviewer. Read-only. Du vertraust niemandem.
Lies spec.md, changes.md, test-results.md und mach `git diff`.
Bewerte gegen die Spec, nicht gegen die Tests: grüne Tests können
das Falsche prüfen.
Schreib dein Urteil nach review.md, SHIP / NEEDS WORK / BLOCK,
plus die konkreten Stellen, die ein Mensch anfassen muss.Der Command verdrahtet die vier und bricht ab, sobald es hakt:
/ship <feature-beschreibung>
planner → spec.md stopp, wenn OPEN QUESTIONS oben stehen
coder → changes.md
tester → test-results.md stopp bei rotem Test, mit Log
reviewer → review.md zeig mir das UrteilDen Widerspruch trägt hier die Struktur selbst. Planner und Reviewer prompst du bewusst paranoid, auf Security, Datenintegrität, Performance. Den Coder hältst du klein, er folgt der Spec und erfindet nichts dazu. Der Tester misstraut den glatten Fällen und schreibt absichtlich die Tests, die wehtun. Vier Agenten kontrollieren sich gegenseitig, obwohl keiner das ganze Bild sieht.
Verdrahten musst du das nicht mehr von Hand. Seit Anthropic Dynamic Workflows in Claude Code ausgeliefert hat, schreibt Claude die Orchestrierung selbst. Aus einer Beschreibung in natürlicher Sprache entsteht ein Skript, das zig bis hunderte Sub-Agenten in einer Session koordiniert und sich strikt an die Reihenfolge hält. Cat Wu zeigt, wie du sogar vorschreiben kannst, wo der Widerspruch hingehört: “Phase 2, zwei Agenten implementieren denselben Code unabhängig. Phase 3, ein Reviewer vergleicht beide.” Die Widersprüche sind dann Teil des Plans.
Das eigentlich Bemerkenswerte: Die adversariale Prüfung steckt im Mechanismus selbst. Eine Gruppe Agenten geht ein Problem aus unabhängigen Winkeln an, eine andere versucht gezielt, ihre Ergebnisse zu widerlegen, und der Lauf iteriert, bis die Antworten konvergieren. Das Muster aus dem Kreislauf weiter oben, jetzt unter der Haube, statt von Hand zusammengesteckt.
Wie weit das trägt, zeigt der Umbau von Bun. Jarred Sumner hat die JavaScript-Runtime von Zig nach Rust portiert, 750.000 Zeilen in elf Tagen. Parallele Agenten schrieben hunderte .rs-Files, und über jede einzelne Datei liefen zwei Reviewer. Adversariales Review als Fließband, über eine komplette Sprachmigration.
Was das in der Praxis bedeutet
Mehr Agenten kosten mehr Rechenzeit. Drei statt einem, vier Durchläufe statt einem Versuch. Token-Verbrauch steigt entsprechend. Ein Workflow mit hundert Sub-Agenten, jeder ein paar tausend Tokens, landet schnell bei einer halben Million Tokens pro Lauf. 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.
Der teuerste Posten taucht in keiner Token-Rechnung auf. Councils, Pipelines, Dynamic Workflows: technisch startest du heute zig bis hunderte Sub-Agenten in einer Session, bis zu tausend pro Lauf. Und genau da schnappt die Falle zu. Addy Osmani fasst es in ein Bild aus der Programmierung: In einem System voller paralleler Agenten bist du das GIL, der Global Interpreter Lock. Egal wie viele Threads laufen, am Ende muss alles durch deinen Kopf, und der arbeitet seriell.
Daraus folgt eine Obergrenze, die mit Rechenzeit nichts zu tun hat. Wie viele Agent-Ergebnisse prüfst du an einem Tag wirklich gründlich? Vier? Sechs? Das ist deine Zahl. Eine Pipeline, deren Review du überspringst, ist schlechter als gar kein Agent, weil sie dir eine Sicherheit vorspielt, die du nicht hast.
Also miss die Flotte an deiner Review-Kapazität. Sechs Pipelines, die du gründlich liest, schlagen zwanzig, die du überfliegst. Isolierbares wie Docs, Logs oder kleine Migrationen laufen halb-autonom, du schaust am Ende auf wenige Artefakte. Die tiefen Architektur- und Produktfragen gehören in einen Council oder zu einem einzelnen Sparringspartner, in deine besten Stunden. Lass dir testbare Artefakte hinlegen, Diffs, Tests, Specs, und block feste Review-Zeit, statt zwischen Threads zu springen. Dein Lock ist zu wertvoll für Arbeit, die eine Maschine prüfen kann.
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.