AI Code Review: Richtlinie für KI-generierten Code

Für AI Code Review braucht jedes Team eine unumstößliche Richtlinie: KI darf Code schreiben und prüfen, doch für den Merge trägt immer eine namentlich benannte Person die Verantwortung. Bei jeder KI-gestützten Änderung muss offengelegt werden, wie die KI zum Einsatz kam. Zudem muss die Änderung deterministische Prüfungen bestehen und von Menschen so gründlich geprüft werden, wie es das mögliche Schadensausmaß verlangt.

Diese Trennung ist heute wichtiger denn je. Am 17. August 2026 veröffentlichte Wiz Details zu einer kritischen Injection-Schwachstelle in GitHub Actions in einem öffentlichen Repository von Snowflake. Im finalen Squash-Commit war Copilot Autofix als Co-Autor aufgeführt, während die KI-gestützte Sicherheitsprüfung von GitHub die Änderung freigab. Wiz stellte ausdrücklich klar, dass unbekannt ist, ob die Codeänderung selbst mit KI-Unterstützung entstanden war. Fünf Tage nachdem die Schwachstelle in Produktion gelangt war, fand und nutzte ein autonomer Sicherheitsagent sie im Rahmen autorisierter Tests aus.

Warum Teams dennoch automatisieren wollen, zeigt eine einfache Rechnung. Wer wöchentlich 50 Pull Requests bearbeitet und für eine erste manuelle Prüfung jeweils 30 Minuten benötigt, investiert dafür 25 Entwicklerstunden. Bei beispielhaft angesetzten Vollkosten von $120 pro Stunde sind das $3,000 pro Woche – noch vor der vertieften Prüfung. GitHub veranschlagt eine Copilot-Prüfung derzeit mit $0.05 bis $1 an KI-Credits im Lite-Modus oder mit $0.25 bis $5 im Balanced-Modus, jeweils zuzüglich der GitHub-Actions-Minuten. Der erste Prüfdurchlauf wird günstig. Die Freigabeverantwortung nicht.

AI Code Review: Was die Richtlinie tatsächlich leistet

Eine gute Richtlinie regelt den Codeverkehr, statt KI zu verbieten. Sie legt fest, was Autoren offenlegen müssen, was die Automatisierung blockieren soll und wann zwingend ein zweites menschliches Augenpaar erforderlich ist.

Ein Pull Request lässt sich mit Fracht vergleichen, die in einem Hafen eintrifft. Tests und Scanner kontrollieren den Container. Ein KI-Reviewer liest das Manifest und weist auf verdächtige Positionen hin. Ob die Fracht die Grenze passieren darf, entscheidet weiterhin ein Mensch. Wer dem Prüfwerkzeug zugleich den Dienststempel überlässt, setzt die Kontrolle außer Kraft.

Der Kern der Richtlinie kann so formuliert werden:

Code, der mit einem KI-Coding-Tool erstellt oder wesentlich verändert wurde, darf ausschließlich über einen Pull Request eingebracht werden. Der Autor bleibt dafür verantwortlich, die Änderung zu verstehen, und muss das verwendete Tool, den Umfang der KI-Unterstützung, die ausgeführten Tests sowie den verantwortlichen Menschen benennen. Vorgeschriebene Tests und Sicherheitsprüfungen müssen vor der Freigabe erfolgreich abgeschlossen sein. Eine KI-Prüfung hat ausschließlich beratenden Charakter und zählt niemals als erforderliche menschliche Freigabe. Für sensible Dateien ist ein Code Owner erforderlich. Kritische Änderungen benötigen eine unabhängige zweite freigebende Person und einen Rollback-Plan. Neue Commits machen frühere Freigaben ungültig und lösen eine erneute Prüfung aus.

Diese Richtlinie orientiert sich an den möglichen Folgen, nicht an der Erkennung der Urheberschaft. Entwickler sollten nicht nachweisen müssen, welche einzelnen Zeilen aus einer Autovervollständigung stammen. Entscheidend ist, wesentliche KI-Unterstützung offenzulegen und die Verantwortung für den gesamten Diff zu übernehmen. Das ist hilfreicher als eine Debatte über einen Prozentwert, den ohnehin kein Tool in eine belastbare Freigabeentscheidung übersetzen kann.

Drei Prüfpfade für unterschiedliche Risiken

Der kritische Pfad ist bewusst aufwendig. Nur ein kleiner Teil der Änderungen sollte dort landen. Knapp bemessene Zeit erfahrener Fachkräfte gehört genau dorthin, wo ein plausibel wirkender Fehler Zugangsdaten offenlegen, Daten beschädigen oder Zugriffsrechte verändern kann.

So funktioniert Code Review mit KI – ohne Fachjargon

Der Workflow umfasst sechs Kontrollpunkte. Jeder davon erzeugt Nachweise, die im nächsten Prüfschritt nachvollzogen werden können.

1. Unterstützung offenlegen. Die Pull-Request-Vorlage erhält Felder für AI-assisted, tool, scope, human owner und tests run. Der Autor verantwortet jede Zeile – unabhängig davon, ob die KI nur eine Funktion oder den gesamten ersten Entwurf geschrieben hat.
2. Risiko einstufen. Eine kleine Richtliniendatei ordnet Pfade und Änderungstypen den Stufen Routine, Sensibel oder Kritisch zu. Eine Änderung unter .github/workflows/ darf niemals in derselben Kategorie landen wie die Korrektur eines Tippfehlers in der Dokumentation.
3. Zuerst deterministisch prüfen. Deterministisch bedeutet: Dieselbe Eingabe führt immer zum selben Ergebnis – bestanden oder nicht bestanden. Kompilierung, Typprüfung, Linting, Tests, Secret-Scanning, Abhängigkeitsprüfung und statische Sicherheitsanalyse gehören vor die Einschätzung durch ein weiteres Modell. Auch GitHubs eigene Anleitung zur Prüfung stellt automatisierte Tests und statische Analysen an den Anfang.
4. KI als Kritiker einsetzen. Sie soll nach fehlenden Fällen, Architekturabweichungen, gelöschten Tests, halluzinierten APIs, verdächtigen Paketen und geänderten Berechtigungen suchen. Für sicherheitsrelevante oder dienstübergreifende Arbeiten ist eine Prüfung mit höherem Aufwand sinnvoll. Die Selbstprüfung des Agenten, der den Code erstellt hat, darf den Kontrollpunkt nicht erfüllen.
5. Das Urteil einem Menschen überlassen. Der Reviewer prüft die Absicht, testet riskantes Verhalten, hinterfragt neue Abhängigkeiten und entscheidet, ob der Diff in das System gehört. Hinweise der KI sind zunächst nur Anhaltspunkte. Erst die Bestätigung durch einen Menschen oder ein deterministisches Tool macht daraus einen Befund.
6. Nach jedem Push zurücksetzen. Veraltete Freigaben werden verworfen, vorgeschriebene Prüfungen erneut ausgeführt und bei neuen Commits eine weitere Prüfung angefordert. GitHub weist darauf hin, dass die automatische Copilot-Prüfung normalerweise nur einmal läuft, sofern die Prüfung bei jedem Push nicht aktiviert wurde.

Zwei weniger offensichtliche Kontrollen gehören ebenfalls in die Richtlinie. Erstens benötigen Abhängigkeitsdateien einen eigenen Scanner, weil GitHub Copilot Code Review Dateien wie package.json und Gemfile.lock nicht berücksichtigt. Zweitens müssen Änderungen an KI-Anweisungsdateien als kritisch eingestuft werden. Copilot liest Repository-Anweisungen, Agentenanweisungen und Skills aus dem Head-Branch des Pull Requests. Damit kann eine vorgeschlagene Änderung genau die Anweisungen beeinflussen, nach denen sie selbst geprüft wird.

In diesen sieben Fällen zahlt sich die Richtlinie zuerst aus

1. Plattformteams mit Coding-Agenten in vielen Repositorys

Plattformteams profitieren am stärksten, weil eine einzige Richtlinie Tausende künftige Änderungen steuern kann. Die Risikozuordnung kommt in eine gemeinsame Vorlage, für alle gelten dieselben Offenlegungsfelder und eine einheitliche Statusprüfung lässt sich in jedem geschützten Branch erzwingen. So entsteht eine zentrale Kontrolle, ohne dass jedes Produktteam ein eigenes Verfahren entwerfen muss. Teams, die die besten KI-Coding-Agenten für Unternehmen vergleichen, können das Tool wechseln, ohne das Freigabemodell neu aufzubauen.

2. SaaS-Teams zum Schutz von Authentifizierung, Abrechnung und Kundendaten

Die technische Leitung eines SaaS-Anbieters kann Authentifizierung, Berechtigungsprüfungen, Zahlungscode und Datenexportpfade als Kritisch markieren. Ein Agent darf einen Fix entwerfen und ein KI-Reviewer darf ihn prüfen, doch die zuständige Person für Identitätsverwaltung oder Zahlungen sowie ein weiterer Mensch müssen zustimmen. Der Nutzen liegt im Fokus: Erfahrene Reviewer behandeln nicht länger jede Datei gleich, sondern konzentrieren sich auf Änderungen mit realem Schadensradius.

3. DevOps-Teams für CI/CD-Workflows

Workflow-Dateien sind ausführbare Produktionsinfrastruktur und sollten auch so behandelt werden. Jede Änderung wird einem DevOps-Code-Owner vorgelegt. Die Prüfung sucht nach direkter Interpolation nicht vertrauenswürdiger Inhalte aus Issues oder Pull Requests in Shell-Befehle, kontrolliert Token-Berechtigungen und verlangt einen Rollback. Der Fall Wiz zeigt den Nutzen konkret: Der Titel eines öffentlichen Issues gelangte in einen Shell-Befehl, und das offengelegte Token konnte interne Jira-Projekte lesen. Eine Richtlinie erfasst diese Fehlerkategorie, bevor überhaupt darüber diskutiert wird, ob der ursprüngliche Autor ein Mensch oder eine KI war.

4. Engineering-Leitungen bei der Einführung von Copilot, Codex oder Claude Code

Wer die Einführung verantwortet, kann Tool-Berechtigung und Merge-Berechtigung sauber trennen. Entwickler erhalten schnelle Codegenerierung und eine erste Prüfung, während die Branch-Regeln weiterhin menschliche Freigaben, erfolgreiche Workflows und die Prüfung durch Code Owner verlangen. Der Vorteil ist eine schnelle Einführung mit nachvollziehbarer Kontrollebene. Ein Vergleich der lokalen und GitHub-basierten Review-Modi von Codex kann bei der Tool-Auswahl helfen; der menschliche Kontrollpunkt muss jedoch auch einen Anbieterwechsel überstehen.

5. Open-Source-Maintainer mit kontextarmen Pull Requests

Eine Checkbox zur KI-Unterstützung und eine Nachweisliste in CONTRIBUTING.md schaffen Klarheit. Anschließend kann die Automatisierung Beiträge ablehnen, wenn Reproduktionsschritte, Tests oder ein verantwortlicher Maintainer fehlen. KI kann die Warteschlange zusammenfassen und vorsortieren. Menschen konzentrieren sich auf die Absicht hinter der Änderung, die Kompatibilität und die Frage, ob der Beitrag überhaupt in das Projekt gehört. So sinkt der Prüfungsrückstand, ohne dass die Anforderungen an fremde Beitragende stillschweigend gesenkt werden.

6. Agenturen, die kundeneigene Software ausliefern

Eine Agentur kann jeder Veröffentlichung einen Prüfnachweis beilegen: eingesetzte Tools, betroffene Komponenten, Testergebnisse, offene Befunde und namentlich benannte Freigebende. Sensible Kundenpfade gehen vor der Veröffentlichung an den Code Owner des Kunden. Das schafft eindeutigere Verantwortlichkeiten und ein Übergabedokument, das auch nach dem Ausscheiden des Umsetzungsteams erhalten bleibt.

7. Solo-Gründer, die mit einem KI-Coding-Agenten veröffentlichen

Solo-Gründern fehlt standardmäßig ein unabhängiger Teamkollege. Deshalb muss der Workflow die Trennung künstlich herstellen: Ein Modell erstellt den Entwurf, anschließend laufen deterministische Prüfungen und ein anderer Review-Durchlauf, bevor die riskante Funktion persönlich getestet und der Merge freigegeben wird. Bei Zahlungen, Authentifizierung oder Produktionsinfrastruktur sollte ein externer Spezialist hinzugezogen werden. So entsteht ein günstiger erster Filter, ohne ein zweites Modell mit einer zweiten verantwortlichen Person zu verwechseln.

Welche Produkte daraus entstehen könnten

Der Markt bezahlt bereits für automatisierte Codeprüfungen. In den USA entfallen monatlich rund 1,600 Google-Suchanfragen auf „ai powered code review platform“, 1,300 auf „ai code review“ und 590 auf „ai code review tools“. CodeRabbit verlangt für den jährlich abgerechneten Pro-Tarif derzeit $24 pro Entwickler und Monat, für Pro Plus $48. Qodo startet bei $30 pro Monat. Die Marktlücke ist kein weiterer Bot, der jeden Pull Request kommentiert. Gefragt ist eine Kontrollebene, die entscheidet, welche Prüfung tatsächlich zählt.

1. Policy-as-Code-Kontrollpunkt für Pull Requests – die stärkste Chance

Eine GitHub-App für Engineering- und Sicherheitsverantwortliche kann aus einer kurzen Richtliniendatei verbindliche Prüfungen erzeugen. Sie liest die geänderten Pfade, kontrolliert die Erklärung zur KI-Nutzung, weist einen Risikopfad zu, fordert die richtigen Code Owner an, bestätigt die Ausführung vorgeschriebener Scanner, entwertet veraltete Freigaben und erstellt einen Auditnachweis.

Die Nachfrage bestätigt die Kategorie: „ai powered code review platform“ erzielt in den USA etwa 1,600 Suchanfragen pro Monat, „ai code review“ 1,300 bei einem CPC von $63.85. Die kleinste verkaufbare Version benötigt eine GitHub-App, eine Richtliniendatei im Repository, eine Statusprüfung, einen Dienst zur Reviewer-Zuweisung und eine Audittabelle. Der Haken ist die Konfigurationsmüdigkeit. Das Produkt gewinnt nur, wenn gute Standardeinstellungen verbreitete Stacks abdecken und Ausnahmen leicht zu erklären sind.

2. Reviewer-Zuweisung für kritische Dateien

Ein schlankeres Tool für Plattform- und AppSec-Teams kann Pfade wie Workflows, Infrastruktur, Migrationen, Authentifizierung und Richtliniendateien überwachen. Bei Änderungen erhöht es den Prüfaufwand, ruft den zuständigen Owner hinzu und verlangt nach jedem Push eine erneute Prüfung. Routinemäßiger Code kann einen günstigen Durchlauf nehmen, während aufwendige KI-Analyse und menschliche Zeit für kritische Diffs reserviert bleiben.

„AI code review tools“ erreicht in den USA rund 590 Suchanfragen pro Monat, zeigt kommerzielle Suchabsicht und weist im Keyword-Datensatz einen jährlichen Trend von 50% auf. „Secure code review“ ergänzt 170 monatliche Suchanfragen bei einem CPC von $50.19. Das MVP umfasst Pfadregeln, eine CODEOWNERS-Integration, eine Check-Run-Schnittstelle und eine budgetbewusste Review-Zuweisung. Der Haken ist die schleichende Ausweitung der Produktkategorie. Das Tool muss SAST, Secret-Scanning und Abhängigkeitsanalyse ergänzen, statt sich als deren Ersatz zu vermarkten.

3. Herkunftsnachweis für KI-Änderungen

Ein schlankes CLI samt Pull-Request-Bot für Agenturen und regulierte Teams kann das deklarierte Tool, die Sitzungskennung, geänderte Dateien, ausgeführte Tests, Reviewer-Entscheidungen und die letztlich verantwortliche Person erfassen und daraus einen signierten Veröffentlichungsnachweis erstellen. Das Produkt soll den Prozess belegen, nicht anhand des Codestils die Urheberschaft erraten.

In den USA entfallen monatlich etwa 210 Suchanfragen auf „ai generated code detector“, bei einem CPC von $16.70. Dahinter steckt eine reale Sorge, doch Erkennung ist das falsche Produktversprechen. Die verkaufbare Version liefert Käufern stattdessen Nachweise über Prüfung und Verantwortung. Der Haken ist die Mitwirkung: Können Teams die Erklärung umgehen, wird der Nachweis zur bloßen Inszenierung. Branch-Schutz und Identitätsintegration sind das Produkt, kein optionales Zubehör.

Auch bei den Quellenangaben besteht eine Lücke. Die ChatGPT-Zitationsprüfung ergab keine wiederkehrend zitierten Quellen für „ai code review tools“. Ein Produkt, das ein sorgfältiges, versioniertes Richtlinienschema und transparente Kontrollen veröffentlicht, kann zur Referenzebene werden und zugleich das dahinterliegende Durchsetzungsprodukt verkaufen.

Grenzen und eine ehrliche Einordnung

KI-Prüfung ist ein nützlicher Filter, aber kein Sicherheitsnachweis. Laut GitHub kann eine Copilot-Prüfung Probleme übersehen und muss durch menschliche Prüfung ergänzt werden. Zudem nimmt sie einige Dateien aus, kann bei nicht verfügbaren Runnern auf einen weniger leistungsfähigen Modus zurückfallen und wird beendet, sobald das Budget für KI-Credits erschöpft ist. Keine dieser Bedingungen darf die Anforderungen für einen Merge unbemerkt senken.

Für agentenbasierte Autofixes gilt dieselbe Grenze. Das Public-Preview-System von GitHub kann eine Codebasis untersuchen, einen Fix vorschlagen, CodeQL erneut ausführen und einen Pull-Request-Entwurf öffnen – häufig innerhalb von zwei bis vier Minuten. GitHub weist außerdem darauf hin, dass das System nach dem Best-Effort-Prinzip arbeitet, Korrekturen für einige benutzerdefinierte oder um Sicherheitsfunktionen erweiterte Abfragen nicht bestätigen kann und die Qualität von Fixes für Warnungen Dritter nicht garantiert. Ein grüner erneuter Durchlauf beweist nur, dass ein Detektor keinen Anlass zur Beanstandung mehr findet. Er beweist nicht, dass das fachliche Verhalten, das Berechtigungsmodell oder der umgebende Workflow sicher sind.

Diese Richtlinie löst weder die Erkennung der Urheberschaft noch schwache Tests, fehlendes Architekturwissen oder eine Kultur, in der Pull Requests nur abgenickt werden. Sie ist außerdem zu schwergewichtig, wenn jeder Tippfehler im kritischen Pfad landet. Routine muss günstig und Kritisch selten bleiben. Und das Tool, das eine Änderung erzeugt hat, darf nie die einzige Instanz sein, die sie freigibt.

Was am Montag konkret zu tun ist

Am Montag ergänzt die Engineering-Leitung die Pull-Request-Vorlage um fünf Felder: AI-assisted, tool, scope, human owner und tests run. Danach werden .github/workflows/, Authentifizierung, Zahlungen, Produktionsinfrastruktur, Secrets und destruktive Migrationen als Kritisch markiert. Für diese Pfade sind erfolgreiche CI, die Prüfung durch einen Code Owner, das Verwerfen veralteter Freigaben und ein zweiter Mensch vorgeschrieben. Das genügt, um aus einer Haltung zu KI-Code eine durchsetzbare erste Version zu machen.

Muss KI-generierter Code geprüft werden?

Ja. Zuerst laufen Tests und deterministische Scanner, anschließend dient die KI-Prüfung als zusätzlicher Kritiker. Die Verantwortung für den Merge trägt danach ein namentlich benannter Mensch. Eine KI-Prüfung darf die vorgeschriebene menschliche Freigabe nicht erfüllen.

Kann ChatGPT ein Code Review durchführen?

ChatGPT kann einen Diff kritisch prüfen, fehlende Tests anmahnen und auf verdächtige Logik hinweisen. Es kann weder den Branch-Schutz durchsetzen noch belegen, dass die CI gelaufen ist; ebenso wenig kann es die Folgen im Produktivbetrieb verantworten. Es gehört in die Richtlinie, nicht an deren Stelle.

Welche KI eignet sich am besten für Code Reviews?

Am besten passt die Lösung, die genügend Repository-Kontext versteht, sich in vorhandene Prüfungen integriert, Datenschutzvorgaben einhält und eine klare Auditspur hinterlässt. Die Modellqualität zählt, doch die Integration in den Merge-Kontrollpunkt und die menschliche Verantwortung zählen mehr.

Gibt es ein kostenloses Tool für AI Code Review?

Einzelne Bausteine sind kostenlos oder bereits enthalten. GitHubs klassisches Copilot Autofix erfordert für geeignete Repositorys kein Copilot-Abonnement und verbraucht keine KI-Credits; viele deterministische Kontrollen lassen sich mit vorhandenen CI-Tools durchsetzen. Eine vollständige Richtlinie braucht dennoch Konfiguration und menschliche Prüfung.

Für die Integration dieses Review-Kontrollpunkts in den eigenen Engineering-Workflow bieten KI-Produktionssysteme den nächsten Schritt.