Dein Blog zum Thema digitales Business

Ein Reviewer prüft, was er kennt

Code-Review ist auf einen bestimmten Fehlertyp trainiert: den menschlichen. Unaufmerksamkeit nach acht Stunden Arbeit, eine Wissenslücke bei einem selten genutzten Framework, ein Copy-Paste-Fehler unter Zeitdruck. Erfahrene Reviewer erkennen diese Muster fast automatisch, weil sie selbst schon so programmiert haben. Genau diese Kalibrierung wird zum blinden Fleck, sobald ein relevanter Teil des Codes nicht mehr von einem Menschen stammt, sondern von einem KI-Assistenten oder einem autonom arbeitenden Agenten.

Zwei Fehlerprofile, die nicht deckungsgleich sind

Ein Mensch, der eine Funktion falsch implementiert, tut das meistens erkennbar unsicher: ungetestete Ränder, fehlende Fehlerbehandlung, ein Kommentar wie „TODO: nochmal prüfen“. Ein Sprachmodell schreibt dieselbe fehlerhafte Funktion mit derselben Zuversicht wie eine korrekte. Es gibt keine Unsicherheit im Ton und keine Lücke im Stil, an der ein Reviewer intuitiv ansetzen kann. Das Modell reproduziert stattdessen, was in seinen Trainingsdaten am häufigsten und am plausibelsten aussah, und das schließt veraltete Bibliotheksversionen, längst abgelöste Verschlüsselungsverfahren oder unsichere Standardkonfigurationen ausdrücklich mit ein. Ein Reviewer, der nach den Anzeichen menschlicher Unsicherheit sucht, findet an dieser Stelle nichts, worauf er reagieren könnte.

Das schwer erkennbare Muster: plausibel, aber falsch

Ein zweites Muster kommt aus der Funktionsweise der Modelle selbst hinzu. Ein Sprachmodell generiert Text als wahrscheinlichste Fortsetzung, nicht durch Nachschlagen in einer Paketdatenbank. Dabei kann es Funktionsnamen, Versionsangaben oder ganze Paketnamen erzeugen, die es schlicht nicht gibt, weil sie zur restlichen Zeile plausibel passen. Für einen Menschen ist der Unterschied zwischen einem echten und einem plausibel klingenden, aber nicht existierenden Abhängigkeitsnamen im Diff kaum zu erkennen, für jemanden, der gezielt nach solchen Namen sucht, um sie vorsorglich zu registrieren, dafür umso besser. Diese Lücke ist mit der klassischen Dependency Confusion verwandt, hat aber eine andere Ursache: nicht ein falsch aufgelöster Namespace, sondern eine Erfindung, die aussieht wie ein echtes Paket.

Wie deutlich sich das Fehlerbild bereits unterscheidet, zeigt eine aktuelle Auswertung von GitGuardian im „State of Secrets Sprawl 2026“: Für Commits, die mit dem KI-Coding-Assistenten Claude Code entstanden sind, wurde eine Leck-Rate für Zugangsdaten von 3,2 Prozent gemessen, gegenüber 1,5 Prozent im Durchschnitt über alle öffentlichen GitHub-Commits (blog.gitguardian.com, „The State of Secrets Sprawl 2026“). Das belegt nicht, dass KI-generierter Code grundsätzlich schlechter ist, es belegt für ein konkretes Werkzeug ein messbar anderes Fehlerprofil als das menschliche, und genau darauf ist die klassische Prüfpraxis nicht ausgelegt.

Herkunft wird zur Prüffrage

Die praktische Konsequenz betrifft nicht in erster Linie das einzelne Review, sondern die Frage davor: Woher kommt diese Änderung überhaupt? Bei menschlichem Code beantwortet der Commit-Autor diese Frage implizit. Bei KI-generiertem Code reicht das nicht mehr, weil „wer hat committet“ und „wer hat geschrieben“ auseinanderfallen können. Ein Entwickler, der einen von einem Agenten vorgeschlagenen Patch ungeprüft übernimmt, ist formal der Autor, inhaltlich aber nicht die Quelle. Für eine Prüfkette, die Verantwortung nachvollziehbar machen soll, ist das ein Unterschied, den sie kennen muss.

Was die Nachweiskette zusätzlich tragen muss

Bisher bilden SBOM, Signierung und Nachweiskette (siehe dazu auch unseren Beitrag zu Provenance und Attestation) vor allem den fertigen Zustand eines Artefakts ab: welche Komponenten stecken drin, wer hat das Ergebnis freigegeben, wie ist der Build entstanden. Die Herkunft der einzelnen Änderung, ob sie von einem Menschen oder einem Agenten stammt und mit welchem Grad an menschlicher Prüfung sie in den Hauptzweig gelangt ist, gehört in dieselbe Kette und nicht in eine Fußnote daneben. Provenienz ist damit kein Zusatzfeature, sondern eine Dimension, die die bestehenden Nachweismechanismen ohnehin schon tragen können: dieselbe Logik, die heute festhält, welcher Build welche Tests bestanden hat, kann auch festhalten, welcher Anteil eines Commits automatisiert erzeugt und welcher Anteil davon von einem Menschen tatsächlich gegengelesen wurde.

Was du daraus machen kannst

Wenn in deiner Pipeline KI-gestützte Schritte längst mitschreiben, lohnt sich die Frage, ob dein Review-Prozess noch auf den Fehlertyp kalibriert ist, den er ursprünglich abfangen sollte, oder auf einen, der so nicht mehr vorkommt. Und ob deine Nachweiskette überhaupt beantworten kann, wer oder was eine Änderung tatsächlich geschrieben hat, bevor sie ein Mensch als seine eigene freigegeben hat.

Das Leistungsspektrum dahinter ist gestaffelt. Es reicht von Delivery und Nachweisführung, die sich modulweise in eine bestehende Pipeline einziehen lassen, über die Frage, wo KI-gestützte Schritte in Build und Deployment Freigaben und Verantwortung verwischen, bis zur Frage, wem ein System nach dem Go-Live gehört und woran man merkt, dass es niemandem mehr gehört. Ein festes Angebot daraus entsteht erst, wenn klar ist, was du wirklich brauchst. Schreib an mm@mhm-dl.de.