KI hat Code billig gemacht. Das Prüfen bleibt teuer.

💡 Kurzfassung

• KI beschleunigt die Umsetzung. Architektur, Sicherheit und das Verhalten bei Fehlern müssen weiterhin geprüft werden.
• Kann der Autor seinen Code nicht erklären, entsteht zusätzliche Arbeit für die prüfende Person. Bei höherem Tempo kann sich diese Arbeit stauen.
• Mehr Code kann höhere Kapazität bedeuten, wenn Qualität und Wartbarkeit erhalten bleiben. Das Team muss das wachsende System weiterhin verstehen können.

Heute kam ein Entwickler mit einer kleinen Anwendung zu mir. Er hatte einen großen Teil des Codes von KI schreiben und anschließend auf offensichtliche Fehler prüfen lassen. Vor dem Produktivstart sollte ich noch einmal abschließend darauf schauen.

Ich halte das nicht für Faulheit. Aus seiner Sicht war der teure Teil erledigt: Der Code war da, die erste Prüfung abgeschlossen. Er bat um eine kurze letzte Kontrolle.

Für eine Freigabe hätte ich jedoch zunächst verstehen müssen, welches Problem die Anwendung löst, welche Annahmen sie trifft und wie sie sich bei Fehlern verhält. In dieser „letzten Kontrolle“ kann fast die gesamte Entwicklungsarbeit stecken.

Die Entscheidungen hinter dem Code bleiben nötig

Ein erfahrener Entwickler mit einer klaren Aufgabe kann mit KI deutlich schneller vorankommen. Was früher vielleicht eine Woche gedauert hätte, lässt sich manchmal in zwei konzentrierten Tagen erledigen. Auch ich nutze diesen Zeitgewinn in meiner Arbeit.

Ein Teil des Gewinns entsteht, weil der Entwickler das System bereits kennt. Er weiß, welche vorhandene Lösung sich nutzen lässt, welche Geschäftsregeln gelten und was die Produktionsumgebung verkraftet. KI beschleunigt die Umsetzung dieser Entscheidungen.

Auch Code, der ohne diese Überlegungen entsteht, kann kompilieren, Tests bestehen und ordentlich aussehen. Vor einer Freigabe braucht es trotzdem Antworten:

• Gehört die Änderung in diesen Dienst? Wird eine bereits vorhandene Lösung nochmals gebaut?
• Bleiben die Geschäftsregeln gewahrt? Werden Berechtigungsprüfungen, Caching oder die Prüfung von Eingaben umgangen?
• Was passiert bei doppelten Anfragen, veralteten Daten oder einem Teilausfall?
• Lässt sich das Verhalten im Betrieb anhand von Protokollen nachvollziehen? Können wir das System nach einem Fehler wiederherstellen oder die Änderung zurücknehmen?

Funktionierender Code liefert diese Antworten nicht automatisch mit.

Im Review prüfen wir auch die Überlegungen

Bei einem Code-Review geht es um die Überlegungen hinter einer Änderung. Warum dieser Ansatz? Welche Alternativen wurden verworfen? Welches Verhalten prüfen die Tests, und welche Risiken bleiben offen?

Kann der Autor seine Entscheidungen erklären, ergänzt die prüfende Person fehlenden Kontext oder findet einen übersehenen Fehlerfall. Kann er es nicht, muss sie zunächst Datenflüsse verfolgen und Geschäftsregeln aus dem vorhandenen Code erschließen. Erst wenn die Begründung rekonstruiert ist, lässt sie sich bewerten.

Deshalb kann es länger dauern, zwei Tage lang generierten Code zu verstehen und zu korrigieren, als die richtige Lösung von Grund auf zu schreiben. Erfahrung hilft, Risiken zu erkennen. Sie ersetzt die übersprungenen Überlegungen nicht.

Wer eine Änderung zur Prüfung einreicht, also einen Pull Request erstellt, muss nicht alles wissen. Die Person sollte aber ihren Ansatz, ihre Tests und ihre Unsicherheiten erklären können. Ein klares „Bei dieser Stelle bin ich noch nicht sicher“ lenkt die Prüfung auf das Wesentliche.

Über Verständnisschulden habe ich bereits geschrieben: die Lücke zwischen dem Code, den wir erzeugen, und dem, den wir tatsächlich verstehen. Im Review wird es zur Aufgabe eines anderen, diese Lücke zu schließen. Die Schuld wechselt den Besitzer, bevor sie beglichen ist. Für das Team entsteht ungeplanter Aufwand.

Auch erfahrene Entwickler verursachen diese Belastung, wenn sie große KI-generierte Änderungen einreichen, die sie nicht verstanden haben. Eine Entscheidung gemeinsam durchzuarbeiten, stärkt die Fähigkeiten im Team. Generierten Code stillschweigend zu entschlüsseln und zu reparieren, kann die Verständnislücke beim Autor bestehen lassen.

Wer versteht den zusätzlichen Code?

Simon Willisons Überlegungen zur konzeptionellen Integrität ergänzen zwei Punkte. Mehr Code kann ein echter Gewinn sein, wenn Qualität, Tests und Wartbarkeit erhalten bleiben. Doch die Fähigkeit, Code zu verstehen, wächst nicht so schnell wie die Fähigkeit, ihn zu erzeugen. Das ist eine Einschätzung aus der Entwicklerpraxis, kein gemessener Befund zur Teamleistung.

Konzeptionelle Integrität bedeutet, dass die Teile eines Systems einem stimmigen Entwurf folgen. Wird dieselbe Geschäftsregel an mehreren Stellen unterschiedlich umgesetzt, kann jeder Teil für sich funktionieren und das Gesamtsystem dennoch schwerer verständlich werden. Dass sich eine Funktion leichter ergänzen lässt, ändert nichts daran, dass ein stimmiger Entwurf Aufmerksamkeit braucht.

Die Zahl der Codezeilen pauschal abzutun, greift deshalb ebenso zu kurz wie der Versuch, sie allein zum Erfolgsmaßstab zu erheben. Mehr zu produzieren ist wertvoll, wenn das Team die wachsende Codebasis erklären, prüfen und warten kann. Ob diese Voraussetzungen erfüllt sind, muss gesondert geprüft werden.

Schnellere Erzeugung kann längere Wartezeiten bedeuten

Modelle, Werkzeuge und parallele Aufgaben können die Codeproduktion schnell steigern. Schwieriger ist es, ebenso schnell mehr Entwickler mit Systemkenntnis und genügend Zeit für Reviews verfügbar zu haben. So kann mehr Arbeit fertig erscheinen, während die Auslieferung stockt, weil Code auf Freigabe wartet.

Zwei von Anbietern finanzierte, 2026 veröffentlichte Umfragen deuten auf diesen Druck hin. Im Auftrag von GitLab befragte Harris Poll 1.528 Entwickler und Verantwortliche für den Einkauf von Technologie in sechs Ländern. 85 Prozent stimmten zu, dass sich der Engpass vom Schreiben zum Prüfen und Validieren verlagert habe. 79 Prozent berichteten von höherer individueller Produktivität, ohne dass die gesamte Auslieferung im gleichen Maß schneller geworden sei.

Sonar befragte mehr als 1.100 professionelle Entwickler. 38 Prozent hielten die Prüfung KI-generierten Codes für aufwendiger als die Prüfung menschlich geschriebenen Codes. Nur 48 Prozent gaben an, ihn vor einem Commit immer zu prüfen.

Das sind Selbstauskünfte. Die Umfragen messen die Teamleistung nicht direkt und belegen nicht, dass Code-Reviews in jedem Unternehmen den Hauptengpass bilden. Anderswo können das Deployment oder die Bündelung von Änderungen zu Releases stärker ins Gewicht fallen. Die Aussage hier ist enger: Übersteigt die Codeproduktion die Prüfkapazität und das gemeinsame Systemwissen, sammelt sich Arbeit an, die auf Prüfung wartet.

Wann ist eine Änderung bereit für das Review?

KI kann auch weniger erfahrenen Entwicklern schnell hilfreiche Rückmeldung geben. Sie kann unbekannten Code erklären, Alternativen vorschlagen und beim Vorbereiten von Tests helfen. Danach beginnt die Prüfaufgabe des Autors.

Teams sollten sich dafür auf einige Erwartungen einigen, statt sich allein auf persönliche Sorgfalt zu verlassen:

• Klären Sie vor einer umfangreichen Änderung die Grenzen und Vorgaben. Ein kurzes Entwurfsgespräch kostet weniger, als die Entscheidungen später aus dem Code zu erschließen.
• Erläutern Sie im Pull Request wichtige Entscheidungen, Annahmen, Fehlerfälle, Testergebnisse und Unsicherheiten.
• Halten Sie jede Änderung so klein, dass sowohl Autor als auch prüfende Person sie vollständig verstehen können.
• Lassen Sie zu, dass eine Änderung zur Überarbeitung zurückgeht, wenn ihr Autor sie nicht erklären kann. Das macht fehlende Vorbereitung sichtbar und ist keine Bestrafung.

Meine praktische Regel lautet: Reichen Sie keinen KI-generierten Code zur Prüfung ein, den Sie einem anderen Entwickler nicht sicher erläutern könnten. Dafür müssen Sie nicht jede Zeile auswendig kennen. Sie müssen die Entscheidungen und ihre Folgen verantworten können.

Die prüfende Person soll helfen, Übersehenes zu finden. Sie sollte nicht eine Lösung von Grund auf erschließen müssen, die der Autor selbst nie zu verstehen versucht hat. KI kann den Code entwerfen und kritisieren. Der Autor muss dem Team begründen können: „Das sollten wir produktiv einsetzen.“