KI-Code prüfen: Was grüne Tests noch nicht zeigen.

Lies zuerst den Auftrag und dann die Lösung.

Nehmen wir eine gedachte Erweiterung des Angebotsrechners: Er soll einen Rabatt berücksichtigen. Für dieses Beispiel gilt eine feste Regel. Der Rabatt darf zwischen null und dreißig Prozent liegen und wird einmal auf den ursprünglichen Nettobetrag angewendet. Bei ungültigen Eingaben erscheint eine verständliche Meldung.

Aus 2.508 Euro werden mit zehn Prozent Rabatt genau 2.257,20 Euro. Bei null Prozent bleibt der Betrag unverändert. Ein zweiter Klick auf „Berechnen“ darf den reduzierten Betrag nicht erneut reduzieren. Diese Erwartungen kannst du festlegen, bevor du die Implementierung ansiehst.

Das schützt dich vor einer typischen Verschiebung im Review: Du erklärst dir, warum der vorhandene Code sinnvoll aussieht, und verlierst dabei den eigentlichen Auftrag aus dem Blick. Halte die fachlichen Regeln deshalb als kurze, unabhängige Prüfliste neben der Änderung bereit.

Schau, wie weit die Änderung tatsächlich reicht.

Der Diff zeigt die Unterschiede zum bisherigen Stand. Lies zuerst die Liste der betroffenen Dateien: Wo liegen Berechnung, Eingabeprüfung, Darstellung und Tests? Passen diese Stellen zum Auftrag? Erst danach lohnt sich der Blick auf einzelne Zeilen.

Eine Rabattfunktion braucht eine nachvollziehbare Berechnung. Wenn dabei zusätzlich das Speichern von Angeboten umgebaut oder eine neue Bibliothek eingeführt wurde, solltest du den Grund verstehen. Solche Eingriffe können berechtigt sein. Sie erweitern aber den Umfang dessen, was du prüfen musst.

Achte besonders auf bestehendes Verhalten, das nebenbei verändert wurde. Rechnet die Anwendung weiterhin mit dem ursprünglichen Nettobetrag? Wird ein Fehler jetzt nur noch ausgeblendet? Hat ein Test seine bisherige Prüfung verloren? Eine knappe Zusammenfassung des Agenten ist nützlich, ersetzt den tatsächlichen Diff aber nicht.

Prüfe, was die Tests wirklich behaupten.

Ein Test kann denselben Denkfehler enthalten wie die Funktion. Wenn der erwartete Rabattbetrag mit derselben Berechnungsfunktion erzeugt wird, die gerade geprüft werden soll, fehlt ein unabhängiger Maßstab. Ein grüner Durchlauf bestätigt dann womöglich nur, dass zwei Aufrufe dasselbe Ergebnis liefern.

Für unser Beispiel lässt sich die Erwartung direkt festhalten: 2.508 Euro mit zehn Prozent Rabatt ergeben 2.257,20 Euro. Ergänze passende Grenzfälle. Dreißig Prozent sind erlaubt, ein Wert darüber wird zurückgewiesen. Ein leeres Feld braucht eine ausdrücklich entschiedene Behandlung. Diese Entscheidung sollte der Test nachvollziehbar machen.

Auch der Ablauf verdient einen Test. Erst zehn Prozent eingeben, berechnen und danach noch einmal berechnen: Bleibt das Ergebnis gleich? Ein Test, der jedes Mal mit einem frisch erzeugten Formular startet, könnte eine versehentliche doppelte Rabattierung übersehen.

GitHub weist in seiner Dokumentation zu Copilot Agents darauf hin, dass erzeugter Code geprüft und getestet werden muss und trotz plausibler Form fachliche oder Sicherheitsfehler enthalten kann. Für mein Review ist die Konsequenz: Testausgabe und Abnahmekriterien müssen zusammenpassen. Die Anzahl grüner Tests allein beantwortet die fachliche Frage nicht.

Benutze die Funktion so, wie sie später bedient wird.

Eine korrekt getestete Berechnungsfunktion kann trotzdem falsch an die Oberfläche angeschlossen sein. Vielleicht bleibt nach einer Änderung des Rabatts noch der alte Betrag stehen. Oder eine Fehlermeldung ist vorhanden, aber auf dem Smartphone außerhalb des sichtbaren Bereichs.

Gehe deshalb den tatsächlichen Weg durch: Eingabe ändern, Berechnung auslösen, Ergebnis lesen, Fehler korrigieren. Probiere auch die Tastatur und einen schmalen Bildschirm. Bei einer deutschen Oberfläche gehört die Frage dazu, wie ein Dezimalkomma behandelt wird und ob die Beschriftung dazu verständlich ist.

Wenn die Anwendung Angebote auf einem Server speichert, entsteht zusätzlich eine Grenze zwischen Browser und Backend. Eine Eingabebegrenzung im Formular ersetzt dort keine serverseitige Prüfung. Ob dieser Fall relevant ist, ergibt sich aus der tatsächlichen Architektur. Ein rein lokaler Übungsrechner und eine gemeinsam genutzte Anwendung benötigen unterschiedliche Prüfungen.

Mach aus einem Verdacht einen nachvollziehbaren Befund.

Auch ein zweiter KI-Durchlauf kann beim Review helfen. Gib ihm einen klaren Prüfauftrag und verlange konkrete Stellen, Eingaben und Folgen. Ein Hinweis wie „Hier könnte die Berechnung falsch sein“ ist erst der Anfang einer Prüfung.

Ein brauchbarer Befund wäre: „Nach der zweiten Berechnung wird der Rabatt auf den bereits reduzierten Betrag angewendet. Mit 2.508 Euro und zehn Prozent entstehen dann 2.031,48 Euro statt weiterhin 2.257,20 Euro.“ Jetzt lässt sich die Beobachtung gezielt reproduzieren.

Prüfe solche Hinweise, bevor du sie übernimmst. Ein Review-Werkzeug kann Zusammenhänge übersehen oder ein Verhalten beanstanden, das ausdrücklich gewollt ist. Die fachliche Entscheidung bleibt an den Auftrag und die tatsächliche Anwendung gebunden.

Halte fest, was du geprüft hast.

Am Ende sollte ein anderer Entwickler verstehen können, was sich geändert hat und worauf sich dein Urteil stützt. Nenne die fachliche Regel, die ausgeführten Prüfungen und verbleibende offene Punkte. Eine nicht durchgeführte Prüfung gehört nicht unter „bestanden“.

Du brauchst dafür keinen langen Bericht. Bei einer kleinen Funktion reichen eine verständliche Änderungsbeschreibung, die relevanten Testfälle und eine kurze Notiz zum geprüften Nutzerweg. Bei Eingriffen in Rechte, Speicherung oder externe Dienste wächst der nötige Prüfumfang mit.

Diese Arbeitsweise ist der Kern des Entwickler-Workshops: einen begrenzten Auftrag mit KI-Agenten umsetzen, die Änderung verstehen und das Ergebnis im Code sowie im Browser beurteilen. Der Agent beschleunigt die Umsetzung. Ein gutes Review macht sichtbar, was du tatsächlich übernehmen kannst.

• Die fachlichen Erwartungen sind unabhängig von der Implementierung beschrieben.
• Alle geänderten Dateien lassen sich dem Auftrag oder einer begründeten Voraussetzung zuordnen.
• Die Tests prüfen passende Ergebnisse, Grenzen und relevante Zustandswechsel.
• Der tatsächliche Nutzerweg wurde mit den betroffenen Eingaben ausprobiert.
• Offene Fragen und nicht geprüfte Bereiche sind ausdrücklich benannt.