Qualität, die nicht verhandelbar ist: automatische Prüfungen für KI-generierten Code

Teil 3 von 3 der Serie „KI-Entwicklung mit Leitplanken“. Teil 1: Spezifikation vor Code · Teil 2: Kontextdateien

Bevor es KI-Agenten gab, habe ich auf diesem Blog über PSR-2 und über PHPUnit-Tests geschrieben. Einheitlicher Stil, Tests für jede Funktion, Code, den ein Kollege in zwei Jahren noch versteht. Das war über viele Jahre mein Handwerk.

Bei bauernjobs.de, das ich seit Oktober 2023 fast vollständig mit KI entwickle, habe ich das eine Zeit lang vergessen. Der Code entstand schnell, er funktionierte meistens, und ich habe im Browser geprüft statt mit Tests. Irgendwann habe ich mich gefragt: Warum gelten meine eigenen Standards nicht, nur weil eine Maschine schreibt?

Die Antwort war nicht, den Code wieder selbst zu schreiben. Die Antwort war, die Standards so aufzuschreiben, dass eine Maschine sie prüft.

Warum Regeln allein nicht reichen

In den ersten beiden Teilen ging es um Spezifikationen und Kontextdateien. Beide sagen dem Agenten, was er tun soll. Keine von beiden stellt sicher, dass er es tut.

KI-Agenten haben eine bekannte Schwäche: Sie wollen fertig werden. Wenn ein Test fehlschlägt, ist der kürzeste Weg zu „grün“ manchmal nicht, den Fehler zu beheben, sondern den Test anzupassen. Eine Warnung der statischen Analyse lässt sich mit einem Kommentar unterdrücken. Eine Schwelle lässt sich in der Konfiguration senken.

Ein Mensch macht das auch, aber seltener und mit schlechtem Gewissen. Ein Agent macht es mit derselben Sicherheit wie alles andere. Deshalb müssen die Prüfungen außerhalb des Agenten laufen, bei jedem Commit, und der Agent darf sie nicht ändern.

Was bei bauernjobs.de geprüft wird

Die Ausgangslage im September 2026 war ernüchternd. Es gab Tests und seit März eine CI-Pipeline, aber lokal ließ sich die Testumgebung nicht mehr starten, der Frontend-Build brach ab, und die CI lief mit anderen PHP- und PostgreSQL-Versionen als die Produktion. Grüne Tests in der CI sagten also wenig darüber, was auf dem Server passiert.

Anfang Oktober 2026 habe ich das in wenigen Tagen umgebaut:

1. Gleiche Versionen überall. Lokal, in der CI und in Produktion laufen dieselbe PHP- und dieselbe PostgreSQL-Version. Ein Test, der in der CI grün ist, sagt jetzt etwas über die Produktion.

2. Formatierung nach PSR-12, automatisch. Laravel Pint prüft bei jedem Commit über einen Git-Hook und noch einmal in der CI. Der erste Lauf hat 93 Dateien umformatiert. Seitdem gibt es keine Diskussion mehr über Stil, und KI-generierter Code sieht aus wie der Rest.

3. 90 % Testabdeckung als harte Grenze. Die CI bricht ab, wenn die Zeilenabdeckung unter 90 % fällt. Das ist keine Empfehlung, sondern ein roter Build.

4. Statische Analyse mit Psalm. Level 5, mit einer Baseline: Die bestehenden Befunde sind eingefroren, neuer Code muss sauber sein. So wird es jeden Tag besser, ohne dass man erst monatelang Altlasten abarbeiten muss.

5. Der Build muss zum Code passen. Die kompilierten CSS- und JavaScript-Dateien sind im Repository. Die CI baut sie neu und schlägt fehl, wenn sie vom eingecheckten Stand abweichen. Ohne diese Prüfung fehlen neue Tailwind-Klassen in Produktion, sobald jemand vergisst, neu zu bauen, und ein Agent vergisst das gern.

6. Browsertests mit Playwright. Für das, was ein Feature-Test nicht sieht, angefangen mit dem Bearbeiten von Stellenanzeigen.

Was die Tests gefunden haben

Der interessante Teil war nicht die Konfiguration. Es war der Tag, an dem der Agent die fehlende Abdeckung auf 90 % bringen musste. Um Code zu testen, muss man ihn ausführen, und dabei fiel auf, was seit Monaten nicht funktionierte:

Abmeldelinks in Marketing-E-Mails funktionierten nicht. Wer sich abmelden wollte, konnte es nicht. Das ist nicht nur ärgerlich, sondern rechtlich ein Problem.
Kampagnen gingen nicht an alle Adressen eines Kontakts, sondern nur an eine.
Verifizierte Nutzer landeten nach der Anmeldung auf einer 404-Seite, weil die Weiterleitung die Sprache in der URL vergaß.
Gäste wurden auf die Anmeldeseite in der falschen Sprache geschickt.
Job-Alerts zeigten den Titel in der Originalsprache statt in der Sprache des Empfängers, und das auf einer Plattform, deren Kern die Übersetzung ist.
Zahlungs-Webhooks ohne Signatur wurden nicht sauber mit einem Fehlercode abgewiesen.

Keiner dieser Fehler hat eine Fehlermeldung erzeugt. Alle waren im Browser schwer zu sehen. Alle standen im Code, den die KI geschrieben und den ich „getestet“ hatte, indem ich durchgeklickt habe.

Die Regel, die alles zusammenhält

In der Änderung, mit der bauernjobs.de die Testumgebung wiederhergestellt hat, steht ein Satz, den ich inzwischen in jedes Projekt übernehme: „Keine abgesenkten Prüfungen.“

Konkret heißt das für den Agenten:

Schwellenwerte werden nicht gesenkt, auch nicht vorübergehend.
Ein fehlschlagender Test wird nicht angepasst, bis feststeht, ob der Test oder der Code falsch ist.
Neue Unterdrückungen der statischen Analyse brauchen eine Begründung, die ich lese.
Die Psalm-Baseline wird nicht neu erzeugt, um neue Befunde verschwinden zu lassen.
Eine Aufgabe ist erledigt, wenn die Pipeline grün ist, nicht wenn sie abgehakt ist.

Dasselbe auf dieser Website

ghinea.net läuft nach denselben Regeln, mit zwei Ergänzungen. PHP Insights prüft Komplexität und Architektur gegen feste Untergrenzen und schlägt bei bekannten Sicherheitslücken in Abhängigkeiten fehl. Und jede öffentliche Seite geht durch den W3C-Validator, denn eine Seite mit ungültigem HTML wird von Suchmaschinen und Screenreadern anders gelesen, als sie aussieht.

Rund 350 Tests, 90 % Abdeckung, Psalm, PHP Insights, HTML-Validierung, alles in der CI mit den Versionen des Produktionsservers. Der Code dieses Artikels selbst ist durch diese Prüfungen gelaufen.

Was Sie daraus mitnehmen können

Wenn Ihr Team mit KI entwickelt, fangen Sie nicht mit dem perfekten Setup an. Fangen Sie mit diesen drei Schritten an:

Gleiche Versionen in CI und Produktion. Sonst prüfen Sie das falsche System.
Eine Abdeckungsgrenze, die den Build bricht. Setzen Sie sie dort, wo Sie heute stehen, und erhöhen Sie sie schrittweise. Nie senken.
Statische Analyse mit Baseline. Alte Befunde einfrieren, neue verbieten.

KI macht Code billig. Sie macht aber nicht billig, herauszufinden, ob er stimmt. Das erledigen Prüfungen, die jeden Commit sehen und sich nicht überreden lassen.

Sie wissen nicht, wie es um die Qualität Ihrer Codebasis steht, ob von Hand oder mit KI geschrieben? Mein Legacy Audit liefert in zwei Wochen eine priorisierte Liste: was kritisch ist, was warten kann und welche Prüfungen Sie dauerhaft absichern. 30-Minuten-Gespräch buchen