Antagonistische KI für bessere Ergebnisse

Wer mit LLMs arbeitet, erreicht bei kleinen, fokussierten Aufgaben häufig gute Ergebnisse. Sobald Aufgaben größer werden, mehrere unterschiedliche Aspekte ineinandergreifen oder ganze Abläufe entstehen, werden die Resultate oft deutlich wackeliger. Kleine Änderungen im Prompt erzeugen plötzlich andere Ergebnisse. Manche Aufgaben funktionieren hervorragend, andere scheitern unerwartet. Und irgendwann taucht eine bekannte Entwicklererfahrung auf: Struktur und Zerlegung helfen auch hier.

Auch wenn „Ende 2024“ in der KI-Zeitrechnung inzwischen ungefähr Bronzezeit ist, erklärt Anthropics Artikel Building effective agents zum Thema „Dekomposition“ von Aufgaben immer noch gut, wie Entwickler durch geschickte Trennung und Orchestrierung von Teilaufgaben stabilere Ergebnisse erreichen können.

Die Kernaussage ist schlicht: Zerlege Aufgaben. Baue einfache, zusammensetzbare Workflows. Fange nicht mit einem autonomen Mega-Agenten an, wenn drei klare Schritte reichen.

Diese Logik zieht sich bis in aktuelle Agenten-Werkzeuge und Skills. Und es ist egal ob man es Orchestration, Handoff, Evaluator, Review-Skill oder Workflow nennt: Die Möglichkeiten der Strukturierung sind genauso vielfältig wie in klassischem Code.

Das klingt für Entwickler auch erst einmal vertraut. Dekomposition ist unser täglich Brot. Wir zerlegen Systeme in Module, Funktionen, Tests, Services, Schnittstellen und Verantwortlichkeiten. Allerdings sind das in Code ziemlich klar umrissene Einheiten, gut strukturiert und logisch klar abgegrenzt. Natürliche Sprache ist da deutlich weicher. Sprache ist nicht Code. Prompts haben keine Typprüfung. Entsprechend anders fühlt sich “Dekomposition” mit diesen neuen Werkzeugen an.

Die spannende praktische Frage verbleibt so beim jeweiligen Entwickler: unabhängig von irgendwelchen theoretischen Betrachtungen der großen KI-Provider: welche konkrete Struktur kann mir denn bei meiner gegebenen Aufgabe die Ergebnisse wirklich sinnvoll verbessern?

Antagonistische KI

Das Feld ist gerade erst im Aufbruch und von daher hilft jeder Erfahrungsaustausch. Persönlich neige ich am Stärksten zu der Variante, die im Artikel von Anthropic “Evaluator-optimizer” heißt. Bei vielen Aufgaben hilft mir dieses Muster, bei dem das bisherige Ergebnis einem sinnvollen Gegenspieler ausgesetzt wird - “antagonistische KI”

Es geht nicht um einem Gegner im dramatischen Sinn. Eher einer Instanz, die eine andere Aufgabe hat und deshalb andere Dinge sieht. Ein Test fragt nicht, ob der Code elegant ist. Er fragt, ob ein Verhalten eintritt.

In diesem Sinn meine ich “antagonistische KI”: nicht mehrere Persönlichkeiten, sondern bewusst gegeneinander gesetzte Arbeitsmodi.

TDD war schon immer ein kleiner Gegenspieler

Programmierer kennen dieses Prinzip gut: Testgetriebene Entwicklung ist im Kern ein antagonistisch zerlegter Workflow.

Erst fragt man:

Was soll der Code fachlich leisten?

Dann fragt man:

Wie baue ich Code, der genau dieses Verhalten erfüllt?

Der Test ist kein freundlicher Schreibassistent. Er ist ein enges Korsett. Rot oder grün. Passt oder passt nicht. Natürlich ist die Welt in der Praxis nie ganz so sauber. Tests können falsch sein, zu eng, zu breit, implementierungsnah oder schlicht albern. Aber sie verändern die Arbeit, weil sie einen zweiten Modus erzwingen: Verhalten vor Implementierung.

Mit LLMs wird das schwieriger, weil viele Aufgaben nicht so klar binär sind. Ein Text ist nicht grün. Eine Architekturentscheidung hat selten eine einzige korrekte Lösung. Ein Frontend kann technisch funktionieren und trotzdem visuell so aussehen, als würde es einen beleidigen.

Bei Aufgaben, die ich häufig wiederhole und bei denen mir das Ergebnis qualitativ noch nicht reicht oder der Prozess zu fragil erscheint, ist diese Strategie für mich nützlich: Suche nach einem Gegenspieler, der eine andere Art von Wahrheit in den Prozess bringt.

Bei Code können das Tests sein. Bei Architektur können es Betriebsannahmen sein. Bei Texten kann es die Leserfrage sein: “Warum sollte mich das interessieren?”

Ein Beispiel: Patch Comparator

Bei größeren Code-Aufgaben nutze ich z.B. gern einen Patch-Vergleich oder “Comparator”. Das Muster ist einfach:

1. Ich lasse mir für dieselbe fachliche Aufgabe drei verschiedene Code-Varianten erzeugen.
2. Ich gebe diese Varianten an ein anderes GPT oder an denselben Modelltyp in einem klar getrennten Vergleichsmodus.
3. Der Comparator soll nicht mehr implementieren. Er soll einen Patch auswählen, die Wahl begründen, den Patch dann aber auch klar kritisieren und konkrete Code-Verbesserungen vorschlagen.

Das ist nicht magisch. Wenn mein Ausgangsprompt fachlich schlecht ist, laufen im Zweifel alle drei Patches elegant in die falsche Richtung. Wenn der Comparator oberflächlich urteilt, gewinnt vielleicht die Variante mit der schöneren Erklärung statt der besseren Architektur. Und wenn ich selbst nicht mehr hinschaue, habe ich die Verantwortung möglicherweise an ein sehr selbstbewusstes Textsystem ausgelagert.

Aber bei bewusstem Einsatz ist das Muster für mich oft erstaunlich nützlich.

Der Comparator sieht nicht nur eine Lösung. Er sieht Alternativen. Dadurch verschiebt sich seine Aufgabe. Er muss nicht fragen: “Wie baue ich den Code als gute fachliche Lösung?” Er fragt: “Welche Variante trägt am besten, was sind die Variationsmöglichkeiten, welche Kompromisse sehe ich, und was hat der eine Patch, was dem anderen noch fehlt?”

Und das liefert mir bei großen Coding-Aufgaben oder Umbauten erstaunlich gute Qualität.

Screenshots sind eine wirklich andere “Sichtweise”

Noch deutlicher wird das für mich bei Frontend-Arbeit.

Ein Modell, das gerade HTML und CSS geschrieben hat, denkt eben in HTML und CSS. Es sieht Klassen, Grids, Breakpoints, Container und Margins. Das ist nützlich. Aber es ist ein fundamental anderer Modus als “sehen”.

Der Screenshot als Gegenspieler ist dabei ein ganz anderer Beobachtungsraum.

Plötzlich geht es nicht mehr um die Frage, ob align-items syntaktisch korrekt ist. Es geht darum, ob die Sprachwahl optisch an der falschen Kante klebt. Ob das Bild zu schwer wirkt. Ob der Abstand zufällig aussieht. Ob die Hierarchie stimmt. Ob etwas mobil einfach bricht.

Und in meiner Erfahrung sind LLMs mittlerweile auch bei der Beurteilung visueller Konsistenz in solchen Screenshots gar nicht mehr so schlecht und damit als Gegenspieler bei der Website-Entwicklung sehr hilfreich. Im ersten Schritt arbeitet die KI am Code und erzeugt ein darstellbares Ergebnis ohne technische Fehler. Danach bekommt sie einen Screenshot und wechselt in den Modus des Gegenspielers. Die visuelle Inspektion liefert ganz andere Ergebnisse in Sachen Alignment, Abständen und visueller Konsistenz. Sie liefert damit einen anderen Blickwinkel auf Optimierungen als die technische Code-Sicht allein.

Im Ergebnis ist das bei der Frontend-Entwicklung ein für mich sehr geliebtes antagonistisches Muster, zumal ich so nur noch selten CSS-Pixel “schubsen” muss. Das war noch nie meine Lieblingsbeschäftigung.

Die Kunst liegt im passenden Gegenspieler

Je mehr ich mit LLMs arbeite, desto häufiger frage ich mich jetzt:

Was könnte hier ein guter Antagonist, ein Gegenspieler sein, der mir das Ergebnis dieser Aufgabe verbessert?

Für Code kann das ein Testautor sein, der nur Verhalten spezifiziert. Oder ein Reviewer, der nur Risiken sucht. Oder ein Security-Check, der explizit auf Exploits achtet.

Für Texte kann das ein Redakteur sein, der die These schärft. Oder ein skeptischer Leser, der fragt, wo der Text prahlt, statt zu erklären. Oder ein Quellenprüfer, der trennt, was Erfahrung, Plausibilität und belegbare Aussage ist.

Für Frontend kann das ein Screenshot-Review sein. Für Datenpipelines ein Lauf mit echten Fehlfällen. Für Produktentscheidungen vielleicht ein Kostenmodell oder eine Support-Perspektive.

In der Praxis kann das durchaus der Unterschied zwischen “ich benutze KI” und “ich baue mir einen brauchbaren Arbeitsprozess, der mir saubere Ergebnisse liefert” sein.

Der Mensch bleibt der Orchestrator

Antagonistische Muster machen KI-Arbeit nicht automatisch wahr. Ein Comparator kann falsch liegen. Ein Reviewer kann Nebensächlichkeiten aufblähen. Ein Screenshot kann Probleme sichtbar machen und trotzdem die falsche Priorität nahelegen. Drei Varianten können schlechter sein als eine sorgfältig geführte.

Aber solche Muster machen Entscheidungen besser diskutierbar.

Ich sehe mehr Alternativen. Ich sehe mehr Schwachstellen und mehr Perspektiven. Und so kann ich als Mensch genauer entscheiden, welchem Vorschlag ich folge und welchem nicht.

Das ist für mich der eigentliche Nutzen: nicht Intelligenz aus einem einzigen Prompt herauspressen, sondern Arbeit so strukturieren, dass Erzeugung, Kritik und Verifikation getrennte Aufgaben bekommen und die menschliche Entscheidung besser und einfacher machen.