Vibe-Coding-Genauigkeit ist eine Messung, keine Eigenschaft des Modells
Zwei Teams mit demselben Modell kommen zu sehr unterschiedlichen Ergebnissen, denn die Genauigkeit auf der Ebene, die Sie interessiert, entscheidet sich nach der Generierung. Hat überhaupt jemand nachgeprüft? Woran gemessen? Wie schnell kam ein falsches Ergebnis zur Korrektur zurück?
So betrachtet lautet die Frage nicht mehr „Welches Modell ist am genauesten?“, sondern „Wie sieht meine Feedback-Schleife aus?“, und die haben Sie selbst in der Hand.
Was sich zu messen lohnt
Tritt das beschriebene Verhalten ein?
Die einzige Definition von korrekt, die den Kontakt mit einem Nutzer überlebt.
Gemessen wird, indem Sie den Ablauf durchlaufen, nicht indem Sie den Code lesen.
Funktioniert noch, was gestern funktionierte?
Sobald die erste Woche vorbei ist, zählt die Regressionsrate mehr als die Genauigkeit beim ersten Versuch.
Etwa jede fünfte Feature-Änderung macht etwas kaputt, das vorher funktioniert hat.
Wie lange dauert es bis zu einem korrekten Ergebnis?
Die Zahl der Versuche bis Grün ist aussagekräftiger als bestanden oder durchgefallen im ersten Anlauf.
Sie erfasst das, was Sie tatsächlich spüren: wie lange die Schleife dauert.
Die Falle: Tests vom selben Autor
Der naheliegende Weg, Genauigkeit zu messen, ist, den Agenten Tests schreiben zu lassen und zu schauen, ob sie bestehen. Das ergibt eine Zahl, die fast immer hoch ist und sehr wenig bedeutet. Ein Test, der aus denselben Annahmen entsteht wie die Implementierung, stimmt ihr schon von der Konstruktion her zu, auch dort, wo beide falsch liegen.
Eine Genauigkeitsmessung braucht eine unabhängige Prüfung. Etwas, das das Produkt am beabsichtigten Verhalten misst und nicht an der Vorstellung, die der Code von sich selbst hat.
Die Messung aufsetzen
Beschreiben Sie in einfacher Sprache die Abläufe, die für Ihr Produkt „korrekt“ definieren, bevor die nächste Änderungsrunde ansteht. Lassen Sie sie gegen die deployte App laufen. Der erste Durchlauf liefert Ihnen eine Baseline, jeder weitere ein Regressionssignal.
Dafür brauchen Sie kein Terminal. Legen Sie im TestSprite-Dashboard ein Projekt an, beschreiben Sie die Prüfung in einfacher Sprache und richten Sie sie auf Ihre App. Entwickler in Ihrem Team können dasselbe über die Kommandozeile steuern, wenn ihnen das lieber ist, zu finden im CLI-Repository.
Ein Datenpunkt, den Sie kennen sollten
In einem öffentlichen Leaderboard, in dem Coding-Agenten dieselbe Anwendung gebaut haben, lieferte das günstigste Modell im Feld die korrekteste App, sofern eine Verifikationsschleife vorhanden war, und das zur Hälfte der Kosten des teuersten Beitrags. Interessant ist nicht die Platzierung. Interessant ist, dass die Schleife mehr ausgemacht hat als das Modell, also genau das Gegenteil dessen, worum sich die Diskussion über Genauigkeit sonst dreht.
Wozu die Zahl eigentlich gut ist
Genauigkeitswerte werden meist erhoben, um eine Frage zu beantworten, die niemand gestellt hat, etwa ob das Modell gut ist. Die nützliche Frage ist enger gefasst: Kann ich das mergen.
Das rückt die Messung zurecht. Sie brauchen keinen Wert über Ihr gesamtes Produkt hinweg, Sie müssen wissen, ob diese eine Änderung etwas kaputt gemacht hat, das vorher funktioniert hat. Eine Handvoll Prüfungen für die Abläufe, auf die es ankommt, gegen den deployten Build ausgeführt, beantwortet das in Minuten. Ein umfassender Benchmark beantwortet eine andere Frage, und dafür braucht er eine Woche.
Es ändert auch, was eine schlechte Zahl bedeutet. Ein sinkender Genauigkeitswert in einem Benchmark ist interessant. Ein konkreter Ablauf, der gestern funktioniert hat und heute nicht mehr, ist umsetzbar, und das Zweite ist es, was verhindert, dass Fehler bei den Nutzern ankommen.
Machen Sie die Messung kontinuierlich
Eine einmalige Messung sagt Ihnen etwas über einen einzigen Moment. Genauigkeit ist die Eigenschaft eines laufenden Prozesses, deshalb gehören die Prüfungen an jede Änderung.
Zwei Wege, und die Wahl hängt vor allem daran, wem die Pipeline gehört. Die Anbindung der GitHub App über das Dashboard erfordert überhaupt keine Änderung an Ihrem Repository, denn sie reagiert auf das Deployment, das Ihr Build ohnehin erzeugt. Ein Schritt mit GitHub Actions bringt die Prüfung dorthin, wo sie wie der Rest des Builds reviewt wird, ins Repository.
Genauigkeit zu etwas machen, das Sie messen
TestSprite ist die unabhängige Prüfung, die diese Messung braucht. Es misst Ihr deploytes Produkt an dem Verhalten, das Sie beschrieben haben, und nicht an der Vorstellung, die der Code von sich selbst hat. Genau das gibt der Zahl Bedeutung, wenn Implementierung und Tests vom selben Agenten stammen.
In der Praxis beschreiben Sie einmal die Abläufe, die für Ihr Produkt „korrekt“ definieren, und sie laufen bei jeder Änderung mit. Der erste Durchlauf ist Ihre Baseline. Jeder weitere beantwortet die Frage, die Sie wirklich haben: ob diese Änderung etwas kaputt gemacht hat, das gestern noch funktioniert hat.
Damit haben Sie die beiden Zahlen, die sich zu verfolgen lohnen: die Regressionsrate pro Änderung und die Zahl der Versuche, bis wieder alles grün ist. Beide bewegen sich, sobald die Schleife enger wird, und keine von beiden lässt sich dadurch aufblähen, dass man mehr Tests schreibt.
Welches Modell ist beim Vibe Coding am genauesten?
Für die meisten Teams die falsche Frage. Ob Sie verifizieren oder nicht, macht einen größeren Unterschied als der Abstand zwischen den aktuellen Spitzenmodellen.
Kann ich Genauigkeit messen, ohne Tests zu schreiben?
Ja. Beschreiben Sie die Abläufe in einfacher Sprache und lassen Sie sie gegen die App laufen. Sie messen Verhalten, und um Verhalten zu beobachten, braucht es keinen Testcode.
Was ist ein guter Genauigkeitswert?
Produktübergreifend gibt es keinen brauchbaren Vergleichswert. Verfolgen Sie stattdessen Ihren eigenen Trend: Regressionsrate pro Änderung und Versuche bis zu einem korrekten Ergebnis. Beide sollten sinken, je enger die Schleife wird.
Bedeutet mehr Abdeckung mehr Genauigkeit?
Nicht verlässlich. Abdeckung zählt, was ausgeführt wurde, nicht, ob die Erwartungen richtig waren. Eine große Suite generierter Tests kann hohe Abdeckung über den falschen Annahmen ausweisen.
Wie oft sollte ich neu messen?
Bei jeder Änderung, automatisch. Nach Zeitplan gemessene Genauigkeit sagt Ihnen etwas über den Zeitplan, nicht über die Änderung, die etwas kaputt gemacht hat.
Genauigkeit ist Ihre Schleife, nicht Ihr Modell.
Vibe-Coding-Genauigkeit ist etwas, das Sie an Ihrem eigenen Produkt messen: Tritt das beschriebene Verhalten ein, funktioniert noch, was gestern funktionierte, wie lange dauert es bis zu einem korrekten Ergebnis. Nutzen Sie eine unabhängige Prüfung statt Tests vom selben Autor, und messen Sie bei jeder Änderung.