KI hat Code billig gemacht. Prüfung ist weiterhin teuer.

💡 Kurzfassung

• Code zu erzeugen ist billig, ihn zu prüfen nicht. KI kann in Stunden eine plausible Implementierung liefern. Architektur, Fehlerbilder, Sicherheit und Betriebsfähigkeit brauchen weiterhin technisches Urteilsvermögen.
• Code Review ist kein Korrekturlesen. Kann der Autor die Begründung einer Änderung nicht erklären, muss der Reviewer sie erst rekonstruieren, bevor er den Code bewerten kann.
• Der Engpass wandert in die Prüfung. KI lässt Teams schneller Code erzeugen, als erfahrene Engineers ihn verifizieren können; die Kapazität für Senior-Reviews wird zur Warteschlange.
• KI überträgt keine Verantwortung. Reichen Sie keinen KI-generierten Code ein, den Sie einem anderen Engineer nicht sicher erläutern könnten.

Heute kam ein Entwickler mit einer kleinen Anwendung zu mir. KI hatte einen großen Teil davon geschrieben. Er hatte das Ergebnis zudem von KI prüfen lassen, in der Hoffnung, offensichtliche Fehler zu finden. Die Bitte war rücksichtsvoll: Könne ich vor dem Produktivgang die abschließende Prüfung übernehmen?

Ich halte das nicht für Faulheit. Aus seiner Sicht war der teure Teil bereits erledigt. Es gab funktionierenden Code, er hatte einen Prüfdurchgang überstanden, und meine abschließende Kontrolle sollte verhindern, dass meine Zeit in die Implementierung selbst fließt.

Das Problem steckte im Ausdruck abschließende Prüfung.

Um zu entscheiden, ob dieser Code sicher auslieferbar war, hätte ich zuerst das Problem verstehen müssen, das er zu lösen vorgab, seine Annahmen, seinen Platz in der Architektur und sein Verhalten, wenn die Realität nicht mehr dem Idealfall folgt. Das sind nicht die letzten zehn Prozent der Arbeit. In manchen Fällen ist es fast die gesamte Engineering-Arbeit.

Codeerzeugung ist nicht mehr der teure Teil

Bei einem klaren Briefing kann ein ausreichend erfahrener Entwickler KI sehr schnell zu einer vernünftigen Implementierung führen. Was früher vielleicht eine Woche gedauert hätte, lässt sich manchmal in zwei konzentrierten Tagen erledigen. Diesen Produktivitätsgewinn sehe und nutze ich selbst.

Die Geschwindigkeit entsteht jedoch nicht nur aus dem Wissen, wie man ein Modell anweist. Der Entwickler liefert ein gedankliches Modell mit, das im generierten Code nicht erscheint: welche bestehende Abstraktion wiederzuverwenden ist, welche Invariante nie verletzt werden darf, wo Validierung hingehört, wie Fehler gemeldet werden sollen, welche Vorgänge idempotent sein müssen, was zu protokollieren ist und was die Betriebsumgebung verträgt.

KI beschleunigt, diese Entscheidungen auszudrücken. Sie hebt die Notwendigkeit dieser Entscheidungen nicht auf.

Erzeugt jemand dieselbe Menge Code, ohne diese Entscheidungen zu treffen, kann der Pull Request aus der Distanz nahezu gleich aussehen. Er kann kompilieren. Er kann Tests haben. Die Ordner können sauber benannt sein. Vor einer Freigabe muss ein Reviewer dennoch Fragen beantworten:

• Gehört dieses Verhalten in diesen Dienst, oder wurde eine Grenze überschritten?
• Bewahrt es die Geschäftsregeln, auf die andere Teile des Systems angewiesen sind?
• Was passiert bei Wiederholungen, Teilausfällen, doppelten Anfragen oder veralteten Daten?
• Umgeht es einen bestehenden Autorisierungs-, Caching- oder Validierungspfad?
• Erzeugt es eine zweite Abstraktion für etwas, das die Codebasis bereits kennt?
• Können wir es im Betrieb beobachten und bei einem Fehler wiederherstellen?

Eine weitere Implementierung zu erzeugen, ist billig. Vertrauenswürdige Antworten auf diese Fragen herzustellen, ist es nicht.

Code Review ist kein Korrekturlesen

Die Formulierung „prüfen Sie es nur kurz“ lässt Code Review wie das Korrekturlesen eines fertigen Dokuments klingen: Das Argument ist vollständig, jemand anderes muss nur einen Tippfehler oder einen holprigen Satz finden.

Ein ernsthaftes Code Review funktioniert anders. Der Reviewer liest nicht nur Syntax. Er prüft die Begründung hinter der Änderung. Warum dieser Ansatz? Warum hier? Welche Alternativen wurden verworfen? Welche Annahmen sind sicher? Wo liegt Unsicherheit? Der Diff ist nur das sichtbare Ende dieses Denkprozesses.

Hat der Autor nachgedacht, kann Review effizient sein. Der Reviewer kann Entscheidungen hinterfragen, einen übersehenen Sonderfall benennen oder Kontext ergänzen, den der Autor nicht hatte. Es gibt ein gemeinsames mentales Modell, das geprüft werden kann.

Hat der Autor diese Denkarbeit nicht geleistet, muss der Reviewer sie aus dem Ergebnis rekonstruieren. Er liest benachbarte Dienste, verfolgt Datenflüsse, erschließt Domänenregeln, prüft alte Vorfälle und klärt, ob die Tests nützliches Verhalten beweisen oder nur die Implementierung bestätigen, die KI zufällig erzeugt hat.

Dann prüft der Reviewer keine Implementierung mehr. Er wird nachträglich zu ihrem Autor.

Deshalb kann das Prüfen und Korrigieren von zwei Tagen schnell erzeugten Codes länger dauern als die richtige Implementierung von Anfang an. Erfahrung verbessert die Risikoerkennung; sie macht das Rückkonstruieren fehlender Absicht nicht kostenlos.

Fehlendes Verständnis wandert zu jemand anderem

Hinter einem Pull Request stand immer ein stillschweigender Vertrag: Die Person, die ihn einreicht, versteht, wofür sie das Team Verantwortung übernehmen lassen will.

Sie muss nicht alles wissen. Review existiert gerade, weil jeder Entwickler blinde Flecken hat. Der Autor sollte jedoch erklären können, warum der Ansatz gewählt wurde, wie er getestet wurde, was scheitern kann und welche Stellen besondere Prüfung verdienen. Auch „Das weiß ich noch nicht“ ist eine gültige Antwort, wenn sie klar ausgesprochen wird. Sie gibt dem Reviewer einen ehrlichen Fokus.

KI ermöglicht es, diesen Vertrag in einem bisher schwer erreichbaren Maßstab zu brechen. Ein Entwickler kann deutlich mehr Code erzeugen, als er persönlich erklären kann. Die Lücke verschwindet nicht beim Öffnen des Pull Requests. Sie wird an die Person weitergereicht, die die Änderung freigeben muss.

Ich schrieb bereits über Verständnisschulden: die Lücke, die wächst, wenn man Code schneller ausliefert, als man ihn versteht. Hier ist das die Teamversion desselben Problems. Eine Person erzeugt die Lücke; der Reviewprozess absorbiert sie leise vor der Produktion. Die Schuld wurde nicht bezahlt. Sie wurde zu ungeplanter Teamkostenlast.

Das ist auch kein Problem von Junior-Entwicklern. Ein erfahrener Engineer kann genau dieselbe Lage erzeugen, wenn er eine große, agentengenerierte Änderung übernimmt, die er nicht gründlich geprüft hat. Erfahrung mag Prompts und Anfangsarchitektur verbessern. Sie verschafft jedoch keine Verantwortung für Code, den niemand verstehen wollte.

Der Engpass wandert zur Verifikation

Vor KI-Coding-Tools war Implementierungszeit ein natürlicher Durchsatzbegrenzer. Eine umfangreiche Änderung zu erzeugen dauerte lange genug, dass Reviewer eine Chance hatten mitzuhalten. Pull Requests wurden trotzdem zu groß, aber drei davon vor dem Mittagessen zu erzeugen, war nicht normal.

Dieser Begrenzer verschwindet. Codeproduktion kann mit Modellen, Agenten und parallelen Aufgaben skalieren. Die Zahl der Senior Engineers, die das System verstehen, skaliert nicht ebenso; ihre Aufmerksamkeit auch nicht.

Misst ein Team Produktivität an erledigten Tickets, geänderten Zeilen oder eröffneten Pull Requests, kann KI die Zahlen glänzend erscheinen lassen, während die Auslieferung langsamer wird. Die Warteschlange ist nur umgezogen. Statt auf Implementierung zu warten, wartet die Organisation auf jemanden, der eine wachsende Menge plausibel aussehenden Codes prüfen kann.

Zwei von Anbietern finanzierte Umfragen aus dem Jahr 2026 deuten darauf hin, dass Teams diesen Prüfdruck spüren. In einem GitLab-Bericht auf Grundlage einer Harris-Poll-Befragung von 1.528 Entwicklern und Technologiekäufern in sechs Ländern stimmten 85 Prozent zu, dass KI den Engpass vom Schreiben von Code zum Prüfen und Validieren verlagert habe. 79 Prozent sagten, individuelle Entwicklerproduktivität sei gestiegen, ohne dass der Gesamtprozess sich im gleichen Maß beschleunigt habe. Eine Sonar-Befragung von mehr als 1.100 professionellen Entwicklern ergab, dass 38 Prozent die Prüfung KI-generierten Codes als aufwendiger als die von Kollegencode empfanden, während nur 48 Prozent angaben, KI-generierten Code vor dem Commit immer zu verifizieren.

Diese Umfragen berichten, was Befragte sagten; sie messen keine Teamleistung direkt. Ihre Ergebnisse bedeuten nicht, dass Code Review in jeder Organisation der Hauptengpass ist. Deployment, Release-Bündelung oder ein anderer nachgelagerter Schritt können in einem bestimmten System dominieren. Die engere Aussage lautet: Wächst der Codeausstoß schneller als Reviewkapazität und gemeinsamer Systemkontext, wird Verifikation zur lokalen Warteschlange.

Das verändert auch die Wirtschaftlichkeit, weniger erfahrenen Entwicklern zu helfen. Jemanden bei einer Entscheidung zu begleiten, ist wertvoll und wirkt langfristig. Seine generierte Implementierung stillschweigend rückwärts zu analysieren, tut das nicht. Ersteres baut einen weiteren Engineer auf, der Verantwortung tragen kann. Letzteres macht aus einem Senior Engineer einen Verifikationsdienst und lässt die ursprüngliche Verständnislücke bestehen.

Generierte Zeilen sind eine Eingangskennzahl. Entscheidend ist, ob das Team die resultierende Änderung erklären, prüfen, betreiben und warten kann.

Verantwortung braucht einen Platz im Prozess

Das ist kein Argument, KI von Junior-Entwicklern oder Codebasen fernzuhalten. Richtig eingesetzt gibt sie weniger erfahrenen Entwicklern schnelleres Feedback und erfahrenen Entwicklern erheblichen Hebel. Sie kann unbekannten Code erklären, Alternativen vorschlagen, Tests erzeugen, Auslassungen finden und repetitive Implementierungsarbeit übernehmen.

Ihr Ergebnis sollte aber der Anfang des Verifikationsprozesses des Autors sein, nicht sein Ende. Das darf nicht nur von individueller Disziplin abhängen. Wollen Teams die Geschwindigkeit von KI nutzen, ohne Senior Engineers in eine Verifikationswarteschlange zu verwandeln, braucht der Reviewprozess einen klaren Zulassungsstandard:

• Bei einer breiten Änderung Grenzen und Einschränkungen vor der Implementierungsgenerierung vereinbaren. Ein kurzes Architekturgespräch ist günstiger, als die Architektur aus einem großen Diff zu rekonstruieren.
• Der Pull Request sollte wichtige Entscheidungen, Annahmen, Fehlermodi, Testnachweise und Unsicherheiten erklären – nicht nur geänderte Dateien zusammenfassen.
• Änderungen müssen klein genug bleiben, damit Autor und Reviewer darüber nachdenken können. Dass KI einen großen Diff erzeugen kann, ist kein Grund, ihn einzureichen.
• Ein Reviewer sollte eine Änderung zurückgeben können, wenn der Autor sie nicht erläutern kann. Das ist weder Gatekeeping noch Bestrafung; die Änderung ist dann schlicht nicht prüfreif.

Meine praktische Regel ist einfach: Reichen Sie keinen KI-generierten Code ein, den Sie einem anderen Engineer nicht sicher erläutern könnten. Das heißt nicht, jede Zeile auswendig zu kennen. Es heißt, Entscheidungen, Annahmen und Folgen so gut zu verantworten, dass Review ein Gespräch statt einer Untersuchung wird.

Ein Reviewer soll helfen, das zu finden, was der Autor übersehen hat. Er sollte nicht entdecken müssen, was der Autor nie zu verstehen versucht hat.

KI kann eine Implementierung entwerfen und sogar ihren eigenen Entwurf kritisieren. Sie kann nicht der Engineer sein, der dem Team begründet sagt: „Das sollten wir ausliefern.“ Diese Verantwortung beginnt beim Autor, nicht beim Reviewer.