Wie bringt ein kleines Modell eine große Aufgabe zu Ende? Alice Moore beschreibt im Firmenblog von Builder.io zwei Experimente, die das Team an seinem eigenen Open-Source-Framework Agent-Native gemacht hat. Der Text ist also ein Erfahrungsbericht des Herstellers über das eigene Produkt. Ein Agent Loop hält einen Coding Agent bei der Arbeit: ein Versuch nach dem anderen, so lange, bis irgendeine Instanz sagt, dass die Aufgabe erledigt ist. Die Schleife ist der einfache Teil.
Die Arbeit steckt in diesem „irgendetwas“. Gemeint ist eine Prüfung, die der Agent selbst ausführen kann und die ihm nach jedem Versuch sagt, ob er näher am Ziel ist. Wer schon einmal einen Ralph Loop oder den Befehl /goal ausprobiert hat, kennt die eine Hälfte des Prinzips: Der Agent hört einfach nicht auf. Die andere Hälfte nennt Geoffrey Huntley Back Pressure – Tests, Builds, Typprüfungen und alles andere, was einen schlechten Versuch zurückweisen kann. Beide Projekte hatten keine Testsuite. Das Team musste sich den Gegendruck selbst bauen.
Als roter Faden hilft eine einfache Vorstellung: der Agent als Lehrling in einer Werkstatt, der ein Maßband in die Hand bekommt. Die Schleife ist die Wiederholung, das Maßband die Prüfung. Erst wenn der Lehrling selbst messen kann, darf er ohne ständige Aufsicht arbeiten.
Was ein Agent Loop leistet und wo die Arbeit steckt
Ein Agent Loop ist unspektakulär: Der Coding Agent macht eine Änderung, führt die Prüfung aus, liest deren Ausgabe und versucht es erneut. Der Wert liegt nicht in der Schleife, sondern in der Qualität des Signals, das sie abbricht. Ohne dieses Signal dreht sich der Loop entweder ewig, oder er hält nach dem ersten halbwegs plausiblen Ergebnis an.
In der Werkstatt-Analogie ist das Maßband wichtiger als die Arme, die es halten. Ein KI-Agent ohne Testsuite steht vor genau diesem Problem: Er kann beliebig oft arbeiten, aber er erfährt nie, ob seine Arbeit besser geworden ist. Ein großer Teil der Konstruktionsarbeit ist deshalb keine Modellfrage, sondern eine Messfrage.
Moore beschreibt zwei Aufgaben, die sich als Lehrstücke eignen, weil bei keiner von beiden eine fertige Testsammlung existierte. Beide enden mit derselben Erkenntnis: Die Verbesserung zwischen den Runden kam fast immer von einer besseren Prüfung, nicht von einem größeren Modell.
Der Pixel-Diff als Maßband für Figma-Importe
Die erste Aufgabe betraf die Importfunktionen von Agent-Native, dem kostenlosen Open-Source-Framework von Builder.io mit zugehörigen Apps. Nutzer wollten Figma-Dateien in Agent-Native Design und Präsentationen in Agent-Native Slides bringen. Die Ergebnisse waren zunächst schlecht: Diagramme zerfielen in lose Einzelformen, Icons verschwanden, eine Folie kam als schwarzes Rechteck heraus. Eine einzige Folie wich in 88 Prozent ihrer Pixel vom Original ab.
Die erste Schleife war die naheliegende: hinschauen, beschreiben, was falsch ist, den Agenten um eine Korrektur bitten, wieder hinschauen. Das funktioniert, aber nur so schnell, wie ein Mensch Folien anschauen kann. Der Agent wusste außerdem nur, was ihm jemand ins Chatfenster getippt hatte. Das Team war der Prüfer und tippte immer wieder Sätze wie „still wrong, the heading moved again“ in den Chat.
Der entscheidende Schritt war die Einsicht, dass jedes importierte File bereits eine richtige Antwort mitbringt: das Original. Statt visuell zu urteilen, rendert man Original und Konvertierung und vergleicht sie mit einem Pixel-Diff. Ein Pixel-Diff vergleicht zwei Bilder und markiert jedes Pixel, das sich unterscheidet. Werkzeuge wie pixelmatch oder ImageMagicks compare erledigen das ohne großen Aufwand.
Die Prüfung lieferte dem Agenten zwei Dinge: eine Zahl und ein Bild, in dem alle Abweichungen rot markiert waren. Die Zahl sagte ihm, ob eine Änderung geholfen hatte. Die rote Markierung sagte ihm, wo er als Nächstes hinschauen sollte. Über ein Wochenende brachte ein kleineres OpenAI-Modell die Abweichung der Problemfolie von 88 Prozent auf 2 Prozent.
Warum das Prüfwerkzeug selbst geprüft werden muss
Ein Agent, der gegen eine Zahl arbeitet, glaubt dieser Zahl. Das ist praktisch, solange die Zahl stimmt, und gefährlich, sobald sie es nicht tut. Genau hier lag die Fehlerquelle: Nicht geladene Schriften ließen einen Export 17 Prozent abweichen, während der tatsächliche Unterschied bei 0,19 Prozent lag. Insgesamt fand das Team vier solcher Fehler in der Prüfung selbst.
Aus diesen Läufen stammt ein Satz, der die ganze Disziplin zusammenfasst: Eine Treue-Zahl ist eine Behauptung über den Konverter, also muss das Prüfgerüst mindestens so vertrauenswürdig sein wie das, was es bewertet. Ein Maßband, das falsch geeicht ist, macht jeden Lehrling schlechter, nicht besser.
Zweitens musste definiert werden, was nicht zählt. Unterschiede in der Schriftdarstellung waren nicht lohnend, also wurden sie ausdrücklich ignoriert. Drittens brauchte die Prüfung echte Beispiele. Ein paar aufgeräumte Musterdateien hätten dem Agenten ein bequemes Durchrutschen erlaubt, deshalb sammelte das Team eine breite Auswahl an Community-Dateien: .fig-Dateien, die Figma-API, PowerPoint, PDF und Google Slides. Jede Änderung wurde gegen das gesamte Korpus bewertet.
Das zahlte sich aus: Die Notizen verzeichnen zwei Korrekturen, die laut Team „made the frame better and the corpus worse“, also eine einzelne Folie verbesserten und das Gesamtergebnis verschlechterten. Beide wurden zurückgenommen. Mit einer belastbaren Prüfung brauchte die Schleife nur noch ein Modell, das nicht aufgab. Es musste nicht das beste sein.
Verwendet wurde Luna, eines der kleineren Modelle von OpenAI, auf der höchsten Einstellung über einen ChatGPT-Pro-Plan. Die grobe Schätzung des Teams: Ergebnisse nahe am Opus-Niveau für ein Zehntel bis ein Zwanzigstel des Preises, und auf diesem Tarif läuft das Modell tagelang ohne Limit. Abweichungen von 20, 40, teils 50 Prozent sanken auf einstellige Werte, oft auf Bruchteile eines Prozents. Import- und Exportprobleme waren nach Angaben von Builder.io zuvor die häufigste Rückmeldung gewesen, mit Dutzenden Berichten pro Tag. Nach dem Loop seien sie ausgeblieben, und Randfälle, die Nutzer später fanden, ließen sich leicht beheben.
Ein zweiter Loop: statische Seite aus Screenshots nachbauen
Um den Teil vor dem Modell sichtbar zu machen, baute das Team einen zweiten Loop von Grund auf – an einer Aufgabe, die sich nachstellen lässt. Der Auftrag: den Kopfbereich eines Blogposts als statische HTML- und CSS-Seite nachbauen, ausschließlich anhand von Screenshots. Der Agent bekam Screenshots in drei Breiten, die Schriften, die Bilder und den Seitentext. Die Prüfung rendert die entstehende Seite in einem Headless-Browser und vergleicht sie mit den Screenshots.
Die Arbeit wurde bewusst geteilt: Ein starkes Modell baut die Prüfung, ein kleines läuft gegen sie. Als starkes Modell diente Claude. Der Prompt, den das Team mit Claude durchging, lautete sinngemäß, ein kleineres Modell solle an dieser Aufgabe arbeiten, bis sie fertig ist. Bevor jemand mit dem Reparieren anfängt, wird die Schleife gebaut, in der es laufen wird. „Fertig“ wird in eine Prüfung übersetzt, die eine Punktzahl oder ein Bestanden/Durchgefallen liefert. Es werden vielfältige, echte Beispiele gesammelt und einige als Holdout zurückgelegt. Die Prüfung muss wiederholbar sein und nachweislich ein bekannt gutes von einem bekannt schlechten Ergebnis unterscheiden. Außerdem werden die Unterschiede aufgelistet, die nicht zählen sollen, dazu ein Budget und Abbruchbedingungen. Das Ganze wird als Brief geschrieben, dem das kleinere Modell ohne Rückfragen folgen kann.
Claude baute daraufhin die Prüfung, einen einseitigen Brief und einen Satz von Testseiten. Die Prüfung fiel durch ihren eigenen Test – zweimal. Die erste Version zählte abweichende Pixel als Anteil des gesamten Screenshots. Da die Seite einen dunklen Hintergrund hat, stimmen die meisten Pixel überein, selbst wenn nichts auf der Seite steht; eine leere Seite kam auf 3 bis 5 Prozent. Nach der Umstellung auf den sichtbaren Inhalt sprang die leere Seite auf 57 Prozent und mehr.
Die zweite Version war zu streng. In der schmalsten Breite ergab eine Verschiebung der ganzen Seite um ein einziges Pixel eine Abweichung von 31 Prozent. Ein solcher Versatz fällt niemandem auf, also lernte die Prüfung, ihn zu verzeihen. Danach passten die Werte zum sichtbaren Eindruck: Original zweimal gerendert ergibt 0 Prozent, alles um ein Pixel verschoben ebenfalls 0 Prozent, eine um drei Pixel versetzte Überschrift 9 Prozent, ein fehlendes Hero-Bild 13 bis 34 Prozent, eine falsche Schrift 41 bis 48 Prozent, eine leere Seite 57 bis 76 Prozent.
Die Bestehensgrenze lag bei 2 Prozent des sichtbaren Inhalts, in jeder Breite. Das entspricht ungefähr einem Button, der vier Pixel daneben sitzt. Zusätzlich behielt das Team Beispiele zurück: Luna arbeitete mit 390, 768 und 1280 Pixeln Breite, die Breiten 1024 und 1440 blieben unter Verschluss. Damit ließ sich prüfen, ob das Modell die Seite gelöst hatte oder nur die Screenshots gelernt.
Vier Runden mit einem kleinen Modell
Der Prompt für Luna war eng gefasst: dem Brief folgen, immer nur eine Änderung auf einmal, danach die Prüfung ausführen und deren Ausgabe lesen. Die Prüfung, die Beispiele und die Toleranzen durften nicht bearbeitet werden. Wer glaubt, eine davon sei falsch, soll anhalten und den Grund erklären. Weiterlaufen, bis die Prüfung in allen Beispielen besteht, das Budget aufgebraucht ist oder es nicht weitergeht. Danach den Holdout-Satz ausführen und die Ergebnisse melden. Über vier Runden hinweg hat Luna die Prüfung nie angefasst – obwohl ein Agent, der eine Zahl senken will, es oft einfacher findet, die Messung zu ändern als den Code.
In Runde eins bekam Luna auf hoher Einstellung ein Budget von 90 Minuten. Der erste Versuch lag bei 41,5 Prozent, nach 34 Minuten hing das Modell bei 16,7 Prozent fest. Die Seite sah dabei fast identisch mit dem Original aus. Der naheliegende Reflex wäre gewesen, dem Modell die Schuld zu geben und ein größeres zu nehmen; geholfen hätte das nicht. Die Prüfung war falsch: Die Toleranz verzieh nur ganze Pixel, halbe Pixel zählten voll. Nach der Korrektur fiel Lunas Seite auf etwa 2 Prozent. Bei 1024 Pixeln Breite, einer Breite, die es nie gesehen hatte, schaltete sie allerdings zu früh auf das volle Menü um und verlor den linken Rand.
In Runde zwei kam eine Zeile in den Brief: Die Seite muss in jeder Zwischenbreite halten. Luna bestand die drei geprüften Breiten in neun Minuten, und der Holdout fiel genau so durch wie zuvor. Das Modell hatte den Satz gelesen, aber keine Möglichkeit, ihn zu überprüfen – also reparierte es, was die Prüfung sehen konnte. Alles, was zählt, muss in der Prüfung stehen, nicht im Brief.
In Runde drei wanderten 1024 und 1440 in die Prüfung; drei neue Breiten wurden zurückgelegt. Luna bestand alle fünf geprüften Breiten in fünf Minuten und fiel bei allen drei neuen durch. Das war der schnellste Durchlauf und das schlechteste Ergebnis. Ein schnelles Bestehen ist ein Grund, genauer hinzuschauen. Der Grund steckte im CSS: Der Menübutton wurde nur zwischen 1024 und 1100 Pixeln angezeigt, gerade genug für die eine sichtbare Breite. Außerdem war der Buchstabenabstand eines Absatzes um 0,03 Pixel verschoben, damit der Text bei 390 richtig umbrach.
In Runde vier orientierte sich das Team an Cheng Lou, der Pretext gegen den Browser selbst prüfte, indem er Claude Code und Codex die Ground Truth des Browsers zeigt und sie bei jeder signifikanten Containerbreite dagegen messen und iterieren lässt, über Wochen. Die Prüfung bekam 28 Breiten, fünf weitere blieben zurück. Luna brauchte 59 Minuten und 55 Prüfläufe, um alle 28 zu bestehen; drei der fünf zurückgelegten Breiten bestanden ebenfalls. Das Ergebnis ist eine Seite, die fast überall richtig aussieht. Das Stylesheet ist eine andere Geschichte: 21 Media Queries, viele davon decken nur 25 bis 50 Pixel ab. Ein Mensch würde ein paar fluide Regeln schreiben. Die Prüfung maß Pixel, und Pixel hat Luna geliefert. Wäre die Qualität des Codes wichtig, und bei echter Arbeit wäre sie das, bräuchte sie laut Moore eine eigene Prüfung.
| Runde | Was geändert wurde | Lunas Zeit | Prüfläufe | Geprüfte Breiten | Zurückgelegte Breiten |
|---|---|---|---|---|---|
| 1 | Erster Lauf | 34 min | 63 | bei 16,7 % hängengeblieben | 0 von 2 bestanden |
| 2 | Halbe-Pixel-Toleranz korrigiert | 9 min | 15 | 3 von 3 bestanden | 0 von 2 bestanden |
| 3 | 5 Breiten geprüft, 3 neue zurückgelegt | 5 min | 6 | 5 von 5 bestanden | 0 von 3 bestanden |
| 4 | 28 Breiten geprüft, 5 neue zurückgelegt | 59 min | 55 | 28 von 28 bestanden | 3 von 5 bestanden |
Was das für eigene Agent-Loop-Projekte bedeutet
Beide Läufe führen zu denselben praktischen Hinweisen. Suche zuerst die richtige Antwort, die bereits existiert: die Ausgabe einer alten Implementierung, das Verhalten des Browsers selbst, Beispiele aus einer Spezifikation, aufgezeichneter Produktionsverkehr oder ein Benchmark, den man schlagen will. Ohne eine solche Referenz bleibt jede Prüfung Geschmackssache, und Geschmackssache kann kein Agent selbst messen.
Über alle vier Runden verbrachte Luna weniger als zwei Stunden mit der eigentlichen Kleinarbeit. Jeder Sprung zwischen den Runden kam laut Moore von einer Änderung an der Prüfung, nicht vom Modell. Daraus leitet sie weitere Regeln ab. Teste die Prüfung, bevor du ihr traust: Dasselbe zweimal gerendert muss null ergeben, bekannt schlechte Ergebnisse müssen schlecht abschneiden, akzeptable gut. Schreib auf, was nicht zählt, sonst verbringt der Agent Stunden mit Rauschen. Nutze echte Beispiele, bewerte jede Änderung gegen den ganzen Satz und halte einige zurück, um zu sehen, ob der Agent das Problem gelöst oder nur die Beispiele gelernt hat.
Alles, was zählt, gehört in die Prüfung, denn der Agent tut, was die Zahl belohnt. Die Prüfung selbst bleibt außer Reichweite: Der Agent soll wissen, dass sie feststeht, und anhalten und erklären, wenn er sie für falsch hält. Das Bauen übernimmt ein starkes Modell, die Kleinarbeit ein kleines. Vor der Punktzahl kommt der Blick auf das Ergebnis, denn ein Stillstand kann an der Prüfung liegen und ein schnelles Bestehen an einer Abkürzung. Und schließlich sollte die Prüfung bleiben: Die finalen Werte werden als Obergrenzen in einen Test übernommen, damit eine spätere Verschlechterung auffällt.
Visuell muss die Prüfung nicht sein. P90-Antwortzeiten, Fehlerraten, überprüfbares Nutzerverhalten, automatisierbare Browser-Abläufe oder schlichte Unit-Tests liefern einem Agenten ebenfalls eine Zahl oder ein Bestanden/Durchgefallen, gegen das er arbeiten kann, ohne nachzufragen. Moore schließt mit der Frage, welche Sache man bisher von Hand prüft und was nötig wäre, um sie zu messen. Der Beitrag endet mit einem Hinweis auf die eigenen Produkte: Wer sehen will, wo der Loop gelandet ist, kann eine Figma-Datei in Agent-Native Design oder eine Präsentation in Agent-Native Slides importieren. Unabhängig geprüft sind die genannten Ergebnisse nicht; es handelt sich um Angaben des Herstellers.
Quelle: builder.io
