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

Aufbau und Erkenntnisse: Zwölf KI-Coding-Agents im Vergleich

Ich habe zwölf KI-Coding-Agents exakt dieselbe Aufgabe gestellt: einen Koopa Troopa umsetzen — Nintendos Schildkröten-Gegner aus Super Mario, der sich bei Sprüngen in seinen Panzer zurückzieht und getreten als rutschendes Geschoss durchs Level fliegt — jeweils denselben kompakten Angular-basierten Super-Mario-Klon, basierend auf zwei identischen Tickets und unter derselben automatisierten Agent-Schleife. Anschließend habe ich die Ergebnisse ausgewertet.

Das Szenario entspricht einem Programmierwettbewerb im hauseigenen Kontext — eine einzelne Codebasis, ein Fachbereich, keine belastbare Stichprobe. Mein Ziel war nicht die Erstellung einer Rangliste verschiedener Modelle, sondern ein spürbarer Einblick in das Verhalten einer Agent-Schleife, wenn das darunterliegende Modell gewechselt wird.

Die Anforderungen

Das Grundgerüst ist ein bewusst schlank gehaltener Mario-Klon: ein kachelbasiertes Level, ein Held mit Sprungmechanik und ein bereits existierender Gegner — der Gumba — der als Vorlage dient. Jeder der zwölf Agents erhielt eine unberührte Kopie dieses Codes und zwei GitHub-Issues:

1. koopa-troopa — einen grünen Koopa Troopa implementieren: Bei einem Sprung von Mario zieht er sich in seinen Panzer zurück; berührt man diesen Panzer, setzt er sich in Bewegung; ein rutschender Panzer eliminiert weitere Gegner sowie Mario (mit kurzer Immunitätsphase direkt nach dem Antreten).
2. enemy-bounce — Trifft Mario auf irgendeinen Gegner, wird er zurückgeworfen; hält man in genau diesem Moment die Sprungtaste gedrückt, fällt der Absprung höher aus; zudem darf eine gehaltene Taste niemals wiederholte Sprungauslösungen verursachen (Release-Latch).

Beide Tickets repräsentieren exakt die Art von Arbeit, mit der ich experimentieren wollte: eine neue Funktion, die tief in vorhandenes Verhalten eingreift (Kollisionsabwicklung, Stomp-Logik, Sprungdynamik) statt nur angefügt zu werden, dabei deutlich komplexer als reine CRUD-Demo und mit einem strukturell ähnlichen Referenzmuster direkt daneben. Diese Situation spiegelt die Realität in großen Business-Systemen wider, wo sich neue Anforderungen selten isoliert einfügen lassen, sondern meist neben einer bestehenden, ähnlich gelagerten Lösung entstehen.

Jedes Ticket entsprach in Aufbau und Duktus einem Sprint-Planning-Item: user-zentrierte Beschreibung, klare Scope-Grenzen in beide Richtungen, Given/When/Then-Abnahmekriterien und ein Prüfabschnitt („alle Tests grün, Build erfolgreich"). Das konzeptionelle Feedback vorab habe ich simuliert, indem ein LLM die Rückfragen stellte, die ein menschlicher Entwickler gehabt hätte; die Antworten flossen in einen Abschnitt Design Decisions zurück ins Ticket. Auch das Überarbeiten lief wie in einem Sprint: Bugs aus der ersten Durchsicht wurden einer einzelnen, QA-bezogenen Korrektur angehängt, und jeder Agent startete genau einen zweiten Versuch. Ein fehlerhaftes Sprite in einer Grafikdatei als alleinigen Mangel gab es nicht — die Begründung folgt weiter unten im Text.

Laufumgebung

Jedes Modell arbeitete mit der offiziellen Agent-Implementierung des jeweiligen Herstellers — darunter Claude Code, Codex CLI, cursor-agent, Antigravity und Grok CLI — allesamt in unveränderter Standardkonfiguration. Verglichen werden also keine nackten Modellparameter, sondern die Endprodukte, mit denen Entwickler tatsächlich täglich arbeiten: Modell, Agent, System-Prompt und verfügbare Werkzeuge in einem Paket.

Alle Agents liefen durch dieselbe Orchestrierungs-Laufumgebung, Sandcastle — technisch gesehen eine Ralph-Schleife, bei der der Agent regelmäßig erneut mit seinen eigenen Ausgaben angesetzt wird, bis die Aufgaben überprüfbar erkennbar ist (vier aufeinanderfolgende Schritte pro Iteration: der Planer wertet aktuelle Tickets aus, der Implementator arbeitet das Ticket in einem eigenen Git-Zweig ab und verfasst dazu Tests, ein Reviewer prüft den Diff, und ein Integrator führt die Änderungen zusammen). Die Prozesse simulieren dabei einen normalen GitHub-Workflow — einzelne Issues gehen hinein, Zweige und Kommentare kommen heraus, mitsamt detailliertem Bericht zu Token-Nutzung und Laufzeit je Issue.

Jeder Bauer lief in seiner eigenen Sandbox. Es ging dabei um mehr als etwaige Netzwerk-Beschränkungen: Zwölf Lösungen desselben Problems lagen in benachbarten Verzeichnissen und mussten unabhängig zustande kommen. Bei den zwei Agents, deren Transkripte ich Abschnitt für Abschnitt manuell kontrolliert habe (Grok und Opus 5), trifft das zu — fremder Repo-Inhalt wurde zu keinem Zeitpunkt ausgelesen.

Das Ergebnis

Alle Kennzahlen sind Summen über beide Aufgaben plus anfallender Fehlerkorrektur-Runden, über jede Phase hinweg, aus den von Sandcastle jeweils publizierten Issue-Berichten. Sämtliche Läufe wurden im Juli 2026 ausgeführt.

Die Kosten stehen für den real gemessenen Ressourcenverbrauch des jeweiligen Laufs (neuer Input, Cache-Schreib- bzw. Lesezugriffe, Output-Segmente, alle Phasen und Korrekturversuche), beziffert mit den öffentlich gelisteten API-Preisen — eine standardisierte Preis-Simulation, die nicht garantiert gleichzusetzen ist mit dem, was ein Lauf in der Praxis kostet: Bei Flatrate-Modellen bleiben weitere Läufe ohne zusätzliche Gebühr bis zum Kontingentslimit. Drei Details zur Einordnung: Composers Cache-Lesepreis ist eine Schätzung (kein veröffentlichter Wert), Sonnet ist mit seinem Einzuführungspreis berechnet, und GPT-5.6 wurde mit der Reduktion von Ende Juli bewertet.

Agent (CLI)	Modell	Geschätzte Kosten (API-Listenpreis)	Laufzeit
luna (Codex CLI)	gpt-5.6-luna	$0.21	21 Min.
Gemini Flash-Lite (Antigravity)	Gemini 3.5 Flash (Low)	$2.26	7 Min.
terra (Codex CLI)	gpt-5.6-terra	$2.64	25 Min.
sol (Codex CLI)	gpt-5.6-sol	$2.79	15 Min.
Grok (Grok CLI)	grok-4.5	$2.88	16 Min.
Gemini Pro (Antigravity)	Gemini 3.1 Pro (High)	$2.95	18 Min.
Composer (cursor-agent)	composer-2.5	$6.12	33 Min.
Gemini Flash (Antigravity)	Gemini 3.5 Flash (High)	$6.19	15 Min.
Opus 4.8 (Claude Code)	claude-opus-4-8	$20.60	74 Min.
Sonnet (Claude Code)	claude-sonnet-5	$22.21	135 Min.
Opus 5 (Claude Code)	claude-opus-5	$25.07	72 Min.
Fable (Claude Code)	claude-fable-5	$34.29	67 Min.

Jede Zeile bildet einen sauber abgeschlossenen Lauf von einer unveränderten Startbasis ab. Ich habe die Agents bewertet, wie ein Tech Lead einen Pull Request ansieht: kompletten Diff lesen, sämtliche gemergten Testläufe lokal ausführen und das fertige Level selbst spielen, um das Gegnerverhalten real zu sehen — nur so überhaupt der Grund, warum die „Moonwalk"-Beobachtung weiter unten Platz findet, denn kein Testsatz des gesamten Vergleichsfelds hat sie abgedeckt.

Die Bandbreite ist erheblich: Kostenfaktor 160, Laufzeitfaktor 19. Eine einzelne Zahl verdient besondere Beachtung: Sonnet hat mit Klarheit die meisten Basisdaten verarbeitet — 98 % davon bestanden aus günstigen gelesenen Cache-Daten. Der Grund dafür ist ein Muster: Auf jeder Stufe wird ein stets größerer Kontext läuft erneut mit. Was das Budget sprengt, sind nicht die einzelnen Überlegungsrunden selbst, sondern die Anzahl der Runden multipliziert mit dem, was man an bereits erledigtem Kontext in dieser Runde mitschleppt. Die günstigsten Läufe waren dabei nicht die unbrauchbarsten — der mit Abstand teuerste Aufsteller (Fable) war übrigens gleichzeitig der einzige tadellose. Diese Differenz zeigt: Sorgfalt und hohe Ausgaben sind nicht gleichzusetzen — bei gut ausformulierten Anforderungen in einer kleinen Codebasis sind Laufzeiten zwischen der 7- und 25-Minuten-Marke völlig genügend.

Einen Koopa erstellen können alle. Den richtigen erkennen nur wenige.

Der entscheidende Befund, den vor zwei Jahren noch niemand für denkbar gehalten hätte: Alle zwölf Agents haben einen funktionsfähigen Koopa Troopa vorgelegt — einschließlich vollständiger Zustandsmaschine (laufen → Panzer → rutschen → stoppen), Immunität nach Antreten und Abprall-Bounce mit Release-Latch. Vier Stück erreichten das Ergebnis im allerersten Durchlauf; die restlichen acht haben das ihr Nachkorrektur-Ticket erfolgreich abgearbeitet.

Beim Detailgrad war aber ein anderes Bild, mit einem eindeutigen Fehlerbild: die Sprite-Auswahl. Die Anforderung verlangte, aus einem binären PNG-Spritesheet genau die grafischen Kacheln des grünen Koopa zu extrahieren — „nach Art der vorhandenen Gumba-Kacheln". Das wurde das härteste Einzelproblem des gesamten Projekts — und zugleich der Bereich, in dem auch die Fehlerschleife keine zuverlässige Korrektur mehr erzielen konnte. Acht der zwölf Agents griffen auf falsche Grafikziele zurück und bekamen dafür ein Reparatur-Ticket:

Drei der übrigen (sol, Grok und Opus 5) wählten fehlerhafte Kacheln als ihren einzigen Fehler im gesamten Lauf; terra gab seinem Koopa stattdessen deutlich sichtbare Flügel — auch dies stand ausdrücklich nicht im Scope. Opus 5 traf die beiden Panzer-Grafiken richtig, bezog die Bewegungsbilder aber aus einer komplett falschen Zeile, sodass der Koopa dort als Hammer Bro durchs Level ging. Genau ein Modell hat ohne äußeres Zutun die korrekten Grafikelemente gefunden: Fable — parallel auch das einzige Modell ohne jeglichen Mangel.

Die Bugs trafen meine eigene Specification-Festlegung

Die sichtbaren Fehler ergaben drei klar abgrenzbare Muster. Als ich jedes Muster gegen den tatsächlichen Ticket-Text stellte, änderte sich meine Einordnung darüber, was hier überhaupt gescheitert war.

Das Rückwärtslaufen. Der allerhäufigste Fehler war: Der Koopa bewegte sich nach links oder rechts, sein Blick zeigte in die entgegengesetzte Richtung und er bewegte sich entsprechend rückwärts an den Gegnern vorbei. Mit fast entstand bei jedem Agent, der ein Korrektur-Ticket bekommen hatte.

Nur: Der Ticket-Text nimmt zur Blickrichtung gar keine Position. Sein genauer Wortlaut ist: „Analog zum vorhandenen Gumba implementieren" — der Gumba ist aber achsensymmetrisch und hat keinerlei Spiegelungslogik. Die Agents haben buchstabengetreu eine Referenz nachgebaut hat und dabei stillschweigend eine geforderte Eigenschaft aus dem ausführlichen Original-Text, die in dieser Vorlage gar nicht enthalten war. Das Rückwärtslaufen ist daher kein technisches Modellversagen; es lag in der Schwäche meiner Ausarbeitung.

Der blockierte Panzer. terra lieferte hierbei den einzigen echten Zustandsmaschinen-Fehler: Ein Sprung auf den Reglenden Panzer bewegte diesen nicht. Die beschreibenden Abnahmekriterien beschriften diesen Fall korrekt; doch der formal gehaltene Punkt Design Decisions erwähnte die ruhende Zustandsvariante gar nicht. Genau der Agent, der dieser technischen Anforderung hierauf ein größeres Vertrauen schenkt als dem beschreibenden Fließtext, erzeugt genau terras Fehler — die beiden Textbausteine in meinem eigenen Issue widersprachen sich durch diese Auslassung.

Das positive Kontrastbeispiel. Das Punkte-Rueckgegner dieses Setups beschrieb sein anspruchsvollste Randbedingung — sehr genau definiert: Ein fest gehaltener Spring-Prozess muss das wiederholte Auslösen blockieren — unverzüglich kann elf von zwölf Agents dies korrekt umgesetzt werden; der den Composer zeigte einen Infinitiv-Sprung-Fehler, der in der ersten Korrektur entfernt wurde. Prese in auch immer detailgenauer Text ging, auftretende Fehler blieben gering und konkret umrissen. Dort wo der Text uneindeutig wurde oder gegen sich selbst Widersprüche lieferte, Erkenntnis Lagen Fehler systemisch und mit hoher Übereinstimmung also vor.

Das strukturelle Signal: Die Agents zeigten beim Code-Basteln nicht das eigentliche Problemfeld; sie förderten mit Unsicherheiten aus meinen Texten Gleichzeitig, Nebeneinander in Dutzelfacher Parallelverarbeitung zutage. Eine klassische Programmierer-Überbrückung Unsicherheiten blitzschnell aus dem Umfeld — gerade durch Fachgewicht, ohne dass bewusst. Ein LLM-Agent nimmt Texte restlos beim Wort.

Codequalitativ — Maßstab für die Effektivität mehrerer Agents

In funktionierendem Code steckt selbstverständlich nur eine Grundhürde. Daher entschied ich, auch die Architektur-Klasse empirisch genauer zu erfassen — mit drei das Kerngeschehen unterscheidenden Blickzu schneiden. Ein AST-Werkzeug zerlegte exakt die von Schleifen verarbeitete Funktion.
Das erbrachte unaufgebbare harte Daten zur Lesbarkeit: Funktionsumfang sowie Verschachtelungs­tiefe. Die gesamte vorliegende Version von Testsuiten lief zusätzlich lokal mit Erfüllungsgrad-Analyse der geänderten Instanzlogik — nur Filiale, die von keinem Testbericht auch nur angefasst worden war, notiert mit 0 Punkten, als die dArtsuch Perse Nachweisräume entfallen lasse — was u. a. sonst gerade die Bewohner der weniger testorientierten Kategorie stattlich geglättet hätte. An anderer Stelle für abstrakte Qualitäten konnte man keine direkt im Metrik-Term fassen; der zurate gezogene mit Vorsicht dafür aufgestellt Ein­gang: der Bewertungs­maßstab genannter Blind-Answer-Datei mit „bis fünf Sterne Kategorien" SLAP und klassischen „Kohäsion-Fits" Gericht.

SLAP grenzt ein über die Einheitliche Ebene der Abstraktionstiefe: Innerhalb eines Codeabschnitts sollte jede entscheidende Vor­stellungsspur auf genau einer Durchdringungs­stufe laufen. Jede Funktion spert folgerichtig das Auftrageantein explizit Adress: a) Satz von Operationen, die das Verhalten im erkennbaren Teilaufgaben führen z. B. stompEnemy() b) startKickImmunity() oder c) die feine Antriebs­Detail­kürzel, Innereien auf Elementarbeit an Ein_vert_mechanik. Beides zeitgleich funkt aber genau diese Serie heißt, Code absurd zu wenden: drei klar abgetrennte Bausteine laufen, dann einlofte Massives Rechenblock im Bereich von zwölf Bits einzeln erkl@rbar linear im Meulen-Fall notiert, sogar wieder aufgerufener Tatbestand hineugeflochten — und schon zwingt jener abstrakte Lese­ebene­wechsel mitten in einem Arbeit-Phasen des Unterdruck der fachlichen Denkflughöhe. Zusammenhalt ist in­ als Schwester zweck orientiert: eine genau zentriert kognitive Verantwortlichkeit je operationell greifbar Ergebnis — Namen ist dieses vorzustellende.

Der Bewerbungs-Teiledruck erwarb vor­um ausschließlich anonymisierten Verfahren der über die Nettigkeiten ohne Agent-typische Eigennamen, Pfad-Industrien, Tiefo-Avatar-Vision gespend für Des in- Zirkel-Anhöhl.

In deren Fix gebaut — …ohne formale Vorgabegesten Bandbreite beachtlich, mit spürbarem Abstand — aber an der Unterseite ein 110-Zeilen-Compound annehmen darin auch switch-Verschachtelung plus Pixel-Arithmetik — ist sowohl Versicherungssinn, Anhalten der Architektur-Ausrichtung weit gesteckt: deutliche Richtungs­Ausnahme klar bis zum Fundament-Schichtung-über-ineinander-Wiedergäbe. Die Struktur orientierte sich dabei sehr bewegungsgerecht an der Preistendenz — als Hintergründe, nicht als strikte Regel: dies für Claude-agency auffellen durchweg nicht „oben", zu Ober dem Weg legate a4 der einziges er-Stehrung gehalten im Verlauf Laufwerk, meist Billighandl (Groktor) Landruteng aus mehr Be-Quatschen oft Selbst um der Opus-Meter Kon-Vergünste oder ducht: SOWICHT — Flotte, als die Preismarke überal­wöhnlich fleißige bei Son E be­te­bung von produkturter Code-Metrik gegen einen Aspekt Text-Kount­quantität. son hebe ich n. at two-Test­satz 6-Starr?

Bringt die Qualität durch formale Regeln künftig heim?

Ich nahm den schwächsten Teil des Protokolls und ging zusätzlich den Reproduktions-Schleife hinzu. Konkret fügte ich dem Text explicite Schul-Regeln aus SLAP-, Hilfsausdrücken mit bezeichen­bar­, insbesondere Die Geschäfts­fache, wie der Fall war am Ein Maximal-Wert — Der Grenzwert Grenzwässtolpe ersichtlich (nahe Zahlen)

	Flash-Lite	Flash-Lite + Regeln
Blinder Richter (SLAP / Kohäsion)	2 / 2	4 / 4
Längste Funktion	90 Zeilen	34 Zeilen
Maximale Schachtelung	4	2
Tests / Coverage des neuen Codes	12 / 38 %	10 / 31 %
Geschätzte Kosten (API-Listenpreis)	$2.26	$4.09

Abschluss-Ergebnis: je nach Blickwinkel. Die Struktur resultiert sich um rund zwei Sterne Aufwertung — die Monolithblockade war entfernt, die neue Konstante auch ausnahmslos realisiert, und dies als entspannteste Pflicht: Daran, solche Verstöße für das Evaluieren zu ärztlichen erklärlichem Maß, zeigt die interne Abhärtung durch die Reviewer-Stufe als besonders hilfreich. Zugleich – das oberere Kapitel zur Totalzeit der Oberregion Realisierungsanforderung blieben scheitert, Aufwand nahe dem Doppelnen — und die Tests erheblich: Die erzwungenen Gesetze äußern sich nichts Näheres zum Testen, also versiegende Band Aufmerksamkeit programmatisch wanderte und Stille aus dem Tests-Zweig abzog. Regeln ziehen die Kernschlaufe scharf, inhaltlich fehlt die Vorgabe → Knoblätt sind jene Effekte, die nicht auf Regeln gelaufen

Drei Erkenntnisse, die sich bewährt haben

1. Das Grundniveau liegt höher, als viele Teams annehmen. Ein zustandsbehaftetes Feature aus der Spielmechanik wurde von zwölf Agent-Stacks jeweils innerhalb eines normalen Bugfix-Zyklus funktionierend ausgeliefert. Die Frage ist nicht mehr, ob ein Agent Ihr Ticket erledigen kann — sondern was er dabei aufwendet, welche Bereinigungen notwendig sind und wie Sie die Fehler lokalisieren.

2. Ihre Vorgaben bestimmen das Ergebnis. Jeder systematische Fehler ließ sich auf etwas zurückführen, das in meinen Tickets nicht erwähnt war; jedes explizit spezifizierte Verhalten wurde nahezu ohne Ausnahme korrekt umgesetzt. Eine Spezifikation kanalisiert die Aufmerksamkeit, anstatt sie zu erweitern: Wo Sie nichts festlegen, übernimmt das Modell die Entscheidung.

Allerdings ist dies ausdrücklich keine Empfehlung für den Wasserfall-Ansatz. Die agilen Prinzipien bleiben auch hier anwendbar: Tickets mit User Stories und Akzeptanzkriterien lassen sich sowohl von Menschen als auch von KI-Systemen effektiv bearbeiten, eine Konversation mit der KI deckt Unklarheiten und notwendige Designentscheidungen auf, und über mehrere Iterationen hinweg arbeitet man sich schrittweise an das Ziel heran.

3. Dasselbe Prinzip gilt für die Qualität. Ohne spezifische Anforderungen lieferten zwölf Agents zwölf verschiedene Umsetzungen — von der Musterlösung mit klarer Schichtung bis hin zu einem Kollisions-Monolithen mit 110 Zeilen. Explizite Regeln zur Struktur hoben das schwächste Modell um zwei volle Punkte auf einer blinden Bewertungsskala. Behandeln Sie Qualität als Bestandteil der Spezifikation und definieren Sie sie ausdrücklich.