Wenn die KI den Code schreibt: Warum Code Review zur wichtigsten Disziplin wird // nh labs

Die Fähigkeit, auf die es jahrzehntelang ankam

Frag eine erfahrene Entwicklerin, worin sie gut ist, und die Antwort kreist fast immer ums Schreiben: eine knifflige Funktion sauber bauen, ein Problem in eleganten Code übersetzen, das richtige Pattern im richtigen Moment wählen. Code zu produzieren war die knappe, gut bezahlte, bewunderte Fähigkeit. Code zu lesen – fremde Pull Requests durchgehen, prüfen, ob etwas stimmt – war die Pflicht, die man zwischen der eigentlichen Arbeit erledigte. Kaum jemand hat sich je damit gerühmt, ein guter Reviewer zu sein.

Genau dieses Verhältnis kippt gerade. Wenn ein Modell den Großteil des neuen Codes schreibt – und in vielen Teams tut es das längst –, ist die Produktion nicht mehr der Engpass. Code entsteht schneller, billiger und in größeren Mengen, als ein Mensch ihn je geschrieben hätte. Der Flaschenhals verschiebt sich an die eine Stelle, die kein Modell für uns übernimmt: zu verstehen, ob der Code richtig ist, und die Verantwortung dafür zu tragen.

Die entscheidende Ingenieursfähigkeit der nächsten Jahre ist damit nicht mehr, Code zu schreiben. Es ist, fremden Code zu lesen – schnell, skeptisch, gnadenlos.

Die Umkehrung

Über Jahrzehnte galt eine stille Annahme: Schreiben ist schwer, Lesen ist leicht. Eine Funktion zu entwerfen, die ein Problem löst, war die anspruchsvolle, kreative Arbeit. Sie zu lesen und abzunicken war Routine – ein Sicherheitsnetz, kein Hauptakt. Genau deshalb war Review in den meisten Teams das ungeliebte Stiefkind: knapp bemessen, schnell erledigt, selten ernst genommen.

KI dreht dieses Verhältnis exakt um. Das Schreiben – das Übersetzen einer klaren Absicht in lauffähigen Code – ist genau die Art von Arbeit, in der Modelle herausragend sind. Es ist gut abgestecktes, millionenfach im Trainingsmaterial vorhandenes Handwerk. Was ein Modell nicht liefert, ist Urteilsvermögen: die Fähigkeit zu beurteilen, ob dieser Code in diesem System, mit diesen Daten, unter diesen Lasten das Richtige tut – und ob jemand die Konsequenzen verantworten kann, wenn er live geht.

Die Knappheit hat sich verschoben. Generierung ist billig geworden, Verständnis ist teuer geblieben. Und Verständnis lässt sich nicht delegieren: Es ist genau die Tätigkeit, die der Mensch übernehmen muss, weil sie der Punkt ist, an dem aus „der Code läuft" ein „wir verstehen, was er tut, und stehen dafür ein" wird. Review war früher das Ende der Pipeline. Jetzt ist es das Nadelöhr, durch das alles muss.

Warum KI-Code besonders heimtückisch zu prüfen ist

Menschen prüfen Code seit jeher mit einer einzigen, hocheffizienten Heuristik: Sieht vernünftig aus → ist wahrscheinlich in Ordnung. Diese Abkürzung funktioniert, weil schlechter menschlicher Code meistens auch schlecht aussieht. Verworrene Logik, krude Variablennamen, ein Kommentar wie „TODO: das ist Murks" – die Oberfläche verrät die Schwäche. Man liest die ersten Zeilen, spürt den Geruch und schaut genauer hin.

KI-Code zerstört genau diese Heuristik. Er ist plausibel. Er kompiliert. Er liest sich sauber. Die Variablennamen sind vernünftig, die Struktur ist konventionell, die Kommentare sind höflich. Er sieht aus wie der Code eines kompetenten, ausgeschlafenen Kollegen – und ist trotzdem selbstbewusst auf subtile Weise falsch:

ein Edge Case, der nie behandelt wird – die leere Liste, der negative Betrag, die Zeitzone an der Tagesgrenze
ein API-Aufruf, der erfunden ist: eine Methode, die so plausibel klingt, dass man sie für echt hält, bis sie zur Laufzeit nicht existiert
eine stille Sicherheitslücke – Nutzereingaben ungeprüft in eine Query, ein Secret im Log, eine Autorisierung, die genau einen Pfad zu prüfen vergisst
eine Annahme, die nicht hält: dass die Antwort sortiert ist, dass das Feld nie null wird, dass die Operation idempotent ist

Bei menschlichem Code korrelieren Aussehen und Korrektheit grob miteinander. Bei KI-Code sind sie entkoppelt. Das Modell optimiert auf Plausibilität – auf Code, der aussieht wie korrekter Code –, und das ist nicht dasselbe wie Korrektheit. Genau deshalb ist KI-Code gefährlicher zu prüfen als der eines unsicheren Junior-Entwicklers: Beim Junior warnt einen die holprige Oberfläche. Beim Modell wiegt die glatte Oberfläche einen in Sicherheit.

Das neue Versagen heißt Durchwinken

Es gibt eine Versagensform, die kaum jemand kommen sieht, weil sie sich nicht wie ein Fehler anfühlt. Sie fühlt sich wie Produktivität an.

Die Mechanik ist simpel und brutal. Das Volumen steigt: Wo früher zwei Pull Requests pro Tag durch das Review liefen, sind es jetzt zehn. Die Zeit pro Review bleibt gleich oder schrumpft, weil der Druck, zu liefern, gestiegen ist. Also fällt die Aufmerksamkeit pro Zeile. Aus „ich verstehe, was dieser Code tut" wird „sieht plausibel aus, läuft durch die Tests, genehmigt". Das ist Rubber-Stamping – das Durchwinken, bei dem das grüne Häkchen die Bedeutung verloren hat, die es einmal hatte.

Das Tückische daran: Es sieht von außen identisch aus wie funktionierendes Review. Dieselben Pull Requests, dieselben Approvals, dasselbe grüne CI. Nur dass niemand mehr wirklich hinschaut. Das Team liefert mehr und versteht weniger. Jeder durchgewunkene PR fügt dem System ein bisschen Code hinzu, den kein Mensch je vollständig im Kopf hatte – und genau das ist die teuerste Form technischer Schulden: nicht Code, der schlecht aussieht, sondern Code, den niemand verstanden hat und den deshalb auch niemand sicher ändern kann.

Diese Schuld verzinst sich. Der erste durchgewunkene Bug ist billig. Der zehnte sitzt in einem Fundament aus neun weiteren ungeprüften Annahmen, und niemand weiß mehr, welche davon noch gelten. Wenn ein Team in dieser Phase aufwacht, ist die ehrliche Frage selten „wo ist der Bug?", sondern „verstehen wir unser eigenes System überhaupt noch?".

Wie gutes Review heute aussieht

Wenn das Schreiben billig wird, muss das Lesen anspruchsvoller werden. Gutes Review im KI-Zeitalter prüft nicht mehr in erster Linie Syntax und Stil – das erledigen Linter und das Modell selbst. Es prüft die Dinge, die ein Modell strukturell am ehesten falsch macht und ein flüchtiger Mensch am ehesten übersieht:

Absicht vor Implementierung. Die erste Frage ist nicht „ist dieser Code korrekt?", sondern „löst er das richtige Problem?". Code kann tadellos sein und trotzdem die falsche Sache tun, weil das Modell die Aufgabe plausibel missverstanden hat.
Architektur statt Zeile. Passt diese Änderung zur Struktur des Systems, oder schmuggelt sie ein zweites, konkurrierendes Muster ein? Modelle bauen lokal sinnvoll und global inkonsistent.
Die Ränder. Die leere Eingabe, der Grenzwert, der gleichzeitige Zugriff, das Timeout. Genau die Fälle, die in keinem Glückspfad auftauchen – und die das Modell am ehesten übersprungen hat.
Die Fehlerpfade. Was passiert, wenn der Aufruf scheitert, die Datenbank wegbricht, die Antwort halb ankommt? Generierter Code beschreibt den Erfolg eloquent und das Scheitern lückenhaft.
Die Sicherheitsfläche. Jede Stelle, an der Nutzereingaben, Berechtigungen, Secrets oder externe Daten ins Spiel kommen. Das Modell hat keine Bedrohungsvorstellung; sie muss vom Menschen kommen.

Und über allem steht eine kulturelle Regel, die nicht verhandelbar sein darf: Wer KI-Code einreicht, besitzt jede Zeile davon. Nicht „die KI hat das so geschrieben" – sondern: Du hast es eingereicht, also kannst du erklären, warum es so und nicht anders ist, was es bei der leeren Eingabe tut und warum du diesem API-Aufruf vertraust. Kann der Einreicher das nicht, ist der Pull Request nicht fertig, egal wie grün die Tests leuchten. Das Modell hat den Code getippt; die Verantwortung lässt sich nicht mittippen.

„Kann nicht die KI die KI prüfen?"

Der naheliegende Einwand: Wenn das Lesen der neue Engpass ist – warum lässt man dann nicht ein Modell den Code eines anderen Modells prüfen und ist das Problem los?

Als erste Schicht ist das sogar sinnvoll. Ein KI-Reviewer fängt Offensichtliches: nicht behandelte Fehlerfälle, fehlende Tests, bekannte Sicherheitsmuster, Stilbrüche. Als automatisiertes Linting auf Steroiden ist er wertvoll, und er nimmt dem Menschen die stumpfe Arbeit ab, damit der seine Aufmerksamkeit für das Schwere aufspart.

Aber er löst das eigentliche Problem nicht, aus zwei Gründen. Erstens teilt er die blinden Flecken. Dieselben Trainingsverzerrungen, dieselbe Neigung zu plausiblen statt korrekten Antworten, dieselbe fehlende Vorstellung davon, was in diesem Geschäft schiefgehen darf und was nicht. Ein Modell, das eine subtil falsche Annahme nicht erkennt, erkennt sie auch im Code eines anderen Modells nicht – es nickt sie mit derselben Souveränität ab. Zweitens, und das wiegt schwerer: Ein KI-Review erzeugt falsche Sicherheit. Ein zweites grünes Häkchen fühlt sich nach mehr Gewissheit an, ist aber bloß dieselbe Wette ein zweites Mal. Und vor allem überträgt es keine Verantwortung. Wenn das System um drei Uhr nachts fällt, kann sich niemand hinter „aber die Review-KI war einverstanden" stellen. Am Ende steht ein Mensch, der den Merge verantwortet – und genau das ist der Punkt, den keine Automatisierung wegnehmen kann.

Strenge nach Sprengradius dosieren

Jetzt die ehrliche Gegenseite, sonst zieht man die Lehre zu weit. Nicht jeder Code verdient dieselbe Strenge – und alles mit maximaler Paranoia zu prüfen, ist seine eigene Form von Verschwendung. Ein Wegwerf-Skript, das einmal eine CSV umformatiert, braucht kein dreifaches Security-Review. Ein internes Dashboard, das fünf Leute sehen, ist nicht die Zahlungsabwicklung.

Die richtige Variable ist nicht „wie viel Code", sondern Sprengradius: Was passiert im schlimmsten Fall, wenn dieser Code falsch ist? Daran bemisst sich, wie genau man hinschaut.

Wie groß ist der Schaden, wenn es bricht? Zahlungslogik, Authentifizierung, Datenmigrationen, alles, was Kundendaten oder Geld berührt – maximale Strenge, Zeile für Zeile. Ein internes Hilfstool – leichteres Review.
Wie umkehrbar ist es? Ein Feature hinter einem Flag, das man in Sekunden zurückdrehen kann, verträgt mehr Tempo als eine Migration, die Daten unwiederbringlich umschreibt.
Wie weit reicht es? Eine isolierte Funktion ohne Abhängigkeiten ist harmlos. Eine Änderung an einer zentralen, von zwanzig Stellen genutzten Komponente ist es nicht.
Lebt es lange? Code, der bleibt und wächst, verdient die Sorgfalt, die man Wegwerf-Code erspart.

Hoher Sprengradius heißt: langsam lesen, jede Annahme anzweifeln, den Einreicher jede Zeile erklären lassen. Niedriger Sprengradius heißt: durchwinken ist in Ordnung. Die Kunst ist nicht, alles maximal zu prüfen – sondern die Aufmerksamkeit dorthin zu lenken, wo ein Fehler wirklich wehtut. Und damit das überhaupt möglich bleibt, gilt eine schlichte Hygieneregel: Pull Requests klein halten. Ein Mensch kann 200 Zeilen mit echter Skepsis lesen. Bei 2.000 schaltet er in den Durchwink-Modus – und der ist, wie wir gesehen haben, gar kein Review mehr.

Fazit

Jahrzehntelang war Code zu schreiben die Fähigkeit, die ein Ingenieur sich erarbeitete und für die er bezahlt wurde. Diese Fähigkeit ist nicht wertlos geworden, aber sie ist nicht mehr knapp. Knapp ist jetzt das, was lange als Pflichtübung galt: fremden Code schnell, skeptisch und rigoros zu lesen – und für ihn geradezustehen.

Für Teams heißt das, eine Disziplin neu aufzubauen, die viele jahrelang vernachlässigt haben. Review muss zu einer erstklassigen, sichtbar geschätzten Tätigkeit werden, nicht zu unbezahlter Mehrarbeit zwischen den eigentlichen Aufgaben. Man stellt und fördert künftig nicht nur Menschen, die brillant schreiben, sondern solche, die scharf lesen. Der Hebel der erfahrenen Entwicklerin ist nicht mehr, wie schnell sie tippt, sondern wie gut ihr Urteil und ihr Geschmack einen Strom generierten Codes filtern.

Genau hier liegt unser Anspruch bei NH Labs. Wir setzen KI im Engineering ein, weil sie schnell und gut ist – aber wir behandeln Review nicht als optionalen letzten Schritt, sondern als die Kerndisziplin, an der jede Zeile vorbeimuss. Ein Mensch versteht jede eingereichte Zeile, kann sie erklären und verantwortet den Merge. Deshalb können unsere Kunden dem Ergebnis vertrauen: nicht, weil eine KI es geschrieben hat, sondern weil ein Mensch es gelesen hat.