KI-Code prüfen – fünf Instrumente, Lesen ist das teuerste

Die zwei verbreiteten Antworten

Auf die Frage, ob KI-generierter Code noch gelesen werden muss, gibt es zwei verbreitete Antworten. Die erste: jede Zeile lesen, weil nur so verantwortbar ist, was ausgeliefert wird. Die zweite: am Anfang für exakte Vorgaben sorgen, danach genügt das Ergebnis.

Beide Antworten haben einen belegbaren Kern und ziehen daraus den jeweils falschen Schluss. Für die erste gilt: Verantwortung ist nicht delegierbar, wer ausliefert, haftet. Als Verfahren skaliert sie trotzdem nicht, weil eine Änderung von mehreren hundert Zeilen in einem Durchgang nicht sorgfältig prüfbar ist.

Für die zweite gilt: Unklare Vorgaben sind die größte einzelne Fehlerquelle beim Bauen mit KI. Daraus folgt aber nicht, dass die Lösung vorab feststehen muss. Vorgaben werden beim Bauen präziser, und eine Vorgabe enthält keine Aussage darüber, ob sie eingehalten wurde.

Die These

Aus dieser Unterscheidung ergibt sich die Ordnung der Lesson. Wer „jede Zeile" fordert, setzt beim aufwendigsten Instrument an und überspringt die vier günstigeren. Wer auf Prüfung ganz verzichtet, nutzt keins davon.

Die Review-Leiter

Fünf Instrumente, sortiert nach Aufwand. Je weiter oben, desto teurer und desto seltener nötig.

Die Instrumente bauen aufeinander auf und werden von unten nach oben angewendet. Wer bei Instrument 5 beginnt, liest mehr und findet weniger, weil die vier Instrumente darunter genau die Fehlerarten abräumen, die beim Lesen erfahrungsgemäß übersehen werden.

Zwei Zielgruppen, ein Verfahren

Diese Lesson richtet sich an zwei Gruppen. Für Entwicklerinnen und Entwickler beantwortet sie eine Aufwandsfrage: wo sich Lesezeit lohnt und wo nicht. Für alle, die ohne Programmier-Hintergrund mit KI bauen, ist Lesen keine verfügbare Option. Vier der fünf Instrumente sind für beide Gruppen identisch, unterschiedlich wird es erst beim fünften.

Warum Vorgaben nicht vorab feststehen können

Die Forderung nach exakten Vorgaben am Anfang setzt voraus, dass alle nötigen Entscheidungen vor dem Bauen bekannt sind. Das ist selten der Fall. Vorgaben werden am ersten Entwurf präziser, weil sich dort zeigt, welche Annahmen nicht tragen. Wer die Lösung vorab festschreibt, fixiert damit die ungeprüften Annahmen.

Vorab feststehen muss deshalb nicht die Lösung, sondern das Erfolgskriterium: die Beschreibung dessen, woran sich erkennen lässt, dass die Umsetzung funktioniert.

Lösungsvorgabe und Erfolgskriterium im Vergleich

Die Lösungsvorgabe engt ein, veraltet mit der ersten Architekturänderung und lässt sich nicht prüfen. Das Erfolgskriterium überlebt einen kompletten Implementierungswechsel und ist am fertigen Produkt beobachtbar.

Wie du die Liste schreibst

• Fünf bis zehn Wenn-Dann-Sätze vor jedem Meilenstein. Diese Liste ist später Prüfbogen und Testgrundlage in einem, du schreibst sie also nur einmal.
• Negativkriterien mitschreiben. „Kein Social Login", „keine Mehrsprachigkeit". Ohne sie erfindet die KI Umfang, und das tut sie zuverlässig.
• Kriterien pro Meilenstein, nicht fürs ganze Projekt. Genug Vorgabe für den nächsten Schritt, dann nachschärfen.

Meilensteine: die Voraussetzung dafür, dass Prüfen überhaupt geht

Wenn die KI achthundert Zeilen am Stück liefert, ist das kein Review-Problem, sondern ein Prozessproblem. Kein Mensch prüft achthundert Zeilen ernsthaft, egal wie diszipliniert er ist. Die Größe der Änderung entscheidet, ob Prüfen überhaupt möglich ist.

• Eine Änderungseinheit muss in einem Durchgang prüfbar sein. Grob ein Feature, nicht ein Feature-Paket.
• Nach jedem Meilenstein ein lauffähiger, geprüfter, gesicherter Zustand. Ohne Rückfallpunkt ist jede Korrekturrunde ein Risiko.
• Geprüft wird die Veränderung seit dem letzten geprüften Stand, nicht der Gesamtbestand. Das hält den Aufwand konstant, egal wie groß das Projekt wird.

Die Anwendung als Prüfinstrument

Das billigste Prüfinstrument ist die Anwendung selbst: das Programm benutzen und beobachten, was es tut. Es liefert einen großen Teil aller Funde, wird in der Praxis aber selten systematisch eingesetzt, weil ihm eine erkennbare Methode fehlt. Die folgenden drei Durchgänge geben ihm eine.

Drei Durchgänge

1. Happy Path. Erfüllt die Anwendung die Kriterien aus Instrument 1, so wie du sie aufgeschrieben hast? Nicht ungefähr, sondern Satz für Satz.
2. Randfälle. Leere Eingabe, sehr lange Eingabe, Sonderzeichen, doppelte Werte, sehr große Datei, falsche Reihenfolge, Abbruch mittendrin.
3. Böswillig. Was passiert, wenn du etwas tust, das du nicht darfst? Fremde ID in der Adresszeile, Zurück-Button mitten im Prozess, zweimal schnell hintereinander abschicken, Seite mitten im Speichern neu laden.

Warum dieses Instrument so viel findet

KI-generierter Code ist typischerweise stark im Happy Path und dünn in der Fehlerbehandlung. Das Modell baut zuverlässig den Weg, den du beschrieben hast, und deutlich seltener die Wege, die du nicht erwähnt hast. Das ist der reproduzierbarste Fund überhaupt.

Diese Fundstellen begegnen dir immer wieder:

• Fehler werden geschluckt. Leerer Auffangblock, der Fehler landet nur in der Konsole, die Oberfläche zeigt nichts.
• Fehlermeldungen zeigen technische Details statt einer Handlungsanweisung.
• Kein Ladezustand. Ein zweiter Klick löst die Aktion ein zweites Mal aus.
• Erfolgsmeldung ohne Erfolg. Die Bestätigung erscheint, gespeichert wurde nichts.
• Optimistische Annahmen. Das Netzwerk klappt immer, die Datei existiert immer, das Feld ist nie leer.

Warum die Reihenfolge zählt

Alles, was eine Maschine mechanisch findet, hat im menschlichen Review nichts verloren. Welche Werkzeuge das im Einzelnen sind, hängt vom Stack ab und ändert sich. Die Reihenfolge ist davon unabhängig: erst die Maschine, dann der Mensch.

Abhängigkeiten sind ein eigener Prüfpunkt

Der Abhängigkeits-Check ist schnell erledigt und hat eine hohe Trefferquote, wird aber selten gemacht. Er beantwortet eine einzige Frage: Was hat die KI in das Projekt hereingezogen?

• Existiert das Paket überhaupt? Modelle erfinden Paketnamen. Daran hängt ein reales Angriffsmuster: Wer weiß, welche Namen häufig halluziniert werden, registriert sie und liefert darüber Schadcode aus.
• Wann wurde es zuletzt gepflegt, und wie viele offene Sicherheitsmeldungen gibt es?
• Passt die Lizenz zu dem, was du damit vorhast?
• Braucht es das Paket überhaupt, oder wären es zehn Zeilen eigener Code?

Der Zirkularitätsfallstrick

Wenn dieselbe KI den Code und die zugehörigen Tests schreibt, entsteht ein Zirkelschluss. Die Tests sind grün, und das belegt nur, dass beide Seiten dieselbe Annahme teilen. Geprüft wurde die Annahme gegen sich selbst.

Die Auflösung besteht aus drei Bewegungen:

1. Tests kommen aus den Kriterien, nicht aus dem Code. Praktisch heißt das: Leg die Wenn-Dann-Sätze aus Instrument 1 als Testgrundlage vor, statt „schreib Tests für diesen Code" zu sagen.
2. Prüffrage für jeden Test: Würde er rot, wenn die Funktion falsch wäre? Ein Test, der immer grün ist, ist Dekoration.
3. Alarmsignal: Die KI ändert den Test, bis er grün wird, statt den Code zu korrigieren.

Die Anweisung an die KI

Ein Review durch die KI ist wertvoll, aber nur unter drei Bedingungen. Fehlt eine davon, bekommst du Zustimmung statt Prüfung.

Bedingung 1: frisches Fenster

Das Modell, das den Code geschrieben hat, verteidigt seine eigenen Entscheidungen und trägt den ganzen Rechtfertigungskontext mit. Öffne eine neue Sitzung, gern bei einem anderen Anbieter. Vorgelegt werden nur der Code und die Kriterien. Sag nicht dazu, dass es dein eigener Code ist, das dämpft die Kritik.

Bedingung 2: Erklärung statt Bewertung

„Ist der Code gut?" erzeugt Zustimmung. „Erklär mir, was hier passiert" erzeugt eine prüfbare Aussage. Wenn die Erklärung schwammig wird, sich widerspricht oder nicht zu dem passt, was du in Instrument 2 beobachtet hast, hast du deine Fundstelle.

Bedingung 3: konkrete Fragen

„Prüfe den Code auf Fehler" liefert eine generische Liste von Best-Practice-Floskeln, die auf jedes Projekt passt und deshalb auf keins. Konkrete Fragen liefern konkrete Antworten.

Drei Anti-Muster

• Suggestivfragen. „Das ist doch falsch, oder?" bekommt Zustimmung, unabhängig davon, ob es falsch ist. Frag offen.
• Zustimmung als Bestätigung werten. Ein „gute Frage, hier ist alles korrekt" ist kein Prüfergebnis, sondern eine Höflichkeitsformel.
• Zu großer Ausschnitt. Je mehr du auf einmal vorlegst, desto oberflächlicher wird die Antwort.

Welche Zonen vollständig gelesen werden

Es gibt Bereiche, die unabhängig von der Projektgröße vollständig gelesen werden. Es sind in jedem Projekt dieselben, und sie machen einen kleinen Teil des Gesamtbestands aus. Außerhalb dieser Bereiche genügt die Prüfung über Verhalten, weil ein Fehler dort stört, aber keinen Schaden bei anderen anrichtet.

Die Risikokarte

Layout, Formatierung, Darstellungslogik und interne Hilfsfunktionen gehören nicht dazu. Dort genügt die Verhaltensprüfung. Zeile-für-Zeile-Lesen an diesen Stellen bindet die Aufmerksamkeit, die in den sieben Zonen gebraucht wird.

Wie man liest, wenn man liest

• Nicht von oben nach unten, sondern dem Datenfluss folgen. Wo kommt die Eingabe herein, wo wird sie geprüft, wo wird sie verwendet, wo landet sie?
• Auf das achten, was fehlt, nicht auf das, was dasteht. Der häufigste Fehler in KI-Code ist die Auslassung, nicht der falsche Code.
• Veränderungen lesen, nicht Dateien. Was hat sich seit dem letzten geprüften Stand geändert?

Wenn Lesen keine Option ist

Damit ist die Frage für alle beantwortet, die Code lesen können. Für alle anderen gilt eine eigene Regel: Wenn du eine Risikozone nicht lesen kannst, baust du sie nicht selbst.

Konkret bedeutet das, Anmeldung und Zahlungen über fertige Anbieter abzuwickeln und die Rechteverwaltung auf das zu stützen, was das Framework mitbringt. Erfahrene Entwickler treffen dieselbe Entscheidung, weil sie den Bereich verkleinert, der überhaupt gelesen werden muss.

Wie KI-Projekte altern

Gewachsene Projekte werden mit der Zeit unübersichtlich. Bei KI-Projekten geschieht das an einer anderen Stelle als bei handgeschriebenen: nicht im Kern, der schrittweise komplizierter wird, sondern am Rand, wo sich mit jeder Runde zusätzliche Bestandteile ablagern.

• Dieselbe Funktion in zwei Varianten, weil sie in Runde drei neu erfunden statt gefunden wurde.
• Dateien aus verworfenen Ansätzen, die niemand mehr aufruft.
• Konfigurationsreste, auskommentierte Blöcke und als temporär deklarierte Behelfslösungen.
• Drei verschiedene Arten, dasselbe zu tun. Zwei Datumsformate, drei Muster für Fehlerbehandlung.

Zwei Gründe, warum das mehr als Kosmetik ist

1. Duplikate erzeugen Fehler, die du für behoben hältst. Du korrigierst an einer Stelle, die zweite Variante bleibt falsch, und beim nächsten Aufruf ist der Fehler wieder da.
2. Rauschen macht die nächste Runde schlechter. Die KI kopiert die Muster, die sie im Projekt vorfindet. Liegen drei Muster nebeneinander, greift sie irgendeins.

Aufräumen gehört in den Meilenstein

Nicht als Aufräumaktion am Projektende, sondern als fester Bestandteil jedes Meilensteins. Die Frage an die KI ist dabei immer dieselbe:

Der letzte Satz ist wichtig. Das Ergebnis ist eine Vorlage zum Entscheiden, keine Freigabe zum Löschen. Manches Duplikat existiert aus einem Grund, den nur du kennst.

Der Kern der Lesson in einem Satz: Die Review-Leiter wird von unten gestiegen. Vier Instrumente kosten wenig und finden den größten Teil der Fehler. Das fünfte ist aufwendig und gehört deshalb nur an die Stellen, an denen ein Fehler Schaden bei anderen anrichtet.

Die sieben Regeln

1. Lesen ist ein Instrument von fünf und das teuerste. Steig die Leiter von unten.
2. Schreib auf, woran du Erfolg erkennst, nicht wie er gebaut werden soll.
3. Der wertvollste Test ist nicht „funktioniert es", sondern „was passiert, wenn es schiefgeht".
4. Lies erst, wenn die Maschine fertig ist.
5. Lass dir erklären statt bewerten. Eine Erklärung kannst du prüfen, ein Urteil nicht.
6. Nicht jede Zeile, aber die Risikozonen vollständig. Was du dort nicht lesen kannst, baust du nicht selbst.
7. Räum in jedem Meilenstein auf, nicht am Ende.

Der Prüfbogen für einen Meilenstein

Neun Punkte, in dieser Reihenfolge. Für eine Änderungseinheit, nicht für ein ganzes Projekt.

1. Wenn-Dann-Sätze liegen vor, inklusive Negativkriterien.
2. Die Änderung ist klein genug für einen Prüfdurchgang.
3. Ein gesicherter, lauffähiger Rückfallpunkt existiert.
4. Happy Path gegen die Kriterien durchgespielt.
5. Randfälle und böswillige Zugriffe durchgespielt, Funde notiert.
6. Typprüfung, Linter, Tests und Secret-Scan gelaufen, Ausgabe unverändert gesehen.
7. Neue Abhängigkeiten geprüft: existiert, gepflegt, Lizenz passt, wird gebraucht.
8. Alles Unklare in einem frischen Fenster erklären lassen.
9. Betroffene Risikozonen vollständig gelesen oder eingekauft.

Das Reparaturkriterium

Bleibt die Ausgangsfrage: Wie viel musst du eigentlich verstehen? Darauf gibt es eine Antwort, die für beide Gruppen funktioniert.

• Als Entwicklerin oder Entwickler reparierst du selbst. Dafür brauchst du Architektur, Datenfluss und Zuständigkeiten im Kopf. Implementierungsdetails kannst du nachlesen, wenn du sie brauchst.
• Ohne Programmier-Hintergrund musst du wissen, welcher Teil klemmt, was er tun sollte, wo die Daten liegen und wen du fragst. Das ist ohne eine einzige gelesene Zeile erreichbar.
• Wer beides nicht kann, hat kein System, sondern eine Abhängigkeit.

Verantwortung beim Ausliefern

Wer etwas ausliefert, verantwortet es. „Die KI hat das geschrieben" ist im Schadensfall keine Erklärung, die ein Kunde, eine Behörde oder das eigene Team gelten lässt. An dieser Zuordnung ändert die Review-Leiter nichts. Sie verändert nur, auf welcher Grundlage die Verantwortung übernommen wird.

Wohin als Nächstes