QUELLENVERGLEICH / Agentisches Programmieren · Reviews & Verständnis
KI-generierten Code prüfen:
drei Ansätze zur Freigabe
Menschliche Freigabe, risikobasierte Automatisierung und von Agenten geführte Reviews sind drei Ansätze für KI-generierte Änderungen. Der Vergleich erläutert ihre Voraussetzungen, Unterschiede zwischen den Quellen und die Engpässe, die sich mit zunehmender Nutzung verschieben.
- Artikeldatum
Aktualisiert- Stand der Ausgangsnotizen
- Letzte Quellenprüfung
KURZFASSUNG
Kerngedanken.
- Review, Freigabe und Deployment sind getrennte Entscheidungen, die sich auf Nachweise mit einem bestimmten Geltungsbereich stützen.
- Wer über die Freigabe entscheidet, hängt vom Ansatz ab. Die Freigabe kann bei einer Person, auf einem vom Risiko abhängigen Entscheidungsweg oder in einem von Agenten geführten Ablauf liegen.
- Mehr Autonomie erfordert belastbare Verifikation und klare Entscheidungsbefugnisse.
01QUELLENVERGLEICH
Verifikation, Review und Freigabe
Bei der Selbstverifikation führt der Agent, der den Code schreibt, selbst Prüfungen aus. Ein Review untersucht die Änderung und ihre Annahmen. Freigabe, Merge und Deployment sind davon zu unterscheidende Entscheidungen oder Handlungen. Anhand dieser Unterscheidungen lässt sich vergleichen, was die einzelnen Quellen unter menschlicher Aufsicht verstehen.
Beobachtbare Akzeptanzkriterien legen fest, was ein Agent überprüfen kann. Dazu gehören erwartetes Verhalten, Tests, Builds oder eine laufende Oberfläche. Anthropic empfiehlt ausführbare Prüfungen, deren Rückmeldungen der Agent für Korrekturen nutzen kann. Ein bestandener Check stützt Aussagen innerhalb seines festgelegten Prüfbereichs. Vollständige Korrektheit oder eigenständiges Verständnis weist er damit nicht nach. [01]
OpenAIs Codex Best Practices empfehlen aufgabenbezogene Tests, Linting, Formatierungs- oder Typprüfungen sowie eine Prüfung des Verhaltens und des Diffs. Die Anweisungen können in Prompts oder AGENTS.md stehen. Dass eine feste Testsuite automatisch ausgeführt wird, ist damit nicht garantiert. [02]
Der begleitende Artikel „Mit Agenten entwickelte Software testen“ behandelt Testziele, Testqualität, Abdeckung und Methoden für Sicherheitstests ausführlicher.
02QUELLENVERGLEICH
Drei Ansätze für Review und Freigabe
Die Quellen unterscheiden sich darin, wer eine Änderung freigibt. Die Freigabe kann bei einer Person, auf einem vom Risiko abhängigen Entscheidungsweg oder in einem von Agenten geführten Ablauf liegen. Danach sind die Quellen hier gruppiert. Die Ansätze können nebeneinander bestehen. Diese Einteilung soll den Vergleich erleichtern und ist weder ein Reifegradmodell noch ein Branchenstandard.
Selective Review bedeutet hier, menschliche Aufmerksamkeit nach Risiko, Umfang und verfügbaren Nachweisen einzusetzen. Zu entscheiden ist, welche Änderungen genauer geprüft werden müssen, einen separaten Reviewer benötigen oder eskaliert werden sollen. Verbindliche Prüfungen und die Grenzen der Freigabebefugnis gelten weiterhin.
Alle drei Ansätze setzen Codeverständnis, belastbare Verifikation und klare Entscheidungsbefugnisse voraus. Die anschließend beschriebenen Nutzungsstufen von Cherny betreffen die Arbeitsorganisation. Sie legen keine Freigaberichtlinie fest.
GRAFISCH ERLÄUTERT
Prüfung, Freigabe und Integration im Vergleich
Befunde und Korrekturen benötigen Nachweise.
Die Freigabe bleibt bei einem Menschen.
Befugnisse für Merge und Deployment bleiben getrennt.
Befunde und Korrekturen benötigen Nachweise.
Kritische Bereiche und Ausnahmen werden von Menschen geprüft. Stichproben und Aufsicht bleiben bestehen.
↳ MENSCHLICHER ENTSCHEIDUNGSWEG FÜR AUSNAHMEN
Befugnisse für Merge und Deployment bleiben getrennt.
Befunde und Korrekturen benötigen Nachweise.
Menschen setzen Ziele und gestalten die Umgebung. Das menschliche Review einzelner PRs ist in diesem Projekt optional.
Befugnisse für Merge und Deployment bleiben getrennt.
Die Abläufe zeigen, wer eine Änderung prüft, wer sie freigibt und wie sie anschließend integriert wird. Die Beispiele stammen aus unterschiedlichen Quellen und können nebeneinander bestehen. Sie bilden weder eine Abfolge von Reifegraden noch eine allgemeine Richtlinie.
Drei Ansätze für Review und Freigabe im Vergleich
Die Übersicht vergleicht, wer eine Änderung prüft, wer sie akzeptieren darf und wo Menschen eingreifen. Die dargestellten Zusammenhänge lassen auch parallele und wiederholte Prüfungen zu.
| Ansatz | Prüfung der Änderung | Befugnis zur Freigabe | Menschliche Beteiligung |
|---|---|---|---|
| Menschliche FreigabeAnthropic-Playbook [01] | Automatisiertes Review und Korrekturen mit angemessener menschlicher Prüfung. | Die Freigabe bleibt an der dokumentierten Stelle bei einem Code Owner. | Bei der Freigabe prüfen Menschen die Absicht, die Annahmen und die folgenreichen Teile der Änderung. |
| Risikobasierte AutomatisierungAnthropic-Praxisbericht [02] | Reviewer mit abgegrenztem Prüfauftrag und Verifikation unter menschlicher Aufsicht. | Ausgewählte Änderungen können automatisch freigegeben werden. Über Ausnahmen entscheiden Menschen. | Kritische Bereiche, Ausnahmen, Stichproben und Prüfung des automatisierten Prozesses. |
| Von Agenten geführtes ReviewOpenAI-Projektbericht [03] | Agenten in einer gezielt aufgebauten Verifikationsumgebung. | Ein von Agenten geführter Integrationsablauf innerhalb delegierter Befugnisse. | Ziele, Akzeptanzkriterien, Umgebung und Ausnahmen. Das menschliche Review einzelner PRs ist in diesem Projekt optional. |
- [01] Menschliche Freigabe
Agenten untersuchen die Änderung und korrigieren sie. An der dokumentierten Stelle der Freigabe entscheidet weiterhin ein Mensch. Bei CodeMender prüfen menschliche Forschende die Patches von 2025 vor der Einreichung bei den Maintainern. Dort ist der Ablauf anders organisiert. [10] [12]
- [02] Risikobasierte Automatisierung
Ausgewählte Änderungen können automatisch freigegeben werden, während kritische Bereiche, Stichproben und die Leistung der Reviewer von Menschen geprüft werden. Das setzt ausdrückliche Risikostufen, deren Durchsetzung und Rückmeldungen voraus. [09]
- [03] Von Agenten geführtes Review
Der Ablauf stützt sich auf menschlich festgelegte Ziele, Akzeptanzkriterien und eine gezielt aufgebaute Verifikationsumgebung. Ein menschliches Review jedes PRs ist darin nicht vorgeschrieben. Die berichteten Voraussetzungen und Unsicherheiten gehören zu diesem Beispiel. [04]
03QUELLENVERGLEICH
Menschliche Freigabe und Codeverständnis
BSI und ANSSI betonen das Verständnis generierten Codes. Die technischen Beispiele legen fest, an welchen Stellen menschliche Freigabe weiterhin erforderlich ist. Automatisierte Analyse unterstützt beides.
BSI und ANSSI
Die Leitlinie geht davon aus, dass Entwickler generierten Code prüfen und verstehen. Automatisierte Funktionstests, Security-Reviews und weitere Werkzeuge ergänzen diese Prüfung. Die Leitlinie behandelt auch Automatisierungsbias, den Verlust von Fähigkeiten und den zusätzlichen Sicherheitsaufwand, den mehr Output verursachen kann. [21]
Anthropic — Freigabe durch einen Code Owner nach automatisiertem Review
Der Pull-Request-Ablauf verbindet automatisierte Reviews und Korrekturschleifen mit der Freigabe durch einen Code Owner, die über Branch Protection durchgesetzt wird. Das Review unterscheidet wichtige Fehler von kleineren Vorschlägen und prüft Spezifikation und Plan. Der schreibende Agent kann seine eigene Arbeit nicht freigeben. [10]
Wiederkehrende Befunde werden in die Projektanweisungen aufgenommen. Außerdem werden die Qualität der Reviewer, störende Kommentare und übersehene Fehler beobachtet. Die Freigabe durch einen Code Owner bleibt ausdrücklich vorgesehen. Daneben behandelt das Playbook weitere wichtige Entscheidungen, die Menschen treffen müssen. [10]
Google DeepMind — Validierung von Sicherheitspatches
CodeMender untersucht die Ursachen von Schwachstellen, erzeugt Sicherheitspatches und validiert sie mit Werkzeugen zur Programmanalyse und spezialisierten Agenten. Die Prüfungen betreffen Korrektheit und Regressionen. Sicherere APIs und Datenstrukturen können zudem ganze Klassen von Schwachstellen beseitigen. Im veröffentlichten Ablauf prüfen menschliche Forschende jeden Patch vor der Einreichung bei den Maintainern. [12]
Die Ankündigung von Gemini 3.5 Flash Cyber vom Juli 2026 beschreibt zusätzlich einen stärker skalierbaren Ansatz für Schwachstellenanalyse und Patching, legt aber keine allgemeine Pflicht zum menschlichen Review gewöhnlicher Funktionsänderungen fest. [13]
GitHub
GitHub stellt Copilot Code Review als Ergänzung zum menschlichen Review dar und empfiehlt, Vorschläge zu prüfen. Das Reviewprodukt, der Cloud-Agent und andere Oberflächen haben unterschiedliche Fähigkeiten und Sicherheitsprüfungen. [14]
04QUELLENVERGLEICH
Risikobasierte Automatisierung
Clinton beschreibt automatisierte Freigaben und den Umgang mit Ausnahmen. Fung erläutert, auf welche Aufgaben ein Team menschliche Expertise konzentriert. Eine Regel für automatische Merges legt sie dabei nicht fest.
Anthropic — Review und Merge nach Risikostufen
Clinton beschreibt eine Automatisierung nach Risikostufen. Dazu gehören ausgewählte Reviews und Merges durch Claude. In kritischen oder regulierten Bereichen bleiben menschliche Reviews vorgesehen, teilweise für eine gesamte Codebasis. Reviewer mit eng begrenztem Prüfauftrag arbeiten mit separaten Kontexten und Wissen über Vorfälle. Ihre Befunde müssen sie mit Nachweisen begründen. Konventionelle Analyse bleibt Teil des Prozesses. [09]
Neue Reviewer beginnen im Shadow Mode. Menschen validieren ihre Ergebnisse, und bewusst problematische Änderungen dienen als Testfälle. Automatisierte Freigaben werden protokolliert und anhand risikobasierter Stichproben geprüft. Sicherheitsinvarianten können ein manuelles Review auslösen. [09]
Anthropic — Menschliche Expertise an kritischen Grenzen
Fung beschreibt, wie Claude routinemäßige Rückmeldungen, Fehlerkorrekturen und Tests übernimmt. Menschliche Expertise konzentriert sich auf Vertrauensgrenzen, sicherheitssensiblen Code, die Toleranz für rechtliche Risiken und Produktentscheidungen. Mit mehr generiertem Code verschieben sich die Engpässe zur Verifikation und Sicherheit. Der Bericht beschreibt die Praxis eines Teams und keine vollständige technische Merge-Richtlinie. [08]
05QUELLENVERGLEICH
Von Agenten geführte Reviews und Integration
OpenAI beschreibt ein Projekt, in dem Agenten Implementierung, Verifikation, Review und Integration übernehmen. Die Umgebung wurde gezielt dafür aufgebaut.
OpenAI — Entwicklung mit Agenten im Mittelpunkt
In diesem eigens dafür aufgebauten Projekt implementieren Agenten Änderungen, prüfen sie, fordern Reviews anderer Agenten an, bearbeiten Rückmeldungen und führen manchmal einen Merge durch. Menschliche Reviews einzelner Pull Requests sind möglich, aber nicht erforderlich. Menschen setzen Ziele, gestalten die Umgebung und validieren Ergebnisse. [04]
Dieser Ablauf setzt umfangreiches Wissen über das Repository, beobachtbare Anwendungen, ausführbare Prüfungen und architektonische Vorgaben voraus. Die wenig restriktiven Merge-Gates und der Umgang mit instabilen Tests (flaky tests) gehören zu dieser speziellen Umgebung. Wie sich die Architektur langfristig verhält, bleibt offen. [04]
Hinweise zur Nutzung von Codex
Die allgemeinen Hinweise empfehlen klare Ziele, Kontext, Projektanweisungen, Erfolgskriterien, Tests und ein Review, bevor Änderungen akzeptiert werden. Sie sind von dem oben beschriebenen autonomen Projekt zu unterscheiden. [05]
06QUELLENVERGLEICH
Boris Cherny: Stufen der KI-Nutzung
Chernys persönliches Modell beschreibt, wie sich die Arbeitsorganisation verändert, wenn Agenten stärker genutzt werden. Die Nutzungsstufe beantwortet dabei eine andere Frage als die Richtlinie zur Freigabe.
Vier Schritte mit einer zugangsbeschränkten Ausgangsstufe
Cherny beschreibt die Einführung über Selbstverifikation, Automatisierung, Isolation und Schutzvorkehrungen. Fortschritt wird dabei am Beseitigen von Engpässen statt an der Tokennutzung gemessen. Sein verlinktes Modell umfasst vier Stufen mit einer vorgeschalteten Stufe 0, „Gated“. [15] [16]
ARBEITSORGANISATION
Auch bei veränderter Arbeitsorganisation müssen die Entscheidungsbefugnisse festgelegt werden.
00 / ZUGANGSBESCHRÄNKT (GATED)Organisatorische oder technische Beschränkungen begrenzen den Zugang. Zunächst müssen der Zugang ermöglicht und geeignete Schutzvorkehrungen für die Governance geschaffen werden. [16]
- 01
Assistiert
Eine Person ↔ ein Agent
PersonAgentGemeinsame Arbeit an jeweils einer Aufgabe.
- Arbeit der Agenten
- Eine Person arbeitet synchron mit einem Agenten.
- Rolle des Menschen
- Prüft fast jede Änderung vor dem Merge. Menschliche Aufmerksamkeit begrenzt den Durchsatz.
- Verifikation und Schutzvorkehrungen
Der Übergang zur nächsten Stufe setzt voraus, dass der Agent Arbeit mit Tests, Builds, Linting und Prüfungen in einer realen Umgebung Ende zu Ende verifizieren kann. [16]
- 02
Parallel
Eine Person → mehrere Agenten
KoordinationAgent AAgent BAgent CFür die Ergebnisse aller parallelen Aufgaben steht dieselbe Reviewkapazität zur Verfügung.
- Arbeit der Agenten
- Mehrere Agenten prüfen ihre Arbeit vor der Übergabe selbst.
- Rolle des Menschen
- Eine Person koordiniert mehrere Agenten. Menschliche Reviews des abschließenden Diffs und manuelle Security-Reviews bleiben ausdrücklich vorgesehen. Zuständigkeit und Reviewkapazität werden zu wichtigen Begrenzungen.
- Verifikation und Schutzvorkehrungen
In der hier beschriebenen Stufe sind automatisierte Code- und Security-Reviews standardmäßig aktiviert, zusammen mit ausdrücklichen Schutzvorkehrungen für den Merge. Das beschreibt die Stufe dieses Modells, nicht jede Claude-Installation. [16]
- 03
Beaufsichtigte Autonomie
Aufsicht → delegierte Agentenarbeit
Menschliche AufsichtKoordinierender AgentDelegierte AgentenAgenten organisieren fortlaufende Arbeit innerhalb festgelegter Grenzen.
- Arbeit der Agenten
- Agenten delegieren an andere Agenten und übernehmen fortlaufende Arbeit, einschließlich Wartung im Hintergrund.
- Rolle des Menschen
- Beaufsichtigt umfangreichere Arbeiten.
- Verifikation und Schutzvorkehrungen
Mehr Kontext über die Organisation, automatisierte Reviews, Isolation und hinterlegte Standards unterstützen diesen Übergang. [16]
- 04
KI-nativ
Begrenzte Ziele → Ausführung durch Agenten
Ziel und GrenzenAusführung durch AgentenMenschliche Aufsicht bei AusnahmenDer Umgang mit Ausnahmen bleibt sichtbar.
- Arbeit der Agenten
- Agenten verfolgen Ziele innerhalb eines abgegrenzten Bereichs.
- Rolle des Menschen
- Menschen überwachen Ausnahmen.
- Verifikation und Schutzvorkehrungen
Aufgabenspezifische Schutzvorkehrungen bleiben wichtig. [16]
Das Modell legt keine allgemeine Regel für die Freigabe von PRs fest. Die Kontrollen der Stufe 2 lassen sich nicht einfach auf spätere Stufen übertragen. Deren Autonomiebezeichnungen befreien sie ebenfalls nicht von Reviews. Die Angaben beruhen auf einer dokumentierten Lektüre vom 20. Juli, weil der Inhalt des verlinkten Artefakts am 14. Oktober nicht abgerufen werden konnte. Chernys LinkedIn-Beitrag wurde erneut geprüft. [16] [15]
Boris Cherny zu den Anforderungen an die Codequalität
Cherny unterscheidet zwischen Wegwerfprototypen mit geringen Auswirkungen und Code für den Produktiveinsatz. Für Code, den Claude für den Produktiveinsatz generiert, fordert er einen höheren Qualitätsanspruch, unterstützt durch Linting, Tests, Ende-zu-Ende-Prüfungen, Fuzzing, automatisierte Reviews und Wartung. Wenn Ergebnisse nicht genügen, können bessere Anweisungen, stärkere Steuerung oder eine Neufassung nötig sein. Die Aussage schreibt nicht vor, jeden Pull Request mit solchem Code manuell zu lesen. [17]
07QUELLENVERGLEICH
Qualität der Reviewer und Grenzen der Werkzeuge
Die Qualität der Reviewer ist bei allen drei Ansätzen wichtig. Dabei sind die Befunde eines Reviewprodukts, Statuschecks und die Richtlinie für Merges zu unterscheiden.
OpenAI — Code-Reviews im großen Maßstab
Das Team nutzt automatisierte Reviews als zusätzliche Schutzebene. Die Reviewer berücksichtigen den Kontext des gesamten Repositorys und verwenden Ausführungswerkzeuge, statt nur einen isolierten Diff zu betrachten. Das Team legt mehr Wert auf belastbare Befunde als auf viele Kommentare. Dabei wägt es übersehene Probleme gegen Fehlalarme ab. [03]
Das Training der Reviewer ist eine eigene Aufgabe. Eine Evaluation anhand von Problemen, die Menschen bestätigt haben, weist nicht nach, dass auch unbekannte Fehler abgedeckt sind. Eine separate Reviewaufgabe belegt außerdem keine statistische Unabhängigkeit vom Modell, das den Code erzeugt. [03]
Claude Code Review
Der verwaltete Dienst untersucht Änderungen im Kontext des Repositorys und meldet Befunde. Sein Check endet mit einem neutralen Status. Die Befunde geben einen Pull Request weder frei noch blockieren sie ihn. Dafür benötigt das Projekt ein separat konfiguriertes Merge-Gate. Der lokale Review-Skill gehört zu einem anderen Ablauf. Er bedeutet nicht, dass der verwaltete Dienst automatisch jede Programmiersitzung prüft. [06]
Automatisierte Security-Reviews in Claude Code
Der Leitfaden unterscheidet den bei Bedarf aufgerufenen Befehl /security-review von einer GitHub Action, die installiert und konfiguriert werden muss. Befunde müssen ergänzend zu bestehenden Sicherheitspraktiken und manuellen Reviews untersucht werden. Gewöhnliche Programmieraufgaben erhalten dadurch nicht automatisch ein Security-Review. [07]
Claude Security
Die Dokumentation dieses eigenständigen Sicherheitsprodukts beschreibt das Finden von Schwachstellen, die Validierung von Befunden und Patchvorschläge zur Prüfung. Diese Funktionen gelten nicht für jeden Ablauf mit Programmieragenten oder PR-Reviews. [11]
08QUELLENVERGLEICH
Aufmerksamkeit, Kapazität und Verständnis
Die Entscheidung, was zuerst untersucht wird, die Reviewkapazität und das Verständnis können zu Engpässen werden. Die folgenden Beiträge sind unterschiedlich stark belegt. Einer davon gibt eine Aussage nur indirekt als Position von Carlini wieder.
Sicherheitsuntersuchungen priorisieren
Ray Amjad gibt in seinem Video vom Juni 2026 aus dem Gedächtnis eine Carlini zugeschriebene Heuristik wieder. Ein LLM soll Dateien auf einer Skala von eins bis fünf danach einstufen, wie interessant ihr Inhalt ist. Anschließend werden höher eingestufte Dateien untersucht. Das ist ein indirekter Bericht, kein verifiziertes Zitat und keine offizielle Empfehlung von Anthropic. [18]
Die Aufteilung in ein günstiges und ein Premium-Modell sowie der weitergehende Patching-Ablauf stammen von Amjad. Ein niedriger Rang bedeutet in der hier verwendeten Einordnung eine geringere Untersuchungspriorität. Er belegt weder die Sicherheit noch rechtfertigt er, vorgeschriebene Prüfungen auszulassen.
Verantwortung dafür, Reviews anzustoßen
Steenfatt beschreibt die Aufforderung an einen Agenten, ein separates Security-Review durchzuführen. Dessen Schwerpunkt unterscheidet sich von der Implementierung einer Funktion. In seiner Darstellung stößt der Mensch das Review an, bezahlt die Tokennutzung und bleibt für das Projekt verantwortlich. Das bedeutet für ihn nicht, persönlich jede Codezeile zu lesen. [20]
Codeverständnis und Reviewkapazität
Das Interview behandelt den Unterschied zwischen formaler Verantwortung und den Fähigkeiten, die nötig sind, um generierte Arbeit zu beurteilen. Weitere Themen sind Prototypen zur Klärung einer Spezifikation, die Überlastung durch parallele Agenten und Code, dessen ursprüngliche Entscheidungsgründe nicht mehr verstanden werden. Als praktische Ansätze werden Entscheidungsprotokolle vorgeschlagen. Veralteter Kontext soll dabei nicht in den aktiven Anweisungen stehen. [19]
Diese Erfahrungen belegen nicht, dass eine Release-Richtlinie geeignet ist. Da das automatische Transkript die Sprecher nicht zuverlässig unterscheidet, werden die Aussagen dem Gespräch und nicht einzelnen Personen zugeschrieben.
CIS — Engpässe bei Validierung und Auslieferung
Atkinson untersucht, wie die Zahl entdeckter Probleme und erzeugter Patches schnell wächst, während Validierung, Priorisierung, die Klärung von Zuständigkeiten und Veröffentlichung langsamer vorankommen. Mehr Probleme zu finden oder zu beheben beseitigt diese nachgelagerten Engpässe nicht von selbst. [25]
09QUELLENVERGLEICH
Gemeinsame Anforderungen und Grenzen der Handlungsbefugnis
Die Absicherung von Software, Abhängigkeiten, Verständnis und die Handlungsbefugnis eines Agenten stellen unterschiedliche Anforderungen an den Reviewprozess.
NIST
PW.7.1 fordert die Auswahl menschlicher Reviews, werkzeuggestützter Analyse oder einer Kombination aus beidem. PW.7.2 behandelt die Durchführung, Dokumentation und Triage. Die Methode kann somit begründet ausgewählt werden. Ein manuelles Review jeder Zeile wird nicht vorgeschrieben. Zugleich werden damit keine beliebigen LLM-Reviews befürwortet. Zum Prüfzeitpunkt am 14. Oktober 2026 führte das Register SSDF 1.2 als Entwurf. [22] [23]
CISA, DARPA, OUSD(R&E) und NSA
Der Bericht fordert skalierbare Analyse und Forschung, einschließlich formaler Methoden und KI. Damit soll eine Lücke im Softwareverständnis geschlossen werden, die bereits vor dem generativen Programmieren bestanden hat. Eine allgemeine Regel für die Freigabe von Pull Requests enthält der Bericht nicht. [26]
ENISA
Wenn KI Pakete auswählt und diese Auswahl ungeprüft bleibt, kann der Überblick über Abhängigkeiten leiden. Ein Review sollte deshalb neben dem Anwendungsverhalten auch prüfen, ob die Pakete benötigt werden, wie sie im Inventar erfasst sind und wie mit Schwachstellen umgegangen wird. [27]
ISACA, NSA und internationale Partner
ISACA unterscheidet das Schlussfolgern des Modells von extern durchgesetzter Autorisierung und fordert menschliche Freigabe folgenreicher Handlungen. Die NSA-Ankündigung gemeinsamer Leitlinien, an denen unter anderem ASD’s ACSC und CISA beteiligt sind, betont eine vorsichtige Einführung, Verantwortung und menschliche Aufsicht. Hier geht es darum, was Agenten tun dürfen. Die Erlaubnis zu handeln und die Korrektheit einer Codeänderung sind getrennte Fragen. [28] [29]
10QUELLENVERGLEICH
Wenn Reviews überkorrigieren
Jin und Chen evaluierten fünf Modelle anhand von Python-Aufgaben aus HumanEval, MBPP und QuixBugs. Die Modelle beurteilten zunächst die Übereinstimmung mit Anforderungen, ohne Tests auszuführen. Die Aufforderung zu Erklärungen und Korrekturen konnte dazu führen, dass korrekter Code häufiger fälschlich abgelehnt wurde. [30]
Dieses Ergebnis ist auf die getesteten Modelle, Prompts und Aufgaben begrenzt. Es misst weder organisatorische Produktivität noch das wiederholte Review von Geschäftskonzepten. [30]
Anthropics Praxisleitfaden warnt unabhängig davon, dass Reviewer bei der gezielten Suche nach Lücken auch Änderungen an einwandfreier Arbeit vorschlagen können. Wer jedem Vorschlag nachgeht, kann dadurch Overengineering verursachen. Klare Anforderungen an die Korrektheit helfen zu unterscheiden, welche Änderungen erforderlich und welche nur optional sind. [01]
11QUELLENVERGLEICH
Meine Position zu Review und Freigabe
Die zunehmende Menge an erzeugtem Code erfordert aus meiner Sicht Reviewprozesse, die auch ohne das persönliche Lesen jeder einzelnen Zeile skalieren können. Zur Verantwortung gehört weiterhin, Reviews anzustoßen, ihren Umfang festzulegen, Zeit und Tokenbudget einzuplanen und auf Befunde zu reagieren.
Ein geeigneter Ablauf würde mit gemeinsamem Kontext, einer abgegrenzten Änderung und beobachtbaren Akzeptanzkriterien beginnen. Im Review werden Absicht, Architektur, Berechtigungen, Datengrenzen und Annahmen untersucht. Ein Befund braucht Nachweise für eine verletzte Anforderung, einen reproduzierbaren Fehler oder ein klar erläutertes Risiko.
Änderungen an sensiblen Berechtigungen, Übergaben zwischen Komponenten, widersprüchliche Anforderungen oder fehlende wesentliche Informationen können zusätzliche Reviews auslösen. Agenten können solche Auslöser erkennen. Verbindliche Prüfschranken müssen jedoch außerhalb des Agenten durchgesetzt werden. Diese Prinzipien teile ich. Sie bilden keinen gemeinsamen institutionellen Standard.
Der vorgeschlagene Ablauf würde Korrekturschleifen begrenzen, ungelöste Widersprüche eskalieren und Korrekturen anhand der ursprünglichen Kriterien prüfen. Selbstprüfungen, separate Reviews, menschliches Urteilsvermögen und die Befugnis zu Merge oder Deployment müssen dabei unterschieden werden. Auch zusätzliche Reviewer können dieselben blinden Flecken haben.
Wer Entscheidungsgründe festhält und aus übersehenen Fehlern lernt, kann die Arbeit besser nachvollziehen. Um den Fortschritt zu beurteilen, eignen sich akzeptierte und nutzbare Ergebnisse, deren Grenzen bekannt sind, besser als die Menge an Änderungen oder Kommentaren.
Welche Nachweise die Annahme einer Änderung stützen, wer darüber entscheiden darf und was ungewiss bleibt, hängt von der Aufgabe, der Umgebung und dem tatsächlichen Reviewprozess ab.
QUELLEN / 30
Quellen.
Dieser Vergleich berücksichtigt Leitlinien, technische Erfahrungsberichte, Produktdokumentation, Praxisberichte und eine empirische Studie mit unterschiedlichen Geltungsbereichen. Die Quellenhinweise nennen die jeweiligen Prüfzeitpunkte und machen kenntlich, wo frühere Lektüren übernommen wurden oder Originale nicht verfügbar waren.
- Anthropic — Best practices for Claude Code (öffnet in einem neuen Tab)
Claude eine Möglichkeit geben, seine Arbeit zu prüfen. Einen adversarialen Reviewschritt ergänzen. Fortlaufend gepflegte Dokumentation. Veröffentlichungsdatum nicht festgestellt.
- OpenAI — Codex best practices (öffnet in einem neuen Tab)
Anweisungen mit AGENTS.md wiederverwendbar machen. Zuverlässigkeit durch Tests und Reviews verbessern. Empfehlungen für konfigurierte, aufgabenbezogene Verifikation, keine garantierte automatische Checkliste.
- Maja Trębacz, Sam Arnesen, Albin Cassirer, Max Johnson, Xin Lin, Thibault Sottiaux and the Codex team — A Practical Approach to Verifying Code at Scale (öffnet in einem neuen Tab)
Precision und Recall. Repositorywerkzeuge. Training der Reviewer. Evaluation zuvor identifizierter Probleme und ihre Grenzen.
- Ryan Lopopolo / OpenAI — Harness engineering: leveraging Codex in an agent-first world (öffnet in einem neuen Tab)
Ablauf für Agentenreviews und Merges, gezielt aufgebaute Umgebung, Grenzen der Übertragbarkeit und offene Fragen. Inhalt aus der Prüfung vom 11. Oktober beibehalten.
- OpenAI — Best practices (öffnet in einem neuen Tab)
Kontext, Projektanweisungen, Verifikation und Tests. Inhalt aus den datierten Recherchenotizen vom 28. September beibehalten. Für diese Aktualisierung nicht erneut geprüft.
- Anthropic — Claude Code Review (öffnet in einem neuen Tab)
Verwaltetes Review, Verhalten bei neutralem Checkstatus und lokaler Reviewablauf.
- Anthropic — Automated Security Reviews in Claude Code (öffnet in einem neuen Tab)
Angezeigtes Seitendatum: 16. März 2026. Überblick, /security-review, Einrichtung der GitHub Action und ergänzende Rolle neben bestehenden Sicherheitspraktiken und manuellen Reviews.
- Fiona Fung / Anthropic — Running an AI-native engineering org (öffnet in einem neuen Tab)
Kontext sammeln. Code-Review: vertrauen, aber prüfen. Menschliche Fachexpertise und Maßstäbe für nützlichen Fortschritt.
- Jason Clinton / Anthropic — How Anthropic secures its AI-native software development lifecycle (öffnet in einem neuen Tab)
Testen (CI), Deployment (CD), Überwachung und Governance. Michael Segner wird als Mitwirkender gewürdigt. Bericht über interne Praxis.
- Louis Claxton / Anthropic — The AI-native SDLC playbook (öffnet in einem neuen Tab)
KI in der PR-Reviewschleife: Reviewrichtlinie, Korrekturschleife, Freigabe durch einen Code Owner und Funktionstrennung.
- Anthropic — Use Claude Security (öffnet in einem neuen Tab)
Sicherheitsbefunde, Validierung und vorgeschlagene Patches. Fortlaufend gepflegte Produktdokumentation.
- Raluca Ada Popa and Four Flynn / Google DeepMind — Introducing CodeMender: an AI agent for code security (öffnet in einem neuen Tab)
CodeMender in Aktion. Programmanalyse und Regressionsprüfungen. Review durch menschliche Forschende vor der Einreichung beim Ursprungsprojekt.
- Raluca Ada Popa and Four Flynn / Google DeepMind — Introducing Gemini 3.5 Flash Cyber (öffnet in einem neuen Tab)
Schwachstellen finden, validieren und patchen. Begrenzter Pilotversuch. Daraus wird keine allgemeine Richtlinie für die Freigabe von PRs abgeleitet.
- GitHub — Application card: GitHub Copilot Agents (öffnet in einem neuen Tab)
Vorgesehene Verwendung. Grenzen. Unterschiede zwischen Code-Review, Cloud-Agent und anderen Oberflächen.
- Boris Cherny — I talk to engineers at other companies every day… (öffnet in einem neuen Tab)
Nur der Hauptbeitrag. Keine Antworten oder Kommentare. Das genaue Veröffentlichungsdatum wurde bei der Recherche vom 28. September anhand der Seitenmetadaten festgestellt.
- Boris Cherny — Steps of AI Adoption (öffnet in einem neuen Tab)
Stufen 0–4 und Übergänge, aus dem dokumentierten erfolgreichen Inhaltsabruf beibehalten. Chernys eigener Beitrag verlinkt dieses Artefakt. Der aktuelle Inhalt konnte am 14. Oktober nicht abgerufen werden. Eine erneute inhaltliche Prüfung wird nicht behauptet.
- Boris Cherny — Every day, I get a lot of emails and messages… (öffnet in einem neuen Tab)
Nur der Hauptbeitrag: Wegwerfprototypen, Qualität von Code für den Produktiveinsatz und Schutzvorkehrungen. Das genaue Veröffentlichungsdatum wurde bei der Recherche vom 28. September anhand der Metadaten festgehalten.
- Ray Amjad — Anthropic Will Bring Back Fable 5 Differently (indirect Carlini attribution only) (öffnet in einem neuen Tab)
Passage zur Dateieinstufung, aus der datierten Quellenanalyse beibehalten. Carlinis Originalinterview und dessen Datum bleiben unverifiziert. Die anderen Abläufe des Videoautors werden Carlini nicht zugeschrieben.
- Florian Baader / Christoph Magnussen — Conversation on AI agents, code understanding and Company OS (öffnet in einem neuen Tab)
Beibehaltenes automatisches Transkript erneut gelesen: Befähigung und Spezifikation. Parallele Agenten. Dark Code. Entscheidungsprotokolle. Die Zuordnung einzelner Sätze zu Sprechenden ist begrenzt. Eine erneute Videowiedergabe wird nicht behauptet.
- Niklas Steenfatt — Vibe Coding hat sich verändert (öffnet in einem neuen Tab)
13:09–14:28: gezieltes Security-Review, Anstoßen der Arbeit, Tokenkosten und Verantwortung, ohne persönlich jede Zeile zu lesen. Automatische deutsche YouTube-Untertitel. Nicht anhand des Tons verifiziert. Als Praxisperspektive verwendet, nicht als allgemeine Freigaberichtlinie.
- BSI / ANSSI — AI Coding Assistants (öffnet in einem neuen Tab)
§3.3, S. 9, mit Kontext auf S. 8. Dokumentinhalt aus der Recherche vom 28. September beibehalten. Eine erneute Prüfung des BSI-PDFs war am 14. Oktober nicht möglich. Ankündigung des Herausgebers: 4. Oktober 2024.
- NIST — Secure Software Development Framework (SSDF), Version 1.1 (öffnet in einem neuen Tab)
Finale Veröffentlichung. PW.7.1 und PW.7.2, gedruckte S. 14 (PDF S. 23). Inhalt aus der Prüfung vom 11. Oktober beibehalten.
- NIST — SSDF publications register (öffnet in einem neuen Tab)
Version 1.1 final. Version 1.2 (17. Dezember 2025) zum Zeitpunkt dieser Prüfung weiterhin als Entwurf aufgeführt.
- CIS and SAFECode — Secure by Design v1.1 release (öffnet in einem neuen Tab)
Veröffentlichungsankündigung. KI-generierter Code und dieselben Test-, Review- und Validierungsprozesse.
- Sean Atkinson / CIS — Security Stagflation (öffnet in einem neuen Tab)
Validierung, Priorisierung, Governance und Kapazität für Veröffentlichungen. Veröffentlichungsdatum nicht festgestellt.
- CISA, DARPA, OUSD(R&E) and NSA — Closing the Software Understanding Gap (öffnet in einem neuen Tab)
Problemdefinition und Empfehlungen für skalierbare Analyse und Forschung. Inhalt aus den datierten Recherchenotizen beibehalten. Eine erneute Prüfung des PDFs war am 14. Oktober nicht möglich.
- ENISA — Technical Advisory: Package Managers (öffnet in einem neuen Tab)
§5.2, PDF S. 27. Transparenz über Abhängigkeiten und KI-gestützte Paketauswahl. Inhalt aus der datierten Recherche vom 28. September beibehalten. Für diese Aktualisierung nicht erneut geprüft.
- ISACA — Cybersecurity Recommendations for Securing AI Agents (öffnet in einem neuen Tab)
Abbildung 3: Durchsetzung von Richtlinien, Kontrolle der Ausgaben und menschliche Aufsicht. Autorisierung von Handlungen wird von Codekorrektheit unterschieden.
- NSA, ASD’s ACSC, Canadian Centre for Cyber Security, CISA, NCSC-NZ and NCSC-UK — Careful Adoption of Agentic AI Services (öffnet in einem neuen Tab)
Gemeinsame Veröffentlichung, identifiziert in der NSA-Ankündigung. Hier wird nur diese Ankündigung verwendet, keine detaillierten Aussagen aus dem verlinkten Leitlinien-PDF.
- Jin & Chen — Are LLMs reliable code reviewers? Systematic overcorrection in requirement conformance judgement (öffnet in einem neuen Tab)
Automated Software Engineering 33, Artikel 90. Abschnitte 3 und 5: fünf Modelle, drei Python-Benchmarks und promptabhängige falsche Ablehnung korrekten Codes. Aus der früheren Prüfung vom 14. Oktober beibehalten.