Kategorie: Tool-Tests

Du beauftragst einen KI-Assistenten mit einer Due-Diligence-Prüfung bei einer Übernahme. Du bekommst eine Antwort. Ist sie wirklich gut? Hat die KI alle relevanten Klauseln erkannt, die richtigen Schlüsse gezogen? Die Entwickler von Legora haben einen Benchmark entwickelt, der unter Bedingungen stattfindet, die ein Anwalt jeden Tag erlebt. Der Name: Legora Benchmark for Agentic Reasoning – kurz Legora BAR.

Juristische Arbeit ist kein Multiple-Choice-Test. Es geht um Abwägungen, Interpretationen und die Fähigkeit, aus Hunderten von Dokumenten relevante Informationen zu extrahieren. Bisherige Benchmarks für KI in der Rechtsdomäne liefen in vereinfachten Umgebungen und nutzten öffentlich zugängliche Fälle. Wenn die Testfälle öffentlich sind, können KI-Labore ihre Modelle genau auf diese Fälle trainieren. Die Ergebnisse sind dann geschönt – sie zeigen, wie gut ein Modell auswendig gelernt hat, nicht wie gut es wirklich arbeiten kann. Legora geht einen anderen Weg: Der Benchmark bleibt privat. Die Fälle stammen von echten Kanzleien und werden nicht veröffentlicht. So misst man tatsächliche Fähigkeiten, nicht Trainingsdaten-Erinnerung.

Wie genau sieht dieser Benchmark aus? Legora hat einen ganzheitlichen Ansatz gewählt. Statt nur das KI-Modell zu testen, wird das gesamte System bewertet: die Werkzeuge, die Umgebung mit Dokumenten und Vorlagen, die Formulierung der Aufgabe – und das Modell selbst. Ein Spitzenkoch braucht die richtigen Messer, Herde und Zutaten, und er muss das Rezept verstehen. Das Endergebnis wird nicht danach beurteilt, ob es essbar ist, sondern nach einer detaillierten Checkliste: Ist die Temperatur richtig? Sind die Gewürze ausbalanciert? Manche Kriterien sind wichtiger als andere. Genauso bewertet der Legora BAR die Arbeitsergebnisse.

Die vier Komponenten des Benchmarks

Der Legora BAR besteht aus vier Elementen. Erstens die Aufgabenbeschreibung – das, was der Anwalt dem System sagt. Sie ist präzise formuliert, zielorientiert, aber variabel wie eine echte Anweisung eines Partners an einen Associate. Zweitens der Fallordner („Matter File Room“): eine strukturierte Ablage mit allen relevanten Dokumenten, Vorlagen, Playbooks und Präzedenzfällen. Drittens das eigentliche Arbeitsergebnis von Legora – ein einzelnes Dokument, eine Sammlung von Dateien oder eine Antwort im Chat. Viertens die Bewertungskriterien, die Rubrics. Diese werden von erfahrenen Juristen erstellt und sind binär (erfüllt/nicht erfüllt), aber unterschiedlich gewichtet.

Diese Gewichtung ist ein entscheidendes Detail. Manche KI-Benchmarks bewerten nach dem Alles-oder-Nichts-Prinzip: Entweder die Antwort erfüllt alle Kriterien oder sie fällt durch. Das ist für die Praxis unbrauchbar. Ein Associate, der eine wichtige Klausel übersieht, macht einen schwereren Fehler als einer, der ein unbedeutendes Datum falsch setzt. Legora gewichtet die Rubrics nach dem Risiko für den Mandanten. Hochgewichtete Punkte (etwa das Erkennen einer Change-of-Control-Klausel) ziehen bei Fehlen viel stärker ab als niedriggewichtete (etwa ein Formatierungsdetail). So spiegelt der Score die tatsächliche Qualität wider, wie ein Partner die Arbeit eines Associates beurteilen würde.

Praxis statt Labor: Über 5.000 Fälle aus 28 Rechtsgebieten

Der Benchmark basiert auf einem Korpus von über 5.000 realen Fällen aus 28 Rechtsgebieten – von M&A über IP bis zu Sanktionsrecht. Die Fälle stammen von Kanzleipartnern und Legal Engineers, die ihre Expertise und reale Fallarbeit einbringen. Die Daten werden synthetisiert oder anonymisiert, der Kern bleibt authentisch. Aus diesem Pool wurde eine Teilmenge von mehreren hundert Fällen für den BAR ausgewählt, repräsentativ für die gesamte Bandbreite. Jeder Fall ist nach Schwierigkeitsgrad eingeteilt: Kurz (einige Stunden), Mittel (ein bis drei Tage) und Lang (eine Woche oder mehr). Die Einteilung orientiert sich an der Zeit, die ein menschlicher Experte für die Arbeit bräuchte – ein vertrautes Maß für jede Kanzlei.

Warum werden die Fälle nicht veröffentlicht? Offene Benchmarks landen früher oder später in den Trainingsdaten der nächsten Modellgeneration. Ein hoher Score sagt dann weniger über die Fähigkeit des Modells aus, mit unbekannten Situationen umzugehen, sondern mehr über die Vertrautheit mit dem Testmaterial. Legora hält die Fälle privat – jedes getestete Modell sieht die Arbeit zum ersten Mal, genau wie ein Anwalt, der einen neuen Fall übernimmt. Nur so erhält man ein ehrliches Bild. Aus Transparenzgründen hat Legora einen synthetischen Fall mit dem Partner AfterQuery veröffentlicht, der die Methodik zeigt, ohne die echten Fälle preiszugeben.

Die Bewertungsmethode: LLM-as-a-Judge mit gewichteten Rubrics

Jeder Fall wird dreimal hintereinander in einer isolierten Sandbox-Umgebung ausgeführt, um statistische Schwankungen abzufangen. Die Ergebnisse werden von einem LLM-as-a-Judge bewertet, der die Ausgabe mit den Rubrics vergleicht. Ein Jurist erstellt eine Checkliste mit den Muss-Kriterien für eine perfekte Antwort. Der KI-Judge prüft automatisch, ob jedes Kriterium erfüllt ist, und berechnet einen gewichteten Score. Ein Beispiel: Wird jede wesentliche Change-of-Control-Klausel identifiziert? Hochgewichtet, 1 Punkt. Werden Kündigungsrechte korrekt markiert? Hoch. Wird die kommerzielle Auswirkung der Risiken erklärt? Mittel. Fehlt eine unwesentliche Fristangabe? Niedrig. So erhält man einen differenzierten Qualitätswert, der mehr aussagt als ein einfaches Bestanden/Durchgefallen.

Der Benchmark läuft kontinuierlich. Jede Evaluierung liefert dem Team Hinweise, wo das System verbessert werden kann. Diese Verbesserungen fließen direkt in die Legora-Plattform. Es entsteht ein Kreislauf aus Messen, Identifizieren und Optimieren. Allein durch Optimierungen am Harness (der Infrastruktur, die das Modell mit Werkzeugen versorgt) konnte die relative Ausgabequalität innerhalb eines Monats um 5 Prozent gesteigert werden – mit denselben Modellen.

Ergebnisse: Wo die Modelle sich wirklich unterscheiden

Im Benchmark wurden mehrere Modelle von Anthropic, OpenAI und xAI (Grok) getestet. Bei kurzen, begrenzten Aufgaben arbeiten alle Modelle auf ähnlichem Niveau. Der Unterschied zeigt sich bei längeren, komplexeren Fällen, die mehrere Tage oder Wochen dauern. Hier müssen die Modelle über einen großen Bestand an Dokumenten hinweg konsistentes Urteilsvermögen zeigen. In diesen anspruchsvollen Szenarien stechen Modelle wie Fable 5, Grok 4.5, Opus 4.8 und Sonnet 5 hervor.

Auch der Trade-off zwischen Qualität und Kosten beziehungsweise Latenz wurde untersucht. Grok 4.5 punktet mit der niedrigsten Bearbeitungszeit pro Fall bei hoher Qualität. Opus 4.8 und Sonnet 5 bieten ebenfalls ein gutes Verhältnis von Kosten und Leistung. Der Benchmark ist modellagnostisch ausgelegt: Legora arbeitet mit verschiedenen Anbietern zusammen, testet neue Modelle frühzeitig und gibt Feedback, damit die Modelle besser auf die juristische Domäne zugeschnitten werden können.

Was bedeutet das für die Praxis?

Der Legora BAR zeigt, dass die Qualität von KI in der Rechtsarbeit nicht allein vom Modell abhängt, sondern vom gesamten System – den Werkzeugen, der Integration und der Art, wie Aufgaben formuliert werden. Für Kanzleien bedeutet das: Sie sollten nicht blind dem neuesten Modell hinterherlaufen, sondern darauf achten, wie es in ihrer Arbeitsumgebung performt. Ein Benchmark wie der BAR gibt eine verlässliche Entscheidungsgrundlage. Er misst die Qualität der Arbeit, die ein Mandant am Ende erhält. Und er treibt die Verbesserung voran, weil jeder Test direkt in ein besseres Produkt mündet.

Für alle, die sich mit KI-Technologie beschäftigen, ist der Ansatz von Legora ein Beispiel dafür, wie man Benchmarks seriös und praxisnah gestaltet. Kein Hype, keine geschönten Zahlen – sondern eine ehrliche Messung unter realen Bedingungen. Das ist der Standard, den wir in Zukunft von KI-Anbietern erwarten sollten, nicht nur im juristischen Bereich, sondern überall, wo Maschinen für uns denken und arbeiten.

Quelle: legora.com

DeepsecBench ist ein neuer Benchmark für KI-gestützte Sicherheitsanalyse. Entwickelt von einem Team, das Sicherheitslücken automatisiert finden will, testet er, wie gut Modelle Schwachstellen in Anwendungsquellcode erkennen. Angreifer nutzen KI, aber Verteidiger kennen ihren eigenen Code von innen. DeepsecBench hilft, diesen Vorteil zu nutzen.

Was genau ist DeepsecBench?

Der Benchmark basiert auf einem Open-Source-Codebase, das kurz vor einem Commit voller Sicherheitsfixes steht. Das Team wählte 50 Einstiegspunkt-Dateien aus und erstellte einen goldenen Datensatz mit 231 manuell bestätigten Schwachstellen. Jedes Modell durchläuft diesen Test – dreimal, der Median fließt in die Wertung ein. Die Metrik: ein F2-Score, der Recall doppelt so stark gewichtet wie Precision. Die Logik: Eine übersehene Lücke bleibt ungepatcht, ein falscher Alarm verursacht nur kurze Verwirrung. Die Konstruktion des Benchmarks bleibt geheim – kein Modell kann sich auf die spezifischen Dateien oder Commit-Nachrichten trainieren. Das Ergebnis: Die besten Modelle finden im Schnitt etwa 30 Prozent der bekannten Schwachstellen.

Die Kosten der Fähigkeit sinken

Gründliche Sicherheitsanalyse war lange teuer. Nur leistungsstarke Modelle erkannten komplexe Lücken, Kosten im dreistelligen Dollarbereich für ein großes Codebase. Während Modelle wie GPT-5.6 Sol und Claude Opus 5 die Spitzenplätze belegen, bieten günstigere Modelle inzwischen respektable Leistung. Kimi K3 vom chinesischen Startup Moonshot AI erreicht einen Score von 17,56 für 12,38 Dollar – etwa die Hälfte der Spitzenleistung, aber ein Fünftel der Kosten. Grok 4.5 von xAI erzielt mit 15,58 für 5,60 Dollar ein fast gleichwertiges Ergebnis. GPT-5.6 Sol auf mittlerer Einstellung bietet mit 25,10 und Kosten von 17,95 Dollar das beste Preis-Leistungs-Verhältnis unter den Top-Modellen. Die Kosten pro Durchlauf beziehen sich auf 50 Dateien. Ein echtes Produktions-Codebase kann das Hundertfache umfassen – ein kompletter Scan kostet dann je nach Modell zwischen 1.200 Dollar (Kimi) und über 5.000 Dollar (OpenSpitzenteam von OpenAI). Kein Schnäppchen, aber eine Investition, die sich lohnen kann, wenn sie eine teure Sicherheitslücke verhindert.

Wie baust du ein Scannprogramm aus mehreren Modellen?

Sicherheitsanalyse erfordert Regelmäßigkeit. Welches Modell für welchen Job? Eine sinnvolle Strategie: Setze die leistungsstärksten Modelle wie GPT-5.6 Sol für tiefgehende, periodische Audits ein – alle zwei Wochen oder vor wichtigen Releases. Günstigere Modelle wie Kimi K3 oder Grok 4.5 könnten kontinuierlich laufen – bei jedem Merge, nach jedem Commit. So deckst du die Fläche ab, ohne das Budget zu sprengen. GPT-5.6 Sol auf höchster Stufe (xhigh) braucht über drei Stunden und kostet 55,98 Dollar. Auf medium sinkt die Zeit auf rund 30 Minuten und der Preis auf 17,95 Dollar – der Score fällt auf 25,10, reicht aber für neue Features vor dem Deployment. Ein Startup könnte jeden Merge mit Grok 4.5 scannen und die teuren Modelle nur für Meilensteine reservieren. Ein Großunternehmen könnte auf kritischen Services Frontier-Modelle in voller Tiefe laufen lassen, für wichtige Pull Requests dieselben Modelle auf niedriger Stufe und für den Rest der Codebasis eine durchgehende Kimi- oder Grok-Sweep.

Die technische Umsetzung: Ein Endpunkt für alle Modelle

Sicherheitsscans sind spitzenlastig – sie verbrauchen in kurzer Zeit viele Token. Diese Burst-Kapazität ist schwer direkt bei jedem Anbieter zu buchen. DeepsecBench läuft deshalb über einen einzigen Endpunkt, den AI Gateway. Das Gateway vereint alle Modelle hinter einer Schnittstelle. Routing, Wiederholungen, Failover passieren automatisch. Kein separates API-Keys für jeden Anbieter, keine Rate-Limits. Du übergibst einfach den Modellnamen – zum Beispiel xai/grok-4.5 – und deinen API-Key aus der Umgebungsvariablen AI_GATEWAY_API_KEY. Der Befehl pnpm deepsec process --project-id my-app --agent pi --model xai/grok-4.5 startet den Scan. Das Gateway balanciert Kosten und Leistung – du bestimmst, welches Modell für welchen Scan-Typ zuständig ist. Das senkt die Hürde für kontinuierliche Sicherheitsprüfungen.

Dein Vorteil: Du kennst dein eigenes System

Angreifer verwenden dieselben KI-Modelle – aber sie agieren von außen. Sie können nur erraten, was hinter einem Endpunkt lauert. Du dagegen siehst den gesamten Quellcode, die Architektur, die Historie. Diese Transparenz macht die Modelle in deinen Händen mächtiger. Ein Modell, das den Quellcode liest, findet eine Lücke, die ein Angreifer nur durch langes Probieren aufdecken könnte. Der Vorteil zählt nur, wenn du ihn nutzt, bevor ein Angreifer zuschlägt. DeepsecBench liefert dir die Daten, um zu entscheiden, wie viel du in Sicherheit investieren willst. Ob Startup oder Enterprise – du kannst dir deinen eigenen Mix aus Spitzenleistung und Kosteneffizienz zusammenstellen. Der Benchmark wird laufend aktualisiert, sobald neue Modelle erscheinen. Sicherheit ist kein einmaliges Projekt, sondern ein kontinuierlicher Prozess. Mit den richtigen Tools und einer klaren Strategie hast du die Oberhand.

KIs finden Sicherheitslücken immer besser, die Kosten sinken. Du brauchst kein großes Budget für effektive Scans. Ein Mix aus teuren Audits und häufigen, günstigen Scans macht Code sicherer. Die besten Modelle finden rund 30 Prozent der Lücken – jedes gefundene Problem ist ein verhindertes. KI ist kein Allheilmittel, sondern ein Werkzeug. Nutze es regelmäßig und bewusst.

Quelle: vercel.com

Du arbeitest an einem kniffligen Softwareproblem. Du hast bereits mehrere KI-Modelle um Hilfe gebeten, aber jede Antwort wirkt nur halb durchdacht. Der Code sieht auf den ersten Blick gut aus, doch bei genauerem Hinsehen fehlt die Tiefe. Randfälle werden ignoriert. Du wünschst dir einen Assistenten, der nicht nur schnell eine Lösung liefert, sondern versteht, warum sie richtig ist – und der seine eigene Arbeit überprüft. Hier setzt Claude Opus 5 an.

Anthropic hat mit Claude Opus 5 ein Modell veröffentlicht, das eine gute Balance zwischen Leistung und Kosten bietet. Es erreicht fast die Intelligenz des teureren Fable 5, kostet aber nur die Hälfte. Gleichzeitig übertrifft es seinen Vorgänger Opus 4.8 in den meisten Disziplinen – vom Programmieren über wissenschaftliche Analysen bis zur eigenständigen Fehlerbehebung. Das macht es zum Standardmodell auf Claude Max und zum stärksten auf Claude Pro. Für tägliche KI-Nutzer ist das ein Vorteil.

Auf dem Frontier-Bench v0.1, einer Sammlung anspruchsvoller Softwareentwicklungsaufgaben, verdoppelt Opus 5 die Leistung von Opus 4.8 – bei niedrigeren Kosten pro Aufgabe. Ähnlich gut sind die Ergebnisse auf dem CursorBench 3.2: Das Modell liegt mit maximalem Aufwand nur 0,5 Prozent unter dem Spitzenwert von Fable 5, benötigt aber nur halb so viel Rechenleistung. Für Entwickler bedeutet das Spitzenergebnisse, ohne das Budget zu sprengen. Die Effizienzsteigerung folgt aus einer Architektur, die Ressourcen gezielt einsetzt.

Opus 5 geht vor wie ein Handwerker, der vor jedem Schnitt den Bauplan studiert und das Werkzeug prüft, anstatt loszuhämmern. Das zeigt sich in Beispielen aus der Praxis. In einem Test sollte Opus 5 ein Maschinenteil aus einer Zeichnung als 3D-Modell rekonstruieren – ohne direkten Zugriff auf das Bild. Das Modell schrieb eine eigene Computer-Vision-Pipeline, um die Geometrie aus den Rohpixeln zu extrahieren, und löste die Aufgabe mehrfach. Kein anderes Modell schaffte das auch nur einmal.

Ein weiteres Beispiel: Ein echter Bug in einem populären Open-Source-Paketmanager. Opus 5 identifizierte nicht nur die oberflächliche Ursache, sondern fand einen Randfall, den selbst die Community in ihrem Patch übersehen hatte. Konkurrierende Modelle reparierten das Symptom und meldeten den Bug fälschlich als erledigt. Opus 5 grub tiefer und lieferte eine dauerhafte Korrektur. Ein Händler bat das Modell, einen Marktdatenfeed für eine neue Börse zu bauen. Frühere Modelle scheiterten, selbst mit detaillierten Anweisungen. Opus 5 schrieb den gesamten Code in einer Sitzung – und erstellte selbstständig eine Testumgebung, um die Korrektheit seiner Implementierung zu überprüfen, da es keinen Live-Feed gab.

Auch bei analytischen Aufgaben zeigt das Modell Stärken. Auf dem Zapier AutomationBench, einem Test für durchgängige Geschäftsprozesse, erreicht Opus 5 eine etwa 1,5-fach höhere Erfolgsquote als das nächstbeste Modell, bei gleichen Kosten pro Aufgabe. Es nimmt eine rohe Kundenliste, identifiziert gefährdete Konten, alarmiert die zuständigen Betreuer und erstellt eine Zusammenfassung für das Retention-Team – alles in einem automatisierten Durchlauf. Frühere Modelle scheiterten hier. Für die Genomforschung beschreibt ein früher Tester, dass Opus 5 sich wie ein vorsichtiger Wissenschaftler verhält: Es wählt die richtigen statistischen Tests aus, um Störfaktoren auszuschließen, überprüft Ergebnisse mit unabhängigen Methoden und bleibt auch bei langen, mehrstufigen Analysen konzentriert. Das unterscheidet es von vielen anderen Modellen, die bei komplexen Aufgaben nachlassen.

Im Bereich der Finanzanalyse hob ein Anwender hervor, dass Opus 5 bei numerischen Berechnungen, Tabellenarbeit und kritischem Denken zulegt. In seinen Tests lag die Genauigkeit durchschnittlich neun Prozentpunkte höher als bei Opus 4.8, bei einem Drittel weniger Interaktionen und Werkzeugaufrufen und 60 Prozent weniger Zeit. Das senkt Kosten und beschleunigt Ergebnisse. Bei der Selbstkontrolle zeigt sich: Opus 5 öffnet erstellte Webseiten in einem Browser bei Desktop- und Mobil-Breite, entdeckt ein verstecktes Produkt unter dem Falz und einen nicht sichtbaren Checkout-Button – und behebt beides, bevor es die Arbeit zurückgibt. Das ist nützlich für die Frontend-Entwicklung.

Selbst in Disziplinen wie der Rechtswissenschaft punktet das Modell. Bei Vertragsprüfungen und Analysen von Unternehmensgovernance-Fällen erzielte es die besten Ergebnisse aller getesteten Modelle. Opus 5 erreicht diese Qualität oft mit geringerem Denkaufwand – es generiert durchschnittlich 26 Prozent weniger Tokens als Opus 4.8 bei maximaler Denkstufe, ohne Einbußen bei der Genauigkeit.

Quelle: anthropic.com

KI-Agenten verbrauchen viele Tokens. Das wird teuer. Adam Jacob zeigt mit seinem Workflow „Swamp“, wie man den Verbrauch senkt – ohne Funktionseinbußen. Sein Ansatz ist eine Systemoptimierung, kein Hype.

Es ist ineffizient, KI für Aufgaben zu nutzen, die deterministisch lösbar sind. Swamp trennt das: Routinesachen erledigt deterministischer Code, knifflige Fälle das LLM.

Das Problem: Garfield und der teure Koordinator

Ausgangssituation ist ein Skill namens „Garfield“, entwickelt bei Sentry. Garfield prüft nach jeder Code-Änderung die Coding-Policy. Es ist intelligent, flexibel – und teuer. Eine typische Ausführung verbraucht etwa 4,5 Millionen Tokens, läuft 12 Minuten und setzt 23 Sub-Agenten ein. Das Herzstück ist ein Koordinator-Agent, der Sub-Agenten losschickt, Ergebnisse einsammelt und bewertet. Ein Loop aus nicht-deterministischen Entscheidungen, bewertet von einem ebenfalls nicht-deterministischen Koordinator. Ein ineffizienter Loop.

Garfield ist nicht schlecht, aber es nutzt das LLM für jeden Schritt. Viele Schritte – etwa das Prüfen von Mustern oder Konventionen – sind deterministisch lösbar. Sie brauchen kein LLM. Ein Parser oder Regex reicht. Das LLM dort einzusetzen ist teuer.

Die Lösung: Swamp – deterministische Koordination, gezielte Intelligenz

Adam Jacob entwickelte eine Erweiterung für sein Swamp-System, die den Garfield-Skill ersetzt. Statt eines Koordinator-Agenten organisiert deterministischer Code die Arbeit der Sub-Agenten. Diese werden nur gestartet, wenn wirklich Intelligenz gefragt ist – etwa bei Stil- oder Architekturbewertung. Die Ergebnisse jedes Sub-Agenten werden als versionierte, typisierte Daten gespeichert. Das schafft Transparenz und vermeidet teure Wiederholungen.

Das Ergebnis: Statt 4,5 Millionen Tokens werden nur noch rund 500.000 benötigt – eine Reduktion um den Faktor 8. Die Laufzeit sinkt von 12 auf 6,5 Minuten, die Anzahl der Agenten von 23 auf 3. Die Funktionalität bleibt identisch, inklusive einer zusätzlichen Risikobewertungsphase. Die Einsparung kommt daher, dass der koordinierende Overhead wegfällt. Der Koordinator war teuer, weil er non-deterministisch die Arbeit anderer non-deterministischer Prozesse bewertete. Swamp ersetzt ihn durch deterministische Logik.

Schritt für Schritt: Wie du selbst von Garfield zu Swamp wechselst

Eine Anleitung in fünf Schritten, um diesen Prozess nachzuvollziehen.

Schritt 0: Installation und Initialisierung

Installiere Swamp mit curl -fsSL https://swamp-club.com/install.sh | sh. Gehe ins Verzeichnis deiner Agenten und Skills und initialisiere: swamp repo init --tool codex. Der Parameter --tool gibt das Framework an.

Schritt 1: Verstehe das aktuelle Verhalten

Bevor du umbaust, verstehe genau, was der Skill tut. Adam Jacob las den Garfield-Skill von Hand und machte Notizen. Dann ließ er Codex den Skill analysieren und zusammenfassen – inklusive ASCII-Diagramme. So visualisierte er das Zusammenspiel von Koordinator und Sub-Agenten. Auch wenn du den Skill selbst geschrieben hast, lohnt eine zweite Meinung, um blinde Flecken zu vermeiden.

Schritt 2: Übersetze den Skill in eine Swamp-Erweiterung

Bitte einen Agenten – Codex oder Claude –, den Skill in eine Swamp-Workflow-Erweiterung zu übersetzen. Die Anweisung: „Übersetze den Garfield-Skill in eine Swamp-Erweiterung. Ziel ist, das Verhalten direkt in deterministischen Code zu übertragen. Beginne mit einem Plan, den ich prüfen kann.“ Wenn du Swamp noch nicht kennst, wirst du die Details vielleicht nicht sofort beurteilen können. Wichtig ist, dass der Plan die gewünschten Ergebnisse abbildet. Sobald der Plan steht, lass den Agenten implementieren und teste manuell.

Schritt 3: Black-Box-Testing und Messung

Ein nützlicher Test für KI-generierten Code ist der Black-Box-Abnahmetest. Er gibt eine wiederholbare Methode für Verbesserungen und Regressionstests. Führe ihn in einem separaten Agentenkontext durch. Bitte den Agenten, einen Test zu schreiben, der alten Skill und neuen Swamp-Workflow ausführt und Token-Verbrauch, Ausführungszeit und Erfolgsquote misst. Der Agent erstellt dann eine Benchmarking-Suite, erzeugt eine Test-Codebase und führt die Tests durch. Die Ergebnisse sind aufschlussreich.

Adam Jacob maß zwei Testfälle. „contained-dry-run“ bestand: Garfield in 12,8 Minuten und 4,6 Millionen Tokens, Swamp in 6,6 Minuten und 506.000 Tokens. „payment-idempotency“ scheiterte in beiden Varianten – aber anders. Garfield scheiterte offen: es erklärte die Arbeit fälschlich für erfolgreich. Swamp scheiterte geschlossen: es meldete, die maximale Anzahl von Agenten sei erreicht. Das ist ein Vorteil deterministischer Systeme: Fehler werden gemeldet, nicht vertuscht.

Schritt 4: Refaktorisieren und Verfeinern

Die Messungen zeigen Optimierungsbedarf. Bei Garfield würde Adam Jacob die Fälle angehen, in denen der Workflow aufgibt, bevor alle Probleme gelöst sind. Er würde weitere Testfälle hinzufügen und prüfen, ob der Workflow mit größeren Änderungen zurechtkommt. Der Vorteil von Swamp: Änderungen sind einfach, weil der Workflow aus deterministischem Code besteht. Du misst, refaktorisierst, misst wieder – bis die Performance stimmt. Ein Kreislauf, den jeder Entwickler kennt.

Warum Swamp funktioniert – die Logik dahinter

Swamp ist effektiv, weil es deterministische Logik und KI-Intelligenz trennt. Statt das LLM in den heißen Pfad jeder Entscheidung zu stellen, erledigt deterministischer Code die meiste Arbeit – billig, schnell und vorhersagbar. Das LLM wird nur eingeschaltet, wenn es wirklich gebraucht wird. Das reduziert den Token-Verbrauch drastisch, ohne die Qualität zu beeinträchtigen. Weil die deterministischen Teile zuverlässig sind und die KI nur punktuell eingesetzt wird, sinkt auch die Fehlerrate. Der Workflow wird robuster.

Adam Jacob sagt: „Du nutzt den Agenten, um das Programm zu bauen, das die Notwendigkeit des Agenten minimiert.“ Das ist die Idee. Statt dem LLM jede Mikroentscheidung zu überlassen, erstellst du ein adaptives Modell des Problems. Die versionierten, typisierten Daten geben dir Transparenz über jeden Schritt. Du siehst, was die Sub-Agenten produziert haben, und kannst eingreifen. Das ist günstiger und kontrollierbarer.

Fazit: Ein pragmatischer Weg zu günstigeren KI-Workflows

Garfield und Swamp zeigen: Hohe Token-Kosten sind oft selbst verursacht. Wir neigen dazu, KI für Aufgaben zu verwenden, die einfacher Code erledigt. Adam Jacobs Ansatz kombiniert die Stärken beider Welten: deterministische Logik für das, was Computer schon immer konnten, und KI für das, was nur ein Modell leistet. Die Ergebnisse: achtmal weniger Tokens, doppelt so schnell, bessere Fehlermeldungen. Für Teams in der Produktion ist das eine effektive Optimierung und solide Systemarchitektur.

Quelle: adamhjk.com

Charles AZAM testete zwei KI-Modelle mit einem kniffligen Optimierungsproblem. Die Frage: Hilft der native /goal-Befehl, bessere Lösungen zu finden, oder ist er hinderlich? Die Ergebnisse zeigen, wann der Befehl nützt und wann er schadet.

Das Problem: Ein Netzwerk aus Glasfaser

Das Problem heißt KIRO, ein NP-schweres Optimierungsproblem aus der Netzwerkplanung. Es geht darum, in Grenoble, Nizza und Paris Verteilerpunkte und Endgeräte über Glasfaserkabel zu verbinden. Die Lösung muss aus redundanten Schleifen bestehen, die an Verteilerknoten hängen, mit kurzen Abzweigen von Masten. Jeder Mast darf nur einmal vorkommen, die Richtung der Kabel beeinflusst die Kosten. Ziel ist es, die gesamte Kabellänge zu minimieren.

Zur Einordnung: Der Suchraum ist astronomisch groß. Selbst wenn man nur die 532 Endgeräte in Paris auf 11 Verteilerknoten verteilt, gibt es 11^532 mögliche Zuordnungen. Eine konservative Abschätzung ergibt etwa 10^1223 Möglichkeiten. Die Anzahl der Atome im Universum wird auf 10^80 geschätzt.

Der Test: Sechs Modelle, zwei Modi, dreißig Minuten

AZAM ließ jedes Modell 30 Minuten rechnen, einmal im normalen Modus (Plain) und einmal mit aktiviertem /goal-Befehl. Der Befehl signalisiert: „Hier ist dein Ziel: Finde die kürzeste Gesamtkabellänge. Arbeite so lange, bis du es erreicht hast oder die Zeit abläuft.“ Gemessen wurde die Länge der gefundenen Lösung – niedrigere Werte sind besser. Als Benchmark diente AZAMs eigene, in C++ geschriebene Lösung.

Getestet wurden Claude Fable 5, Opus 4.8, Sonnet 5, Terra, Luna und GPT-5.6 Sol. Die Hauptvergleiche konzentrierten sich auf Fable und Sol, von denen jeweils drei vollständige Durchläufe pro Modus vorliegen. Alle Läufe liefen in einer Docker-Umgebung unter Harbor 0.1.43, mit maximaler Reasoning-Stufe und einem Timeout von 1900 Sekunden.

Die Ergebnisse: Fable dominiert, /goal ist ein zweischneidiges Schwert

Die Ergebnisse sind eindeutig: Claude Fable 5 ist GPT auf diesem Problem überlegen. Im Plain-Modus erreichte Fable durchschnittlich 32.386 Meter Gesamtkabellänge, Sol 34.261 Meter – ein Unterschied von fast 1.900 Metern. Fables Ergebnisse schwankten nur um 319 Meter, Sols um fast 2.000 Meter. Fable lieferte nicht nur durchschnittlich bessere, sondern auch verlässlichere Lösungen.

Beim /goal-Vergleich führte der Befehl in vier von sechs Durchläufen zu einer Verbesserung. Doch der Durchschnitt zeigt: Bei Fable stieg die Länge mit Goal um 759 Meter, bei Sol um 868 Meter. In den verbleibenden zwei Läufen gab es massive Verschlechterungen. Bei Fable sprang der Wert in einem Lauf von 32.446 auf 35.178 Meter (plus 2.732 Meter), bei Sol von 33.581 auf 39.371 Meter (plus 5.790 Meter). Der Median bewegte sich leicht in die richtige Richtung. /goal hilft häufig ein bisschen, schadet aber gelegentlich massiv. Die Gewinne sind klein, die Verluste können groß sein.

Warum ist das so? Ein Blick unter die Haube

AZAM untersuchte die Implementierung der /goal-Funktion in Claude Code und Codex. Obwohl der Befehl gleich heißt, steckt unterschiedliche Architektur dahinter. Bei Claude Code wird /goal als separater Evaluator realisiert. Nach jeder Antwort des Hauptmodells prüft ein kleineres Modell (Claude Haiku) anhand des Transkripts, ob das Ziel erreicht ist. Es kann keine Werkzeuge nutzen oder Dateien inspizieren – es sieht nur den Dialog. Bei Codex wird der Zielzustand persistiert und das Modell erhält spezielle Werkzeuge (create_goal, get_goal, update_goal). Das Modell entscheidet selbst, wann das Ziel erreicht ist, und bekommt bei Leerlauf eine Fortsetzungsaufforderung. Diese Architektur ist anfälliger für Fehleinschätzungen und kann dazu führen, dass das Modell zu früh aufgibt oder sich in eine falsche Richtung verbeißt.

Bei Optimierungsproblemen mit riesigen Suchräumen ist es nicht trivial zu erkennen, ob ein weiterer Schritt das Ergebnis verbessert oder verschlechtert. Ein Befehl, der einfach „mach weiter“ sagt, kann einen guten Algorithmus verstärken, aber auch einen schlechten weiter in die Irre führen. Die Qualität der Suchstrategie ist wichtiger als die Anzahl der Wiederholungen.

Was bedeutet das für die Praxis?

Blindes Vertrauen in einen /goal-Befehl ist nicht angebracht. Wenn du eine KI mit einer schwierigen Optimierungsaufgabe betraust, solltest du verstehen, wie der Goal-Mechanismus in deinem System funktioniert. Ein externer Evaluator, der nur den Dialog sieht, kann Fehlentscheidungen des Hauptmodells möglicherweise nicht korrigieren. Ein selbstbewertendes System kann sich in eine Sackgasse manövrieren und Ressourcen unnötig verbrauchen.

Der Benchmark zeigt auch, dass die Modellwahl entscheidend ist. Claude Fable 5 erwies sich auf diesem NP-schweren Problem als robuster und leistungsfähiger als GPT-5.6 Sol – unabhängig vom Goal-Modus. Die Kombination aus einem starken Modell und einer durchdachten Steuerung (ohne künstliche Goal-Vorgabe) führte zu den besten und verlässlichsten Ergebnissen.

KI ist kein Allheilmittel. Selbst fortschrittliche Modelle stoßen bei kombinatorischen Optimierungsproblemen an ihre Grenzen. Der /goal-Befehl ist kein Turbo-Knopf, sondern ein Werkzeug, das je nach Problem und Implementierung sowohl nützen als auch schaden kann. Teste verschiedene Konfigurationen, vertraue auf Konsistenz und sei skeptisch gegenüber Features, die auf den ersten Blick wie ein einfacher Verstärker wirken. Die wahren Helden sind durchdachte Algorithmen und clevere Problemzerlegung – die KI hilft, sie schneller auszuführen, ersetzt aber nicht das Verständnis des Problems.

Quelle: charlesazam.com