Loop Engineering mit Super Mario und zwölf KI-Coding-Agenten

Ich habe zwölf KI-Coding-Agents exakt dieselbe Aufgabe gegeben: einen Koopa Troopa zu implementieren — Nintendos Schildkröten-Gegner aus Super Mario, der sich in einen Panzer duckt, den man zu einem rutschenden Geschoss antreten kann — im selben kleinen Angular-basierten Super-Mario-Klon, auf Basis derselben zwei Tickets, unter derselben automatisierten Agent-Schleife. Dann habe ich mir angesehen, was zurückkam.

Das ist ein Backyard Setup, kein Leaderboard — n=1, eine Codebasis, eine Domäne, keine statistische Signifikanz. Mir ging es nicht um ein Ranking von Modellen, sondern um ein Gefühl dafür, wie sich eine Agent-Schleife tatsächlich verhält, wenn man das Modell darunter austauscht.

Die Aufgaben

Das Projekt ist ein bewusst kompakter Mario-Klon: ein kachelbasiertes Level, ein Held mit Sprungphysik und ein bereits vorhandener Gegner — der Gumba — als Referenzimplementierung. Jeder der zwölf Agents bekam eine unberührte Kopie dieser Basis und zwei GitHub-Issues:

1. koopa-troopa — einen grünen Koopa Troopa implementieren: Springt Mario auf ihn, versteckt er sich in seinem Panzer; berührt man den Panzer, rutscht er los; ein rutschender Panzer tötet andere Gegner und Mario (mit einem kurzen Immunitätsfenster nach dem Antreten).
2. enemy-bounce — Springt Mario auf einen beliebigen Gegner, prallt er ab; hält man in diesem Moment die Sprungtaste, fällt der Absprung höher aus; und eine gehaltene Taste darf niemals wiederholte Sprünge auslösen (Release-Latch).

Beide Tickets sind genau die Sorte Arbeit, die ich testen wollte: ein neues Feature, das tief in bestehendes Verhalten verwoben ist (Kollisionssystem, Stomp-Mechanik, Sprungphysik), statt daneben angeschraubt zu werden, Komplexität deutlich jenseits von CRUD-Demos — und ein Beispiel in Reichweite, an dem man sich orientieren kann. Das ist die Situation in großen Business-Systemen, wo neue Anforderungen fast immer neben etwas strukturell Ähnlichem landen.

Jedes Ticket las sich wie eines aus dem Sprint Planning: eine nutzerorientierte Beschreibung, Scope- und Out-of-Scope-Listen, Given/When/Then-Abnahmekriterien und ein Verifikationsabschnitt („alle Tests grün, Build läuft durch"). Das Refinement-Gespräch wurde vorab simuliert: Ein LLM stellte die klärenden Fragen, die ein Entwickler stellen würde, und die Antworten wanderten als Abschnitt Design Decisions zurück in jedes Ticket. Auch die Nachbesserung lief Sprint-artig: Bugs aus dem ersten Review kamen in ein einzelnes QA-artiges Fix-Ticket, und jeder Agent bekam genau einen weiteren Lauf. Eine falsche Sprite-Kachel als einziger Defekt bekam kein Ticket — warum, dazu unten mehr.

Die Harness

Jedes Modell lief unter dem offiziellen Agent seines Herstellers — Claude Code, Codex CLI, cursor-agent, Antigravity, Grok CLI — in Standardkonfiguration. Verglichen werden hier also keine nackten Modelle, sondern die Produkte, die Entwickler tatsächlich benutzen: Modell plus Agent plus System-Prompt und Tooling.

Alle steckten in derselben Orchestrierungs-Harness, Sandcastle — im Kern eine Ralph-Loop (der Agent wird so lange erneut über seinen eigenen Output aufgerufen, bis die Arbeit erledigt ist) mit vier Stufen: Ein Planner liest die offenen Tickets, ein Implementer übernimmt jedes Ticket auf einem eigenen Branch und schreibt dabei Tests, ein Reviewer geht über den Diff, und ein Merger integriert, was übrig bleibt. Angebunden an GitHub hinterlässt ein Lauf dieselbe Papierspur wie ein menschlicher Sprint — Issues rein, Branches und Kommentare raus, inklusive eines Token- und Laufzeitberichts pro Issue.

Jede Stufe lief in einer Sandbox. Das ist mehr als Netzwerk-Hygiene: Zwölf Lösungen für dieselben Tickets lagen in benachbarten Verzeichnissen, und jede musste unabhängig entstehen. Bei den zwei Agents, deren Transkripte ich Aufruf für Aufruf geprüft habe (Grok und Opus 5), hat das gehalten — kein Repo eines Nachbarn wurde jemals gelesen.

Die Ergebnisse

Die Zahlen sind Summen über beide Aufgaben plus etwaige Fix-Runden, über alle Phasen hinweg, entnommen aus den Berichten, die Sandcastle an jedes GitHub-Issue gepostet hat. Alles fand im Juli 2026 statt.

Die Kosten sind der gemessene Verbrauch jedes Laufs (frischer Input, Cache-Writes/-Reads, Output, alle Phasen und Fix-Runden) zu öffentlichen API-Listenpreisen — ein normalisiertes Was-wäre-wenn, nicht unbedingt das, was ein Lauf Sie kostet: Bei Flatrate-Abos ist der zusätzliche Lauf bis zur Quota kostenlos. Kleingedrucktes: Composers Cache-Read-Preis ist angenommen (nicht veröffentlicht), Sonnet läuft mit seinem Einführungspreis, GPT-5.6 mit der Preissenkung von Ende Juli.

Jede Zeile ist ein sauberer, abgeschlossener Lauf von einer unberührten Basis aus. Bewertet habe ich die Agents so, wie ein Tech Lead einen Pull Request reviewt: Ich habe jeden Diff gelesen, jede gemergte Testsuite lokal ausgeführt und das Level gespielt, um den Gegner tatsächlich in Bewegung zu sehen — der einzige Grund, warum der Moonwalk weiter unten überhaupt in diesem Artikel steht, denn keine Testsuite im gesamten Feld hat ihn gefangen.

Die Spannbreite: Faktor 160 bei den Kosten, Faktor 19 bei der Laufzeit. Eine Zahl lohnt das Entschlüsseln: Sonnet hat mit Abstand die meisten Roh-Tokens verbraucht — 98 % davon billige Cache-Reads, weil seine Schleife bei jedem Schritt einen immer weiter wachsenden Kontext erneut mitschickte. Was kostet, sind nicht die Runden, sondern Runden mal dem, was man im Kontext auflaufen lässt. Die billigsten Läufe waren nicht die schlechtesten — der teuerste (Fable) war allerdings der einzige fehlerfreie. Mehr Gründlichkeit ist nicht automatisch besser: Für ein gut spezifiziertes Feature in einer kleinen Codebasis reichten die Läufe zwischen 7 und 25 Minuten völlig aus.

Einen Koopa bauen können alle. Einen sehen kann fast keiner.

Die Schlagzeile, die vor zwei Jahren undenkbar gewesen wäre: Alle zwölf Agents haben einen funktionierenden Koopa Troopa abgeliefert — mit vollständiger State Machine (laufend → Panzer → rutschend → gestoppt), Kick-Immunität und Stomp-Bounce inklusive Release-Latch. Vier schafften es im ersten Anlauf, die übrigen acht nach ihrem einen Fix-Ticket.

Kosmetisch war es eine andere Geschichte, und der Fehler war systematisch: die Sprites. Die Aufgaben verlangten, die Kacheln des grünen Koopa aus einem PNG-Spritesheet zu extrahieren, „analog zu den vorhandenen Gumba-Kacheln". Das war das schwierigste Teilproblem im gesamten Aufbau — und das einzige, bei dem die Fix-Runde nicht zuverlässig half. Acht der zwölf Agents griffen zu falschen Kacheln und bekamen dafür ein Ticket:

Drei weitere (sol, Grok und Opus 5) wählten falsche Kacheln als ihren einzigen Defekt; terra verpasste seinem Koopa sogar Flügel — explizit out of scope. Opus 5 traf beide Panzer-Kacheln, nahm die Lauf-Frames aber aus der falschen Zeile, sodass sein Koopa als Hammer Bro durchs Level patrouilliert. Genau ein Modell wählte die richtigen Kacheln aus eigener Kraft: Fable — zugleich der einzige Agent ohne jeden Defekt.

Die Bugs führten zurück zu meiner Spezifikation

Die sichtbaren Bugs gruppierten sich in drei Muster, und der Abgleich jedes Musters mit dem tatsächlichen Ticket-Text hat verändert, wie ich über die Fehler denke.

Der Moonwalk. Der häufigste Bug: Der Koopa lief nach rechts, schaute aber nach links und glitt so rückwärts durchs Level. Fast jeder Agent mit Fix-Ticket hatte ihn.

Nur: Das Ticket erwähnt die Blickrichtung mit keinem Wort. Es sagt: „Analog zum vorhandenen Gumba implementieren" — und der Gumba ist symmetrisch, ohne jede Spiegelungslogik. Die Agents haben getreu eine Referenz nachgebaut, der die geforderte Eigenschaft stillschweigend fehlte. Der Moonwalk ist nicht wirklich ein Modellfehler; er ist ein Spezifikationsfehler.

Der Panzer, der sich nicht antreten ließ. terra lieferte den einen echten State-Machine-Bug: Ein Sprung auf einen ruhenden Panzer trat ihn nicht an. Die Abnahmekriterien hatten den Fall richtig beschrieben, aber der codeartig formulierte Design-Decisions-Punkt ließ den ruhenden Panzer stillschweigend aus. Ein Agent, der diesem Punkt mehr vertraut als der Prosa, produziert exakt terras Bug — die beiden Hälften meines eigenen Tickets widersprachen sich durch Auslassung.

Das Gegenbeispiel. Das enemy-bounce-Ticket spezifizierte seine kniffligste Ecke explizit — eine gehaltene Sprungtaste darf niemals einen erneuten Sprung auslösen —, und elf von zwölf Agents bekamen sie richtig hin; nur Composer lieferte einen Endlos-Sprung-Bug, behoben in seiner Fix-Runde. Wo die Spezifikation explizit war, waren Fehler selten und idiosynkratisch. Wo sie schwieg oder sich selbst widersprach, waren Fehler systematisch und nahezu universell.

Das ist das Muster: Die Agents sind nicht in erster Linie am Programmieren gescheitert; sie haben die Mehrdeutigkeiten in meinen Tickets ans Licht gebracht — zwölffach, parallel. Ein menschlicher Entwickler überbrückt Lücken in der Spezifikation mit Genre-Wissen, oft ohne die Lücke zu bemerken. Ein LLM-Agent nimmt alles gnadenlos wörtlich.

Codequalität: Was zwölf Agents ohne Vorgaben liefern

Funktionierender Code ist eine niedrige Latte, also habe ich auch gemessen, wie die Lösungen gebaut sind — mit drei Instrumenten, die unterschiedliche Blickwinkel abdecken. Ein AST-Tool hat genau die Funktionen geparst, die jede Schleife angefasst hat, und die harten Zahlen erhoben: Funktionslänge und Schachtelungstiefe. Jede gemergte Testsuite lief lokal erneut, mit Coverage über die betroffenen Feature-Dateien — wobei eine Datei, die kein Test auch nur importiert, mit 0 % zählt, denn Coverage-Tools lassen solche Dateien stillschweigend weg und würden ausgerechnet die Agents schönrechnen, die am wenigsten getestet haben. Und die strukturellen Qualitäten, die sich nicht in Zahlen fassen lassen, gingen an einen blinden LLM-Richter mit einer festen 5-Sterne-Bewertung für zwei Kriterien: SLAP und Kohäsion.

SLAP steht für das Single Level of Abstraction Principle: Innerhalb einer Funktion sollten alle Anweisungen auf derselben Abstraktionsebene liegen. Eine Funktion formuliert entweder das Warum — sie orchestriert ein Verhalten als Abfolge gut benannter Schritte wie stompEnemy() oder startKickImmunity() — oder sie trägt das Wie genau eines solchen Schritts: die rohe Mechanik eines einzelnen Mechanismus. Nie beides, denn genau die Mischung macht Code schwer lesbar: drei gut benannte Schritte, dann zwanzig Zeilen Pixel-Mathematik inline, dann wieder ein Schritt — und der Leser muss mitten in der Funktion die Flughöhe wechseln. Kohäsion ist das Schwesterkriterium: eine Verantwortlichkeit pro Funktion — und zwar eine, die sich benennen lässt.

Der Richter sah ausschließlich anonymisierte, auf Leaks geprüfte Bundles — keine Modellnamen, keine agent-spezifischen Pfade oder Marken. Und um die Stabilität der Rubrik zu prüfen, habe ich die komplette Bewertung wiederholt: Jeder Score wurde auf einen Punkt genau reproduziert.

Ohne Qualitätsvorgaben war die Spannbreite enorm — von Lehrbuch-Schichtung bis zu einer 110-Zeilen-Kollisionsfunktion mit einem switch im switch, Pixel-Mathematik inline drumherum. Die Qualität folgte den Preisschildern — als Tendenz, nicht als Gesetz: die Claude-Agents alle im oberen Feld, Opus 5 die einzige 5/5, die billigsten Agents am unteren Ende — und Grok als ehrliche Ausnahme, Schichtung auf Top-Niveau für unter drei Dollar. Beim Testen ging die Schere genauso weit auseinander: Sonnet schrieb doppelt so viel Testcode wie Produktionscode, luna weniger als die Hälfte.

Kann man die Qualität mit Regeln zurückkaufen?

Ich habe den schwächsten Agent genommen und explizite Regeln ergänzt — SLAP, Hilfsfunktionen müssen benennbare Fachkonzepte sein, eine harte Schachtelungsgrenze von 2 — durchgesetzt sowohl vom Implementer als auch vom Reviewer in der Schleife. Bewusst kein Zeilenlimit: Numerische Zielwerte werden ausgetrickst.

Das Ergebnis ist zweischneidig. Zwei volle Punkte bei einer blinden Neubewertung — der Monolith verschwunden, die harte Regel eingehalten; Verstöße zu erkennen ist deutlich leichter, als sie zu vermeiden, und die Reviewer-Stufe ist der Ort, an dem sich diese Asymmetrie auszahlt. Aber das obere Feld blieb außer Reichweite, die Kosten haben sich fast verdoppelt — und das Testen wurde schlechter: Die Regeln sagten nichts über Tests, also hat das Modell den Aufwand stillschweigend vom Testen zur Struktur umgeschichtet. Leitplanken lenken die Aufmerksamkeit; was man in ihnen weglässt, zahlt die Rechnung.

Drei Erkenntnisse, die Bestand hatten

1. Das Grundniveau ist weiter gestiegen, als die meisten Teams glauben. Ein zustandsbehaftetes Spielmechanik-Feature, funktionierend abgeliefert von zwölf Agent-Stacks, jeweils innerhalb eines gewöhnlichen Bugfix-Zyklus. Die Frage ist nicht mehr, ob ein Agent Ihr Ticket umsetzen kann — sondern was er dabei verbraucht, welche Aufräumarbeiten folgen und wie Sie die Defekte finden.

2. Ihre Spezifikation entscheidet, was Sie bekommen. Jeder systematische Fehler führte zurück zu etwas, das meine Tickets nicht sagten; jedes explizit spezifizierte Verhalten wurde nahezu durchgängig korrekt umgesetzt. Eine Spezifikation lenkt Aufmerksamkeit, statt welche hinzuzufügen: Wo Sie nichts vorgeben, entscheidet das Modell selbst. Das ist kein Wasserfall: Spezifizieren, laufen lassen, die Bugs lesen, das nächste Ticket schreiben, wieder laufen lassen.

3. Für die Qualität gilt dieselbe Regel. Ohne Vorgaben lieferten zwölf Agents zwölf verschiedene Implementierungen — von Lehrbuch-Schichtung bis zum 110-Zeilen-Kollisionsmonolithen. Explizite Strukturregeln hoben das schwächste Modell um zwei volle Punkte auf einer blinden Rubrik. Behandeln Sie Qualität als Teil der Spezifikation und machen Sie sie explizit.