Quelle auf.

Ich stelle ChatGPT Fragen, bei denen ich selbst nicht weiß, ob meine Ausgangsannahme stimmt. Statt einer schnellen Antwort soll ChatGPT recherchieren, Quellen prüfen und offenlegen, worauf die Antwort beruht.

Warum ich diesmal frage: In meinen Vibe-Coding-Experimenten kann ich inzwischen nicht nur mehr Code erzeugen lassen. Ich kann auch immer neue KI-Instanzen damit beschäftigen, diesen Code zu prüfen: Security Review, technisches Review, Review des Reviews. Irgendwann muss ich mich fragen, ob das noch Qualität erhöht – oder nur meinen eigenen Blick auf das Ergebnis immer weiter delegiert.

Meine Frage: Welche Regeln müssen wir uns im Umgang mit KI-generiertem Code auferlegen, damit wir nicht mehr Softwareproduktion in Auftrag geben, als wir selbst noch verstehen, prüfen und verantworten können?

Hier ist die Antwort von ChatGPT:

Der nächste Review ist nicht automatisch mehr Kontrolle

Noch ein Security Review. Noch ein technisches Review. Noch ein Review des Reviews.

Das sieht erst einmal gewissenhaft aus. Jede neue Prüfung produziert eine weitere Liste mit Befunden, Prioritäten und grünen Häkchen. Irgendwann ist nur nicht mehr klar, ob die Software besser verstanden wurde oder bloß mehr Text über sie existiert.

Die kurze Antwort auf die Frage lautet: Wir sollten KI-Code nicht an der Menge begrenzen, die ein Mensch Zeile für Zeile lesen kann. Wir sollten ihn an der Menge begrenzen, die wir mit menschlichem Urteil, unterschiedlichen technischen Nachweisen und echter Betriebsfähigkeit abschließen können.

Das ist eine wichtige Korrektur der Ausgangsannahme. Moderne Software enthält schon lange Dinge, die kein einzelner Mensch vollständig gelesen hat: Betriebssysteme, Bibliotheken, Compiler-Ausgaben, generierte Clients, Datenstrukturen. Verantwortung kann nicht bedeuten, alles persönlich nachzuvollziehen. Sie muss bedeuten, zu wissen, welche Aussage durch welche Prüfung gedeckt ist, welches Restrisiko bleibt und wer handeln kann, wenn die Software anders reagiert als erwartet.

Fünf Fragen, die ein grüner Haken gern zusammenklebt

Ich verstehe den Code kann heißen: Ich kann Zweck, Datenfluss, Kontrollpfade und wichtige Fehlermodi dieser Änderung erklären. Das ist eine Erklärung, noch kein Beweis für Korrektheit.

Ich habe den Code reviewt heißt enger: Jemand hat menschenlesbaren Code auf Design, Korrektheit, Wartbarkeit, Sicherheit und Kontext inspiziert. Googles Engineering Practices empfehlen im allgemeinen Fall, jede zugewiesene Zeile anzusehen und zu verstehen. Der Leitfaden kennt aber Ausnahmen, etwa für generierten Code oder klar zwischen mehreren Reviewern aufgeteilte Bereiche. Entscheidend ist, den tatsächlich geprüften Scope sichtbar zu machen. Google: What to look for in a code review [claim-005]

Das Verhalten ist verifiziert ist eine andere Aussage. Ein Compiler, ein statischer Analyzer, ein Integrationstest, ein Fuzzer und ein Canary-Release sehen verschiedene Dinge. Das NIST Secure Software Development Framework trennt deshalb direkte Codeprüfung und toolgestützte Analyse von Tests am ausführbaren Code. Es empfiehlt nicht eine magische Kontrolle, sondern passende Kombinationen. [claim-001, claim-003]

Ich übernehme Verantwortung ist keine weitere Testart. Es ist die Entscheidung, dass die vorhandene Evidenz für diesen Einsatz und dieses Schadenspotenzial genügt. Ein Werkzeug kann Befunde liefern. Es kann nicht für eine Organisation entscheiden, welches Restrisiko akzeptabel ist. Je nach Risiko kann diese Entscheidung bei einem Entwickler, einem Team oder einer besonderen Freigaberolle liegen. Wichtig ist nicht, dass immer dieselbe Person entscheidet, sondern dass Rolle, Befugnis und Eskalationsweg vor dem Merge benannt sind.

Und wir beherrschen den Betrieb zeigt sich erst, wenn etwas schiefgeht: Gibt es Signale, die den Fehler sichtbar machen? Kann der Rollout gestoppt, die Änderung zurückgenommen oder ihre Wirkung begrenzt werden? Ist jemand erreichbar, der diagnostizieren, eindämmen, reparieren oder eskalieren kann? Genau diese Verben stehen im Zentrum von Googles On-Call-Praxis. [claim-013]

Eine Review-Zusammenfassung kann alle fünf Aussagen gleich aussehen lassen. Sie sind es nicht.

Nehmen wir einen kleinen KI-generierten Change an einer Authentifizierungs-Middleware. Verstanden hieße: Jemand kann den Weg vom eingehenden Token über Identität und Rolle bis zur Erlaubnis oder Ablehnung erklären. Reviewt hieße: Eine qualifizierte Person hat unter anderem geprüft, ob fehlende oder ungültige Angaben standardmäßig abgewiesen werden und ob Abhängigkeiten richtig konfiguriert sind. Verifiziert hieße: Von den Anforderungen aus formulierte Tests decken etwa fehlende, abgelaufene, manipulierte und formal kaputte Tokens ab; zusätzliche Analyse sucht nach anderen Fehlerklassen.

Verantwortung beginnt danach, nicht davor: Eine benannte Rolle entscheidet, ob diese Nachweise für das konkrete System genügen. Betriebsbeherrschung zeigt sich schließlich daran, ob Ablehnungsraten und Fehlermuster sichtbar sind, der Change begrenzt ausgerollt wird und sich bei unerwartetem Verhalten stoppen oder zurücknehmen lässt. Ein einzelnes LGTM beantwortet keine dieser fünf Fragen vollständig.

Man muss nicht jede Zeile lesen. Dann muss man etwas Besseres prüfen

Die stärkste Gegenposition zur Ausgangsfrage lautet: Vielleicht ist der menschliche Blick auf jede Implementierungszeile gar nicht die richtige Kontrollinstanz.

Das stimmt in vielen Fällen. Bei einem vertrauten Codegenerator kann es sinnvoller sein, den Generator, seine Eingaben und die Eigenschaften seines Outputs zu prüfen. Bei einer Bibliothek prüfen wir Schnittstelle, Herkunft, Version, Verhalten und bekannte Risiken, nicht jede interne Verzweigung. Bei einem mechanischen Refactoring können Invarianten und Tests mehr aussagen als eine ermüdete Lektüre von tausend verschobenen Zeilen.

Dafür gibt es etablierte Methoden. Bertrand Meyers Aufsatz Applying Design by Contract formuliert Vorbedingungen, Nachbedingungen und Invarianten als explizite Verpflichtungen zwischen einer Komponente und ihren Nutzern. QuickCheck machte Property-Based Testing bekannt: Statt nur einzelne Beispiele einzutragen, formuliert ein Entwickler Eigenschaften – etwa Nach dem Sortieren ist jedes Element höchstens so groß wie sein Nachfolger – und lässt sie an vielen generierten Eingaben prüfen. [claim-017, claim-018]

Beides verlagert Arbeit von der Zeile zur Eigenschaft. Es beseitigt sie nicht. Ein Vertrag kann die falsche Eigenschaft festschreiben. Ein Property-Test kann wichtige Eingaberäume verfehlen. Meyer warnt in seinem Text selbst davor, Design by Contract als unfehlbare Garantie zu lesen; auch das QuickCheck-Paper spricht über Fallstricke.

Die brauchbare Regel lautet deshalb nicht: Wenn du den Code nicht lesen willst, schreibe einen Test. Sie lautet: Wenn du Implementierungslektüre reduzierst, musst du auf einer anderen Ebene präziser werden. Was darf hinein? Was muss herauskommen? Was darf nie passieren? Welche Nebenwirkungen sind erlaubt? Unter welchen Produktionsbedingungen gilt das?

Bei einer CSS-Änderung kann ein Screenshot und ein kurzer Diff reichen. Bei Berechtigungen, Zahlungen, Datenmigrationen oder irreversiblen Aktionen wäre dieselbe Prüftiefe fahrlässig. Das Risiko, nicht die Herkunft des Codes allein, bestimmt die Evidenz.

Die alte Ironie der Automation passt unangenehm gut

1983 beschrieb die Psychologin Lisanne Bainbridge die Ironies of Automation. Automation übernimmt die Routinetätigkeit, lässt den Menschen aber als Rückfalle für seltene und schwierige Ausnahmen zurück. Gerade weil die Routine automatisiert wurde, können Aufmerksamkeit, aktuelles Systemwissen und eingeübte Fähigkeiten fehlen, wenn sie plötzlich gebraucht werden. [claim-016]

Das Paper handelt von industrieller Prozesssteuerung, nicht von Coding Agents. Die Übertragung ist meine Interpretation. Aber die Mechanik ist erkennbar: Eine KI schreibt den Change. Eine zweite erklärt ihn. Eine dritte prüft die Erklärung. Der Mensch wird für den seltenen Moment aufgehoben, in dem alle drei danebenliegen.

Auch die breitere Human-Factors-Forschung mahnt zur Vorsicht. Parasuraman und Manzey fanden in ihrer Auswertung empirischer Studien, dass Automation Bias und Automations-Complacency nicht nur Anfänger betreffen und nicht durch einfache Instruktionen verschwinden. Unvollkommene Entscheidungshilfen können sowohl dazu führen, dass Menschen Probleme übersehen, als auch dazu, dass sie falschen Empfehlungen folgen. [claim-016]

Das beweist nicht, dass ein KI-Code-Reviewer genau denselben Effekt erzeugt. Es gibt der persönlichen Beobachtung aber einen besseren Namen als Faulheit. Die Gefahr liegt nicht nur in zu viel Output. Sie liegt darin, eine aktive fachliche Tätigkeit in passives Beaufsichtigen zu verwandeln und trotzdem dieselbe Verantwortung zu behalten.

Drei KI-Gutachten sind nicht automatisch drei unabhängige Kontrollen

GitHub schreibt in der eigenen Dokumentation zu Copilot Code Review, dass das Werkzeug Probleme übersehen und Fehler machen kann. Sein Feedback soll sorgfältig validiert und durch menschliches Review ergänzt werden. [claim-010]

Was die Recherche nicht belegen konnte: ob zwei oder drei verschiedene Modelle beim Review desselben Diffs ausreichend unabhängige Fehlerprofile haben. Es wäre genauso falsch, immer identische Fehler zu behaupten, wie ihre Unabhängigkeit einfach vorauszusetzen.

Darum sollte ein weiterer Review nur für das zählen, was er tatsächlich neu prüft. Ein Compiler beantwortet eine andere Frage als ein Sprachmodell. Ein statischer Security-Scanner sieht andere Muster als ein Integrationstest. Ein von den Anforderungen aus formulierter Property-Test hat einen anderen Ausgangspunkt als ein Test, den dieselbe KI zusammen mit ihrer Implementierung erzeugt hat. Ein qualifizierter Mensch kann Produktkontext, Architektur und Schadensfolgen beurteilen, die im Repository gar nicht vollständig stehen.

Noch ein Review ist also keine Methode. Frage, Scope und Prüfkanal müssen benannt sein.

Der Engpass braucht eine sichtbare Warteschlange

Hier hilft ein erstaunlich unspektakuläres Konzept aus Lean und DevOps: Work in Progress.

DORA empfiehlt, WIP-Limits an der tatsächlichen Kapazität des Teams auszurichten und dabei auch Produktionssupport und technische Schulden einzurechnen. Kleine Batches verkürzen Feedbackwege; DORA beschreibt sie inzwischen ausdrücklich als wichtigen Stabilisator bei KI-Nutzung. [claim-006, claim-007]

Der Transfer auf KI-Code ist meine Synthese: Ein generierter, aber noch nicht verstandener Diff ist Work in Progress. Ein Security-Bericht mit 38 untriagierten Punkten ist Work in Progress. Ein gemergter Change ohne brauchbare Telemetrie oder Rollback-Weg ist nicht fertig; er hat die Warteschlange nur gewechselt.

Diese Arbeit muss nicht automatisch als KI-generiert erkannt oder in einer neuen Plattform gezählt werden. Ein vorhandenes Board oder ein klarer PR-Status reicht, wenn er sichtbar macht, ob Verständnis, fachliches Review, technische Nachweise und Betriebsabsicherung noch offen sind. Das Limit braucht eine explizite Teamregel, keine erfundene universelle Zahl.

Damit dreht sich die Flussrichtung um. Nicht die KI schiebt so lange Arbeit nach, wie sie Tokens bekommt. Das Team zieht neue Generierung erst dann, wenn die nachfolgenden Stufen wieder Kapazität haben.

Kleine Changes sind dafür mehr als eine Stilfrage. Googles Leitfaden zu kleinen Changes nennt gründlicheres Review, leichteres Schlussfolgern und einfacheres Zurückrollen als Vorteile. Er verweigert vernünftigerweise eine universelle Zeilengrenze: Ein in sich geschlossener Gedanke ist wichtiger als die rohe Zahl. [claim-004]

Sechs Regeln für den Dienstagmorgen

Die folgende Liste ist meine Synthese aus diesen Praktiken, kein neuer Standard und kein eigenes Framework.

Das Prüf- und Betriebsbudget bestimmt das Generierungsbudget. Ungeprüfte Diffs, offene KI-Befunde und noch nicht abgesicherte Rollouts zählen als WIP. Ist die Kapazität erschöpft, wird nicht weiter generiert.
Ein Change bleibt klein und erklärbar. Ein zuständiger Mensch kann Zweck, betroffene Daten, wichtige Abhängigkeiten und wesentliche Fehlermodi benennen. Wo Implementierungslektüre bewusst entfällt, braucht es einen stärkeren Vertrag auf einer anderen Ebene.
Kritische Eigenschaften entstehen vor oder unabhängig von der Implementierung. Akzeptanzkriterien, Invarianten und negative Fälle dürfen nicht bloß nachträglich beschreiben, was der erzeugte Code ohnehin tut.
Jede Prüfung nennt Frage, Scope und Methode. Ein weiterer KI-Bericht ist ein Hinweis, nicht automatisch unabhängige Bestätigung. Mehr Sicherheit entsteht durch unterschiedliche Informationsquellen und Fehlerfindemechanismen.
Die Prüftiefe folgt dem Risiko. Reversible, isolierte Änderungen dürfen stärker über Verhalten abgesichert werden. Security, Berechtigungen, Daten und irreversible Wirkungen verlangen qualifiziertere menschliche und technisch unabhängigere Prüfung. NASA behandelt IV&V für kritische Systeme als risikobasierte Tätigkeit: Analysiert werden bevorzugt die Verhaltensweisen und Komponenten mit dem größten Einfluss auf Sicherheit und Missionserfolg. Die organisatorische Strenge der NASA ist keine Vorgabe für jede Webanwendung; das Prinzip der proportionalen Prüfung ist der übertragbare Teil. NASA SWE-141 [claim-009]
Kein Merge ohne Betriebsantwort. Owner, Beobachtungssignale und ein angemessener Stop-, Rollback- oder Eindämmungsweg sind benannt. Canary-Releases zeigen, wie sich Verhalten unter realer Last mit begrenztem Schadensradius prüfen lässt – und warum auch das kein Vollbeweis ist. [claim-011, claim-013]

Die wichtigste Regel steht zwischen den sechs Punkten: Ein Stoppsignal ist ein Ergebnis. Wenn ich einen Diff nicht erklären kann, einen Befund nicht reproduzieren kann oder keine Kapazität mehr für den Betrieb habe, brauche ich nicht den nächsten Bestätigungsprompt. Ich muss den Change verkleinern, Expertise holen, pausieren oder ihn wegwerfen.

Vielleicht darf am Ende also weiterhin ein Mensch fertig sagen. Aber nicht, weil drei KI-Instanzen nacheinander dasselbe beruhigende Wort gefunden haben. Sondern weil die offene Arbeit klein genug geworden ist, dass jemand wieder eine echte Entscheidung treffen kann.