Eval-first: erst die Checks, dann der Code mit KI

Was eval-first bedeutet, einfach erklärt

Stell dir vor: Du bestellst eine Torte bei einem extrem flinken, aber leicht durchgeknallten Konditor. Sagst du „mach eine Torte“ - macht er eine. Irgendeine. Vielleicht mit Pilzen. Und ist auch noch ehrlich stolz auf sich.

Und jetzt sag es anders: „Schokotorte, für 8 Stücke, ohne Nüsse - ein Gast hat eine Allergie, und die Kerze soll stehen, nicht umfallen“. Merkst du den Unterschied? Der Konditor hat jetzt eine Checkliste, mit der er sich selbst überprüft. Und du prüfst auch - ohne die ganze Torte anzubeißen.

Genau das ist eval-first Eval-first (von engl. evaluation - Bewertung, Prüfung) - ein Ansatz, bei dem du zuerst die Erfolgskriterien und die Art ihrer Prüfung beschreibst und erst dann mit der Arbeit startest. Die Prüfung kommt vor dem Code. : überleg dir zuerst, woran du erkennst, dass es gut geworden ist, und starte erst dann den KI-Agenten. Klingt langweilig. In Wahrheit ist das genau das Geheimnis, warum die KI bei den einen ein funktionierendes Produkt ausspuckt und bei den anderen hübschen Müll.

Wozu ein Vibecoder eval-first braucht

Du bist Vibecoder. Code schreibst du nicht mit der Hand - du stellst dem Agenten Aufgaben und nimmst das Ergebnis ab. Und genau hier, beim „Ergebnis abnehmen“, rettet eval-first dir Nerven und Geld:

• du musst nicht mehr in 12 Dateien starren und denken „naja, sieht ok aus?“ - du hast eine präzise Liste, was funktionieren soll;
• der Agent prüft sich selbst, bevor er das Ergebnis abgibt - weniger Runden im Stil „nein, so nicht, mach nochmal“;
• du erwischst den Moment, in dem ein neues Feature ein altes kaputt gemacht hat (und das passiert öfter, als einem lieb ist);
• du kannst ehrlich „fertig“ sagen - weil „fertig“ jetzt eine Definition hat und nicht nur ein Gefühl.

Der Unterschied zwischen „die KI hat irgendwas gemacht“ und „die KI hat genau das Richtige gemacht“ ist meistens eine einzige Frage, gestellt vor dem Start: „und woran erkennen wir, dass es geklappt hat?“

Wie die eval-first-Schleife funktioniert

In den ECC-Skills heißt das eval-first loop - die Schleife „erst die Checks“. Es sind nur vier Schritte, und die sind simpel:

1. Beschreib die Checks - was funktionieren soll (Capability) und was nicht kaputtgehen darf (Regression).
2. Mach eine Messung „vorher“ - lass die Checks auf der aktuellen Version laufen, halt fest, was jetzt durchfällt.
3. Lass den Agenten arbeiten - jetzt schreibt er Code für ein klares Ziel und nicht auf gut Glück.
4. Lass die Checks erneut laufen - vergleich „vorher“ und „nachher“. Ist es besser geworden? Ist nichts abgefallen?

Im Grunde ist ein Check wie Tests für normalen Code, nur für die Arbeit mit KI. In der ECC-Welt sagt man genau so: Evals sind „Unit-Tests für die Entwicklung mit KI“.

Capability und Regression: neu gegen alt

Die werden leicht verwechselt - deshalb sortieren wir sie sauber.

• Capability Capability Eval - der Check, ob der Agent etwas Neues hinbekommt, das es vorher nicht gab: ein neuer Button, eine neue Funktion, ein neues Feature. (kann es das Neue). Du prüfst, ob das aufgetaucht ist, wofür du das Ganze angefangen hast. Zum Beispiel: „Nutzer registriert sich per E-Mail“, „das Bestellformular wird abgeschickt“.
• Regression Regression Eval - der Check, dass eine neue Änderung nichts kaputt gemacht hat, das schon lief. „Regression“ = Rückschritt, wenn etwas Funktionierendes nicht mehr funktioniert. (hat es das Alte kaputt gemacht). Du prüfst, dass das von gestern auch heute noch läuft. Zum Beispiel: „der alte Login-Button ist noch da“, „die übrigen Seiten öffnen sich“.

Die Metrik pass@k: wie man die Zuverlässigkeit der KI misst

KI ist eine Wahrscheinlichkeitssache: dieselbe Anfrage kommt mal perfekt raus, mal daneben. Deshalb misst man Zuverlässigkeit nicht mit „ja/nein“, sondern mit dem Anteil der Treffer aus mehreren Versuchen. Genau das ist pass@k pass@k - Zuverlässigkeitsmetrik: „hat mindestens einmal von k Versuchen geklappt“. pass@1 - beim ersten Mal. pass@3 - mindestens einmal von drei. pass^3 - alle drei Versuche hintereinander erfolgreich. .

• pass@1 - beim ersten Mal geklappt.
• pass@3 - mindestens einmal von drei Versuchen geklappt.
• pass^3 - alle drei Versuche hintereinander erfolgreich (höhere Latte, für kritische Dinge).

In den ECC-Skills gibt es diese Richtwerte: für neue Features (Capability) - pass@3 ab 90% aufwärts, und für kritische Regressionen - pass^3 = 100%. Alles, was lief, muss immer laufen. Ohne Ausnahmen.

Zerleg die Aufgabe in Häppchen à 15 Minuten

Evals funktionieren nur, wenn sich die Aufgabe prüfen lässt. Ein gigantisches „bau mir einen Marktplatz“ prüfst du nicht auf einen Schlag - da stecken hundert Risiken in einem Topf. Deshalb gibt es im Skill agentic-engineering die 15-Minuten-Häppchen-Regel: zerleg die Arbeit in Einheiten, bei denen jede:

• für sich selbst prüfbar ist, getrennt vom Rest;
• ein Hauptrisiko trägt (und nicht „hier hast du Design, Bezahlung und Datenbank in einem“);
• ein klares „fertig“ hat - man sieht, wann es abgeschlossen ist.

Eval-first am echten Beispiel: das Reservierungsformular

Du bittest den Agenten: „füg auf der Café-Seite ein Tischreservierungsformular hinzu“. Ohne eval-first klatscht der Agent munter ein Formular hin, du schaust drauf - Felder da, Button da, „naja, ok“. Und einen Tag später kommt raus: das Formular schickt leere Anfragen, prüft die Telefonnummer nicht und hat nebenbei das Menü kaputt gemacht gleich daneben.

Und wie würde es ein Vibecoder machen, der’s versteht? Erst die Checks beschreiben - und erst dann arbeiten lassen:

Füg auf der Café-Seite ein Tischreservierungsformular hinzu. Aber zuerst, VOR dem Code, schreib die Checks auf, an denen wir erkennen, dass es fertig ist.
Checks fürs Neue (was funktionieren soll):

Das Formular nimmt Name, Telefon und Anzahl der Gäste an.
Ein leeres Formular kann nicht abgeschickt werden - es erscheint eine verständliche Fehlermeldung.
Ein Telefon ohne Ziffern wird nicht angenommen.
Nach erfolgreichem Absenden ist die Nachricht „Anfrage angenommen“ zu sehen.
Checks fürs Alte (was nicht kaputtgehen soll):

Das Menü auf der Seite öffnet sich weiterhin.
Der „Anrufen“-Button im Header funktioniert.
Die übrigen Seiten öffnen sich wie zuvor.
Dann arbeite so: setz das Formular um, geh anschließend selbst alle Checks durch und schreib neben jeden PASS oder FAIL. Gibt es auch nur ein FAIL - reparier und prüf erneut. Ein Ergebnis mit FAIL gibst du mir nicht ab.

Wer das Ergebnis prüft: Code, KI oder Mensch

Die Prüfung kann man verschiedenen „Richtern“ übertragen - im Skill eval-harness gibt es drei:

• Code-Richter (der zuverlässigste). Eine exakte Prüfung ohne Diskussion: Tests bestanden / Build durchgelaufen / die nötige Zeile ist da. Kannst du es mit Code prüfen - prüf es mit Code.
• KI-Richter (LLM als Bewerter). Wenn „gut“ sich nicht mit dem Lineal messen lässt: „ist der Text angenehm“, „ist die Fehlermeldung verständlich“. Du bittest ein anderes Modell, auf einer Skala von 1 bis 5 zu bewerten.
• Mensch-Richter (du). Für Strittiges und für alles, was mit Sicherheit zu tun hat. Die ECC-Regel ist hart: Sicherheitsprüfungen geben wir niemals komplett an den Autopiloten - das letzte Wort hat der Mensch.

Wie ein PASS/FAIL-Eval-Bericht aussieht

Damit es ganz anschaulich wird - hier ein kurzer Check-Bericht im Stil von eval-harness:

Nachdem du das Formular fertiggestellt hast, gib mir einen kurzen Bericht in dieser Form:
Checks fürs Neue:
nimmt Felder an        - PASS oder FAIL
leeres nicht absenden  - PASS oder FAIL
Telefon wird geprüft   - PASS oder FAIL
Erfolgsmeldung         - PASS oder FAIL
Checks fürs Alte:
Menü öffnet sich       - PASS oder FAIL
Anrufen-Button         - PASS oder FAIL
andere Seiten          - PASS oder FAIL
Am Ende: wie viele von wie vielen bestanden haben. Und der Status: abnahmebereit oder Korrekturen nötig.

Häufige Fehler bei Checks mit KI

• Nur den „Happy Path“ prüfen. Du hast dich vergewissert, dass das Formular läuft, wenn alles richtig eingegeben wurde. Und leere Felder? Und ein krummes Telefon? Echte Menschen geben alles ein, samt Emoji im Feld „Alter“.
• Regressionen vergessen. Du freust dich über das neue Feature und merkst nicht, wie das Alte zerbröselt. Halt immer die Liste „was nicht kaputtgehen darf“ griffbereit.
• Checks NACH dem Code beschreiben. So passt du die Kriterien unbemerkt an das an, was schon rausgekommen ist. Checks denkt man sich strikt vorher aus.
• Eine gigantische Aufgabe durchdrücken. Die kann man nicht am Stück prüfen. Schneide sie in Häppchen à ~15 Minuten mit klarem „fertig“.
• „Fertig“ ohne Definition. „Mach es schön“ - der Agent rät, und du bist hinterher unzufrieden. „Fertig“ = eine konkrete Liste von Haken.
• Sicherheit auf Autopilot geben. Logins, Bezahlung, Zugänge - die finale Prüfung macht immer ein Mensch.
• Prozenten hinterherjagen und den Preis vergessen. Man kann pass@k zur Hochglanz-Perfektion polieren und dabei übersehen, dass jeder Versuch jede Menge Tokens und Zeit frisst. Achte sowohl auf Zuverlässigkeit als auch auf den Verbrauch.