Code-Review in der Ära der Künstlichen Intelligenz - Wer überprüft den von KI generierten Code?

In meinem letzten Beitrag (AI173) habe ich “Überprüfung” als dritte neue Hürde nach dem kostenlosen Code genannt und am Ende einen Hinweis auf einen separaten Abschnitt gegeben. Hier ist die Erfüllung. Zunächst möchte ich ein Fazit ziehen: Wenn wir uns 2026 im Rückblick ansehen, ist die größte Variable, die von KI-Programmierwerkzeugen geliefert wird, nicht die Lizenzanzahl, nicht die Anzahl der Sitzplätze und nicht die Modellleistung, sondern die Überprüfungsbandbreite.

Langsam AI lernen

Ein Bericht von CodeRabbit aus dem Jahr 2025 analysierte 470 Open-Source-GitHub-PRs und kam zu dem Ergebnis, dass AI-generierter Code 1,7-mal mehr Fehler aufweist als rein menschlich erstellter Code (im Durchschnitt 10,83 vs. 6,45 Fehler pro PR, ohne Berücksichtigung von Dateigröße und Komplexität). Sicherheitslücken waren in den Unterkategorien um 1,57 bis 2,74 Mal höher - XSS 2,74-mal, unangemessene Passwortverarbeitung 1,88-mal, unsichere direkte Objektverweise 1,91-mal, unsichere Deserialisierung 1,82-mal; Logik/Korrektheit 1,75-mal, Lesbarkeit 3-mal+, Formatierung 2,66-mal, Fehlerbehandlung fast 2-mal.

Ein weiterer Bericht von Apiiro aus September 2025, der die Ergebnisse von Scans in den Repositories von Fortune-50-Unternehmen (Daten von Dezember 2024 bis Juni 2025) enthält, ergänzt diese Ergebnisse: AI-generierter Code führte zu einer Zunahme der monatlichen Sicherheitsentdeckungen von etwa 1000 auf über 10.000 ( 10-fache Steigerung ), eine Steigerung der Privilegierungslücken um 322% (absolute Zählung; nach Normalisierung auf die Codebasis geschätzte Steigerung von etwa 60-80%) und eine Steigerung der Architekturdesignfehler um 153%. Im gleichen Zeitraum sanken die syntaktischen Fehler um 76% und die logischen Bugs um 60%.

Langsam AI lernen

Die beiden Datenmengen zusammengefasst ergeben ein wichtiges Ergebnis, insbesondere im Kontext der Regulierung: Ein erheblicher Teil der 322%igen Anstieg von Privilegienlücken bei Apiiro fällt auf die Berechtigungsgrenzen - und diese sind in der Finanz- und Telekommunikationsbranche mit Kundenfonds und Kundendaten verbunden. AI-generierter Code kann zwar laufen, aber die Anzahl von Fehlern und Lücken steigt proportional, und die gefährlichen Lücken steigen heimlich. (Hinweis: Der CodeRabbit-Bericht stammt von einem Hersteller, während die Apiiro-Daten von einem Drittanbieter für Sicherheitslösungen stammen. Die Ergebnisse sind konsistent, aber die Methodik muss berücksichtigt werden.)

Diese Erkenntnis hat in Unternehmen zwei unerwartete Auswirkungen, die beide im Widerspruch zu den gängigen Erzählungen über Werkzeuge stehen.

Zwei unerwartete Auswirkungen

Unerwartete Auswirkung 1: Die Rolle der Entwickler ändert sich von “Code-Schreibern” zu “Code-Prüfern”, aber das Prüfen ist anstrengender als das Schreiben.

Slowly Learn AI 001: AI 工具的新常态

Ein kürzlich von JetBrains durchgeführter Umfrage im Januar 2026 unter mehr als 10.000 Entwicklern in acht verschiedenen Sprachen ergab, dass 90 % der Entwickler mindestens einen AI-Tool verwenden. Eine weitere Studie des Pragmatic Engineer im Februar 2026 fand heraus, dass 56 % der erfahrenen Entwickler sagen, dass sie mehr als 70 % ihrer Arbeit auf AI-Tools angewiesen sind (einschließlich der Entwickler, die intensiv AI-Tools verwenden). Dies ist kein gelegentliches Gebrauch von AI, sondern ein neuer Standard in der Arbeit der Entwickler. Die Produktionsbeziehungen wurden umgestellt: Das Schreiben von Code wurde zu einer AI-Aufgabe, und die Entwickler verbringen mehr Zeit damit, zu lesen und zu bewerten, also zu überprüfen. Lesen von Code ist ohnehin schwieriger und langsamer als das Schreiben von Code; Lesen von Code, das von AI erstellt wurde, und dabei auch noch die Grenzen der Einhaltung von Vorschriften und die Geschäftsregeln berücksichtigen zu müssen, ist ein erheblich höherer kognitiver Aufwand als das Schreiben von Code.

Dies ist der Grund, warum die Entwickler in den beiden Jahren 2025-2026 ständig sagen: “AI macht mich müde”. Hintergrund ist die Umkehrung der Schlussfolgerung der METR-Studie 2026.2 (frühere Studien fanden heraus, dass erfahrene Entwickler durch AI 19 % langsamer wurden; in der neuen Studie wurde dies teilweise umgekehrt, und neue Entwickler sind immer noch -4 % langsamer; die Gesamtschätzung lautet: “Die Bewertungsbreite ist enger als die Produktionsbreite”).

Gegenintuitives 2: Je stärker die AI-Tools, desto mehr braucht die Organisation nicht mehr Tools, sondern Governance.

慢慢学AI: Die Grenzen der künstlichen Intelligenz in der Softwareentwicklung

Die jüngsten Fälle von CodeRabbit und Apiiro haben gezeigt, dass die künstliche Intelligenz (KI) in der Softwareentwicklung nicht immer ein Erfolg ist. Die 1,7-fache Zunahme von Fehlern bei CodeRabbit und die 322%ige Zunahme von Sicherheitslücken bei Apiiro können als ein Versagen der KI angesehen werden. Doch wenn man diese Fälle aus der Perspektive der Theorie der Engpässe betrachtet, wird klar, dass die KI die Produktivität erhöht hat, aber die Fähigkeit zur Überprüfung nicht mitgehalten hat.

Ein System ist nur so stark wie sein schwächstes Glied. Die KI hat die “Schreib”-Fähigkeit verbessert, aber die “Überprüfungs”-Fähigkeit ist nicht mitgehalten. Wenn die Überprüfungs-Fähigkeit nicht verbessert wird, kann die KI zwar schnellere Ergebnisse liefern, aber die Organisationen sammeln dadurch auch mehr Schulden an.

Dies ist die Schlussfolgerung, die wir aus dem AI173-Modell ziehen können: Die Automatisierung eliminiert nicht die Engpässe, sondern verschiebt sie nur. Wenn wir dies auf die Softwareentwicklung anwenden, müssen wir hinzufügen, dass die Softwareentwicklung nicht nur ein einzelner Engpass ist, sondern vielmehr ein komplexes System mit mehreren Engpässen, die sich dynamisch verändern. Die Theorie der Engpässe (TOC) gilt für lineare Prozesse, aber in der Softwareentwicklung mit KI gibt es mehrere Engpässe, die sich parallel verändern. Der engste Punkt hat sich von der “Schreib”-Fähigkeit zur “Überprüfungs”-Fähigkeit verschoben, aber innerhalb der Überprüfungs-Fähigkeit gibt es drei weitere Engpässe: Validierung, Governance und Compliance-Überprüfung.

Diese Engpässe müssen unabhängig voneinander überwunden werden, um die Vorteile der KI in der Softwareentwicklung voll auszuschöpfen.

Langsam AI lernen: Die Bedeutung von Kontrolle bei der Einführung von KI-Entwicklungstools

Die praktische Bedeutung dieser Regel lässt sich in zwei Schichten unterteilen. Die erste Schicht besteht darin, dass vor der Einführung von KI-Entwicklungstools vier wichtige Sicherheitsmaßnahmen implementiert werden müssen: obligatorische manuelle Code-Reviews, automatisierte Tests (KI-Änderungen müssen lauffähig sein), Sicherheits-Scans (entsprechend den Standards für manuellen Code) und schrittweise Veröffentlichung (KI-Änderungen werden zunächst nur in kleinen Schritten veröffentlicht). KI-Änderungen dürfen nicht ohne Überprüfung bleiben.

Dies ist die Mindestanforderung, um das Problem der KI-Entwicklung zu lösen, indem man “KI-Entwicklung” zu “KI-Entwicklung + Organisation, die die Kontrolle übernimmt” erweitert. Ohne eine dieser Maßnahmen besteht das Risiko, die Kontrolle zu verlieren. Carlini hat im Januar und Februar 2026 ein Beispiel dokumentiert, das oft zitiert wird: Ein Forscher von Anthropic hat 16 Claude Opus 4.6-Agenten parallel über zwei Wochen, etwa 2000 Sitzungen und etwa 20.000 US-Dollar API-Kosten, einen 100.000-Zeilen-Rust-basierten C-Compiler von Grund auf geschrieben, der den Linux 6.9-Kernel kompilieren und den GCC-Torture-Test mit 99% bestehen kann. Es ist wichtig zu betonen, dass dies ein kontrolliertes Experiment in einem abgeschlossenen Bereich war, bei dem Carlini den Code nicht in die Produktion gebracht hat. Es kann als “extremes Gegenbeispiel ohne Überprüfung” verwendet werden, aber nicht als “Schnellstart” für die Einführung von KI-Entwicklungstools.

Wenn diese Sicherheitsmaßnahmen nicht implementiert werden, ist es nur eine Frage der Zeit, bis es zu Problemen kommt.

Langsam AI lernen

Die zweite Ebene ist subtiler: Der Schlüssel zur Überprüfung liegt nicht darin, Fehler zu finden, sondern die Architektur, die Compliance-Grenzen und die Geschäftskorrektheit zu bewerten. Die ältere Generation von Ingenieuren fällt oft in die Falle, die Überprüfung in der AI-Ära mit der traditionellen Code-Review zu verwechseln. Traditionelle Reviews konzentrieren sich auf “Ist dieser Code fehlerfrei?”, während Reviews in der AI-Ära sich auf “Sollte dieser Code in dieser Datei, diesem Projekt, dieser Compliance-Grenze existieren?” konzentrieren. Die von CodeRabbit und Apiiro gemeldeten Probleme (1,82-2,74-fache Sicherheitslücken bzw. 322% erhöhte Berechtigungslücken) sind Beispiele für diese Art von Problemen: Die AI hat keinen Fehler gemacht, aber sie hat den falschen Ort, die falschen Berechtigungen oder die falsche Standardkonfiguration gewählt. Diese Probleme können nicht in der IDE behoben werden und müssen am Review-Tisch verstanden werden.

In der Branche ist es üblich, GitHub/GitLab-Branch-Schutz und CODEOWNERS-Regeln nach “Dynamischer Schema/Auth/Billing/Compliance-Grenze” zu kennzeichnen und sie zur zweifachen Genehmigung (in der Finanz- und Telekommunikationsbranche üblicherweise Backup-Veto und nicht vollständige Überprüfung) zu leiten. Die Überprüfung der Architektur, der Sicherheits- und Compliance-Baselines sowie der Geschäftsregeln ist der eigentliche Zeitpunkt für die Überprüfung in der AI-Ära.

Einige Beispiele für Unternehmen, die diese Überprüfungsprozesse durchführen, sind:

a regional carrier (ein regionales Telekommunikationsunternehmen)
ein Finanzdienstleister wieWirecard / Solaris (DE)/TikTok Shop (Chinese fintech / ByteDance service)

Es ist wichtig zu beachten, dass die Überprüfung in der AI-Ära nicht nur auf die Suche nach Fehlern beschränkt ist, sondern auch die Architektur, die Compliance-Grenzen und die Geschäftskorrektheit bewertet. Dies erfordert eine andere Herangehensweise als die traditionelle Code-Review und erfordert eine tiefe Kenntnis der AI-Technologie und der Geschäftsprozesse.

Warum Unternehmen ihre Code-Review-Prozesse anpassen müssen

Wenn man diese beiden scheinbar widersprüchlichen Aspekte kombiniert, wird das Bild klar: In der Ära von KI müssen Unternehmen drei Dinge anpassen, um Code-Reviews effektiv durchzuführen - die Einbindung von Entwicklungsleitern in den Review-Prozess, die Integration von Compliance- und Architektur-Richtlinien in den PR-Workflow und die Berichterstattung von Fehlerraten und anderen Governance-Indikatoren an den Vorstand.

Diese drei Punkte entsprechen direkt den Anforderungen der “drei Verteidigungslinien” für die Modellregierung in der “Verordnung über die Verwaltung von Internet-Krediten für Geschäftsbanken”, die für die Aufsichtsbehörden leicht verständlich sind. Im Folgenden werden diese Punkte in vier Schritten erläutert.

Warum jetzt: Die Mechanismen der Validierung als neues Flaschenhals

Die im dritten Abschnitt von AI173 gemachte Zusage wird hier eingelöst. Die Besonderheit des Zeitfensters im Jahr 2026: Autonome Agenten (Claude Code, Codex) sind von der “Testphase” in die “Standardnutzung” übergegangen; Organisationen, die ihre Review-Prozesse vorher nicht aufgerüstet haben, werden in der vierten Quartals-Verkaufsperiode / der Jahresabschlussperiode / der regulären Prüfungsperiode der Aufsichtsbehörden mit Problemen konfrontiert.

Zunächst wird erläutert, warum die “Validierung” im neuen Flaschenhals am tiefsten unterschätzt wird, und dann wird sie zusammen mit den beiden anderen neuen Flaschenhälsen (die richtige Fragestellung, die Systemintegration) in einer Grafik dargestellt.
Scheren-Differenz: Codevolumen 6×, Review-Kapazität 1,3×
2024 H1 → 2026 H1 relativer Wert (Basislinie=1×); Gap = Risikoakkumulation

Zeit Relativer Wert

2024 H1
2025 H1
2025 H2
2026 H1
2026 H2

KI-Codevolumen 6× Review-Kapazität 1,3×

Gap = Risikoakkumulation (Defekte +1,7×, Sicherheitslücken +1,82–2,74×, Rechteausweitung +322 %)
Verhältnisse als richtungsweisende Darstellung, basierend auf JetBrains 2026.1-Umfrage, CodeRabbit 2025.12-Bericht, Apiiro 2025.9-Bericht

Die Wurzel des Problems liegt in der Tatsache, dass in den meisten Diskussionen über AI-Programmierung “Überprüfung” automatisch mit CI/CD, Einzeltests und Lint-Prüfungen gleichgesetzt wird.

Dies ist die Welt der Internet-Produkte: Code wird auf die Cloud bereitgestellt, Einzeltests sind grün, CI ist erfolgreich, Merge, Produktiv. Dieser Prozess funktioniert im Rhythmus der Internet-Produkte, aber wenn man ihn auf die Branchen Telekommunikation, Finanzen, Fertigung und E-Commerce überträgt, funktioniert er nicht: In diesen Branchen bedeutet “Überprüfung” Algorithmus-Registrierung, Sicherheitsprüfung, Datenexport-Bewertung, Change Advisory Board (Change Advisory Board (CAB))-Änderungsprüfung, Abrechnungsprüfung und regulatorische Berichterstattung, die nichts mit Code zu tun haben, aber jeweils mehrere Wochen dauern. AI173 hat bereits ein Bild gezeigt (Kodierungsbeschleunigung, Engpass bei der Überprüfung), das hier nicht wiederholt wird. Der Schwerpunkt liegt auf der Frage, die es aufwirft: Wie viele Überprüfungen muss der von AI generierte Code durchlaufen, bevor er in die Produktion geht?

Sieben Schritte zum Start: Automatisierte Tests + Code-Review + Sicherheits-Scans + Architektur-/ADR-Prüfung + Geschäftsregel-Prüfung + Compliance-Clearance + Graustufen-Test. Jeder Schritt verbraucht eine Portion Bandbreite. Diese sieben Schritte sind die “andere Seite” des Bildes von AI173 - die Beschleunigung von AI betrifft den Teil mit den geringsten Grenzkosten (GPU-Zeit, Lizenzgebühren), während die Überprüfung den Teil mit den höchsten institutionellen Kosten (Regulierung, Registrierung, Abrechnung) frisst.

Beispiel: Ein regionales Telekommunikationsunternehmen wie AT&T oder Deutsche Telekom muss seine AI-Modelle einer strengen Überprüfung unterziehen, bevor sie in die Produktion gehen. Dies umfasst die Überprüfung der Algorithmus-Registrierung, die Sicherheitsprüfung, die Datenexport-Bewertung und die Change Advisory Board (Change Advisory Board (CAB))-Änderungsprüfung. Jeder dieser Schritte kann mehrere Wochen dauern und verbraucht eine Portion Bandbreite.

Ein häufig unterschätztes Problem ist die Engführung von “Code-Review” auf “Code-Prüfung”.

Die beiden Hauptstränge der Code-Prüfung - Weinbergs egoless programming (NASA/akademischer Hintergrund) aus dem Jahr 1971 und Fagans Fagan-Inspektionen (IBM-Systemprodukt) aus dem Jahr 1976 - basieren auf der gleichen Annahme: Code wird zeilenweise geschrieben, der Autor versteht ihn am besten und nach der Fertigstellung wird er von einer anderen Person gelesen, um Fehler zu finden.

Künstliche Intelligenz (KI) zerstört diese Annahme: Code wird in wenigen Sekunden von der KI generiert, der Autor (KI) ist nicht an der Übertragung des Kontexts beteiligt und der Leser (Entwickler) steht vor einem fremden, generierten Objekt. Die ursprüngliche Annahme der Fehlerfindung ist nicht mehr gültig, die neue Annahme der Überprüfung lautet:

Sollte dieser Code in dieser Datei existieren?
Wird er die bestehenden Architektur-Entscheidungen umgehen?
Fällt er innerhalb der bestehenden Compliance-Grenzen oder außerhalb?
Wird seine Standardkonfiguration in der Produktion zu einem Sicherheitsrisiko werden?

Jede dieser Fragen erfordert ein Verständnis von Geschäft, Architektur und Compliance, und Werkzeuge können nur unterstützen. Dies ist die Erweiterung von “Code-Review” von einem Lint-Schritt in der CI/CD-Pipeline zu einem “Engineering-Governance-Schritt”.

Drei Ebenen des Review-Modells: AI-Vorprüfung, menschliche Kontrolle und Regeln der Governance

Die obige Analyse kann in eine handhabbare Struktur umgewandelt werden. Das dreistufige Modell ist kein Ersatz, sondern eine Überlagerung - jeder PR durchläuft alle drei Ebenen gleichzeitig, wobei jede Ebene ein anderes Problem behandelt.

Ebene 1 läuft auf Sekunden- bis Minuten-Ebene - jeder von AI geschriebene Codezeile wird zuerst von einem Tool überprüft. CodeRabbit, GitHub Copilot Review, Sourcery, Cursor BugBot und Antigravity Review können alle innerhalb von Sekunden bis Minuten nach der Erstellung eines PRs Kommentare abgeben, die Lint, Sicherheitslücken, wiederholten Code, Benennung und Abhängigkeitsrisiken abdecken. Der Budgetrahmen für diese Ebene ist sehr niedrig (die Anzahl der PRs kann beliebig hoch sein, die Tools haben alle die gleichen Abonnementkosten), die Abdeckungsrate ist hoch (jeder PR wird überprüft) und bildet die Grundlage für die Bandbreite. Aber auch die Blindheit dieser Ebene ist offensichtlich - **sie kann nicht die Architektur, die Einhaltung von Vorschriften und die Geschäftskorrektheit lösen**. Der Bericht von CodeRabbit lautet "Automatisches Abfangen der meisten offensichtlichen Probleme", aber die verbleibenden versteckten Risiken (Standardkonfiguration, Berechtigungsgrenzen, Ausnahmeverarbeitungspfade, die in Details versteckt sind) erfordern manuelle Eingriffe. Diese Ebene ist nur die Grundlage und nicht das Endziel.

Die menschliche Kontrolle und die Regeln der Governance sind die beiden anderen Ebenen, die auf dieser Grundlage aufbauen. Die menschliche Kontrolle überprüft die Architektur, die Einhaltung von Vorschriften und die Geschäftskorrektheit, während die Regeln der Governance sicherstellen, dass alle Vorschriften und Richtlinien eingehalten werden. Durch die Kombination dieser drei Ebenen kann ein umfassendes Review-Modell erstellt werden, das sowohl die technischen als auch die geschäftlichen Anforderungen abdeckt.

Langsames Lernen von KI: Die Bedeutung von Layer 2 bei der Code-Überprüfung

Bei der Überprüfung von Code-Änderungen ist es wichtig, zwischen verschiedenen Risikostufen zu unterscheiden. Hochriskante Änderungen, die das Kernmodul, die Datenbank-Schemata oder die Authentifizierung/Abrechnung/ Skalierbarkeit betreffen, müssen von einem Team aus Architekten, Geschäftseignern und Sicherheitsverantwortlichen sorgfältig überprüft werden. Dieses Team muss sicherstellen, dass die Änderungen nicht nur technisch korrekt sind, sondern auch die Sicherheitsanforderungen erfüllen.

Ein Beispiel hierfür sind die Ergebnisse von CodeRabbit und Apiiro, die zeigen, dass ein erheblicher Teil der Sicherheitslücken und Berechtigungslücken nur durch eine sorgfältige Überprüfung identifiziert werden kann. AI-generierter Code kann zwar technisch korrekt sein, aber die Default-Konfiguration, die Berechtigungsgrenzen und die Ausnahmehandhabung können in den Details versteckt sein.

Für mittlere und niedrige Risiken kann eine Stichprobennahme (z.B. 20-30% der Änderungen) durchgeführt werden, um die Überprüfung zu beschleunigen. Dies ist ein Prozess, der die menschliche Bandbreite von der “vollständigen Überprüfung” auf die “Überprüfung der wichtigsten Änderungen” freisetzt.

Ein häufiger Fehler bei dieser Methode ist die Absenkung der Standards, um die Überprüfung von AI-generiertem Code zu beschleunigen. Dies kann jedoch zu schwerwiegenden Folgen führen, wenn Sicherheitslücken oder andere Probleme nicht erkannt werden.

Es ist wichtig, die Standards hochzuhalten und die Überprüfung sorgfältig durchzuführen, um die Sicherheit und Qualität des Codes zu gewährleisten.

Langsames Lernen von KI: Die Herausforderungen von Layer 3

In der Welt der KI-Entwicklung gibt es verschiedene Ebenen, auf denen Änderungen vorgenommen werden können. Layer 3 ist die Ebene, auf der Änderungen die Grenzen der Konformität, der regulatorischen Berichterstattung, der Datenexporte, der SLAs und der Architektur zwischen Teams berühren. Hier kommen Change Advisory Board (Change Advisory Board (CAB)) (Change Advisory Board), die Bewertung von Änderungen, die Sicherheitsprüfung und die regulatorische Kommunikation ins Spiel. Dies ist die Ebene, auf der die Kosten für die Einhaltung von Vorschriften am höchsten sind.

Laut AI173 ist es so, dass KI nicht in der Lage ist, Layer 3 zu bewältigen, aber wenn Layer 1 und 2 gut gemacht sind, können etwa 80-90% der Änderungen mit niedrigem Risiko bereits im Vorfeld abgefangen werden. Die verbleibenden 10-20% der Änderungen mit hohem Risiko müssen dann durch Change Advisory Board (Change Advisory Board (CAB)) geprüft werden, wodurch die Bandbreite von Change Advisory Board (Change Advisory Board (CAB)) auf die tatsächlich benötigten Änderungen konzentriert wird. Durch die Verkürzung der Wartezeiten für Change Advisory Board (Change Advisory Board (CAB)) und die Beschleunigung des Gesamtprozesses entsteht ein “Governance-Bandbreitenbonus”, der leicht unterschätzt wird.

Die Konformitätsunterschrift für Layer 3 muss schriftlich erfolgen. Bei jedem durch Layer 3 ausgelösten PR muss eine vollständige Spur von Änderungen erhalten bleiben: PR-Diff + Bewertungskommentare + Geschäftseigentümer + Konformitätseigentümer mit doppelter Unterschrift + Zeitstempel + Anhang des Modellvalidierungsberichts. Die Aufbewahrungsfrist beträgt für die Finanzbranche 5 Jahre und für die Telekommunikationsbranche 3 Jahre (gemäß GDPR + BDSG §55 + Verordnung der Banken- und Versicherungsaufsichtsbehörde [2020] Nr. 24 + Verwaltungsanweisung für die Registrierung von Algorithmen des Ministeriums für Industrie und Informationstechnologie). Dies ist ein wichtiger Beweis für die regulatorische Kommunikation und nicht nur eine papierene Konformität.

Schrittweise lernen: AI

Dreischichtige Überlagerung: Schlüsseldesign

Die Auslösebedingungen werden durch Risikostufen kodiert und nicht durch Codezeilen oder PR-Größe. In der Praxis kann die Risikostufenbestimmung nicht von der AI-Selbstbewertung abhängig sein - AI hat kein Compliance-Bewusstsein und weiß nicht, dass die Änderung von Kundenidentitätsfeldern eine GDPR + BDSG-Rotlinie ist. Der PR-Initiator muss daher im PR-Template manuell auswählen (Schema ändern? Auth ändern? Billing ändern? Compliance-Grenzen ändern?) + CODEOWNERS-Regeln doppelt bestätigen. Basierend auf den ausgewählten Ergebnissen wird die entsprechende Ebene geroutet: Niedrigrisiko-PRs werden automatisch in Layer 1 gemergt (innerhalb von Whitelist-Pfaden + Fehler-Fallback-Mechanismus, wenn innerhalb von 30 Tagen ein automatischer Merge-PR zu einem Produktionsunfall führt, wird er angehalten und vollständig zurückgesetzt), mittlere Risiken werden in Layer 2 spot-check und hohe Risiken in Layer 3 Governance-Prozesse geroutet. Diese “Risiko-Selbstadaptions-Routing” ist die höchste Form der Überprüfung.

4. Auswahl der Überprüfungstools: CodeRabbit ist nicht die einzige Antwort, aber es ist der aktuelle Baseline

Dieser Abschnitt löst nur die Auswahl von Layer 1 - Layer 2/3 hängt hauptsächlich von der Organisation und den Prozessen ab, und die Tools können nicht viel dazu beitragen.

AI-Code-Review auf GitHub Marketplace: CodeRabbit führt die Liste an

CodeRabbit, ein Unternehmen, das im September 2025 eine Serie-B-Finanzierung in Höhe von 550 Millionen US-Dollar erhalten hat und ein ARR von 40 Millionen US-Dollar im zweiten Quartal 2026 erreicht hat (Quelle: Sacra Daten), ist der führende Anbieter von AI-Code-Review-Tools auf GitHub Marketplace. Es integriert “AI-Code-Reviewer” in den PR-Kommentarfluss, wobei jeder Kommentar einen klickbaren Erklärungstext, einen Reparaturvorschlag und eine Schweregradeinstufung enthält. Dies ist besonders effektiv für die Überwindung von Blindspots in Einzeltests. CodeRabbit ist eng mit GitHub Actions integriert und bietet eine Preiskalkulation nach PR-Menge an. Die Enterprise-Version bietet zusätzlich private Modelle, eine Whitelist und ein internes Wissensrepository. Die oben genannten 1,7-fachen Defekte und 1,82-2,74-fachen Sicherheitslücken sind Ergebnisse eines eigenen Berichts von CodeRabbit.

Warum GitHub Copilot Review CodeRabbit bevorzugt

Der einzige Grund, warum GitHub Copilot Review CodeRabbit bevorzugt, ist, dass es bereits auf GitHub Enterprise verfügbar ist und keine neuen Lieferanten benötigt. Die Regel kann diese Schwäche nicht tiefgreifend korrigieren, und mit der Zeit wird die Regelbibliothek von CodeRabbit überholt werden.

Code-Review-Tools im Vergleich

Für Python-Entwickler ist Sourcery das stärkste Tool für automatisierte Code-Reviews. Es kann bereits im PR-Stadium direkte Refactoring-Vorschläge machen (nicht nur Fehler finden, sondern auch Code umschreiben), was besonders bei der Vervollständigung von Typ-Annotationen und der Bereinigung von technischen Schulden hilfreich ist. Für Teams, die mehrere Sprachen verwenden, ist es jedoch nicht ausreichend - TypeScript und Go werden erst jetzt unterstützt, andere Sprachen sind nur teilweise abgedeckt.

Cursor BugBot hingegen ist stark, wenn es um die Kontextanalyse von Cursor-Editor-Dialogen geht. Es kann sehen, was Sie mit dem AI-Modell besprochen haben, und gibt gezielte Code-Reviews. Projekte, die nicht auf Cursor basieren, können dieses Tool jedoch nicht nutzen.

Antigravity Review ist eine Review-Funktion, die im November 2025 in die Antigravity-Plattform von Google integriert wurde. Sie basiert auf dem Gemini-3-Modell und den Unternehmens-Compliance-Funktionen von Google Cloud. Im ersten Halbjahr 2026 wird es weiterhin schnell weiterentwickelt, die Regelbibliothek ist jedoch noch nicht so umfangreich wie die von CodeRabbit, und die Preisgestaltung und Bereitstellungsmodelle für Unternehmen sind noch im Wandel.

Auswahlkriterien für Code-Review-Tools

Die Auswahlkriterien sollten in folgender Reihenfolge priorisiert werden: Anpassbarkeit der Regeln > Qualität der PR-Kommentare > Integrationsgrad > Preis. Langfristig gesehen sind Tools der ersten Ebene (Layer 1) von entscheidender Bedeutung, da unanpassbare Regeln zu einem “Lock-in” in das Sicherheitsmodell des Tools führen können. Eine schlechte Qualität der PR-Kommentare (z.B. “Hier sieht es nicht richtig aus, aber ich weiß nicht warum”) führt zu einer Verschwendung von Entwicklerzeit. Der Integrationsgrad beeinflusst die Einarbeitungszeit, und der Preis ist zwar nicht unwichtig, aber an vierter Stelle zu priorisieren, da die Preisdifferenzen zwischen Tools der gleichen Klasse weniger als 30% betragen.

Zwei wichtige Überlegungen bei der Auswahl

Erstens: In den Bereichen Finanzen, öffentliche Verwaltung, Verteidigung und Telekommunikation ist eine private Bereitstellung oder Selbstverwaltung ein Muss. Allerdings reicht die private Bereitstellung allein nicht aus - die Überprüfungstools müssen auf den gesamten Code zugreifen (PR-Diff + Repository-Historie), was bedeutet, dass der Code an einen Dritten übergeben wird. Daher ist ein Vertrag für die Datenverarbeitung durch Dritte erforderlich (GDPR + BDSG §21 Datenverarbeitung durch Dritte).

Zweitens: AI-basierte Überprüfung und manuelle Überprüfung sind nicht gegensätzlich - die Kombination von CodeRabbit und GitHub Copilot Review ist in großen Organisationen üblich. Diese Tools haben unterschiedliche Regeln und decken unterschiedliche Schwachstellen ab, sodass ein einzelnes Tool immer Schwachstellen aufweisen wird.

Fünf: Branchenspezifische Anwendungsfälle: Die verschiedenen Formen der Überprüfungsverbesserung in unterschiedlichen regulatorischen Kontexten

Telekommunikation - Überprüfung von Tarif- und Abrechnungsänderungen auf höherem Niveau

Ein regionale Carrier hat mir während eines AI-Workshops ein Diagramm gezeigt, das die 11 Schritte von der Kodierung bis zur Veröffentlichung einer Tarifänderung darstellt. Durch die Einführung von AI konnte die Kodierungszeit von 2 auf 0,5 Tage reduziert werden. Allerdings dauerten die Schritte Change Advisory Board (Change Advisory Board (CAB)), Algorithmus-Registrierung (im Zusammenhang mit dem Abrechnungsmodell), Sicherheitsprüfung, Datenexport (aufgrund der Verwendung eines ausländischen Modells, das die spezielle Ausfuhrliste des “Industrial and Information Technology Sector Data Security Management Measures (Trial)“ erfüllt, nicht jedoch den GDPR + BDSG-Standardvertrag) und Abrechnungsprüfung jeweils mehrere Tage bis zu einem Monat. Die Registrierung eines Algorithmus dauert in der Regel 4-6 Monate, von der Vorbereitung der Unterlagen bis zur Rückmeldung des Ministeriums für Industrie und Informationstechnologie - ein echter Engpass. Die Gesamtdurchlaufzeit blieb jedoch nahezu unverändert.

Die Richtung der Überprüfung auf höherem Niveau ist wie folgt:

Layer 1-Tools müssen in der Lage sein, Änderungen an den Abrechnungs-, Authentifizierungs- und Skalierungsmodulen zu erkennen und automatisch als hochrisikoreich zu kennzeichnen, um sie an die Layer 2-Geschäftseigentümer und Compliance-Eigentümer zur gemeinsamen Genehmigung weiterzuleiten.
Die Change Advisory Board (Change Advisory Board (CAB))-Schicht sollte nur bei Änderungen, die tatsächlich eine regulatorische Meldung erfordern, eine zweite Überprüfung durchführen.

Das Wesen dieser Vorgehensweise besteht darin, die Change Advisory Board (Change Advisory Board (CAB))-Bandbreite von allen Änderungen (einschließlich dringender Patches) auf 5.000-8.000 pro Monat auf die tatsächlich benötigten Änderungen (hochrisikoreich) auf 100-200 pro Monat zu reduzieren. Bevor die Überprüfung auf höherem Niveau eingeführt wurde, war die Change Advisory Board (Change Advisory Board (CAB))-Bandbreite der Engpass; nach der Einführung wurde die Change Advisory Board (Change Advisory Board (CAB)) jedoch zur schnellsten Schritt, da die vorherigen 8 Schritte durch Automatisierung und Regeln vorab überprüft wurden.

Langsam AI lernen: Die verborgenen Schmerzpunkte der Telekommunikationsbranche

Die Telekommunikationsbranche hat einen verborgenen Schmerzpunkt, der nicht Change Advisory Board (Change Advisory Board (CAB)) (Change Advisory Board) ist, sondern Modell-Interpretierbarkeit. Die Abrechnungsmodelle müssen in der Lage sein, die Quelle jeder einzelnen Rechnung zu erklären. Nachdem AI-Blackbox-Modelle online gegangen sind, müssen sie bei Beschwerden von Kunden nachvollziehbar sein. Die Top 3 Szenarien für Bundesnetzagentur Verbraucherbeschwerde Beschwerden (Nummernportierung, Rechnungsabrufbarkeit und An-/Abmeldung) erfordern vor der Online-Schaltung eine vorherige Prüfung durch die Gruppenverbraucherschutzbehörde. Dies kann nicht durch Change Advisory Board (Change Advisory Board (CAB)) ersetzt werden.

Beispiel: Ein regionaler Carrier wie AT&T oder Deutsche Telekom muss sicherstellen, dass seine Abrechnungsmodelle transparent und nachvollziehbar sind. Wenn ein Kunde eine Beschwerde über seine Rechnung einreicht, muss der Carrier in der Lage sein, die Quelle der Kosten zu erklären und die Berechnung nachzuvollziehen. Dies erfordert eine hohe Modell-Interpretierbarkeit, die nicht durch Change Advisory Board (Change Advisory Board (CAB)) allein gewährleistet werden kann.

Warum ist Modell-Interpretierbarkeit wichtig?

Kundenservice: Kunden erwarten transparente und nachvollziehbare Rechnungen. Wenn ein Kunde eine Beschwerde einreicht, muss der Carrier in der Lage sein, die Quelle der Kosten zu erklären und die Berechnung nachzuvollziehen.
Regulatory Compliance: Die Telekommunikationsbranche unterliegt strengen regulatorischen Anforderungen. Modell-Interpretierbarkeit ist erforderlich, um sicherzustellen, dass die Abrechnungsmodelle den regulatorischen Anforderungen entsprechen.
Geschäftliche Effizienz: Modell-Interpretierbarkeit kann dazu beitragen, die Geschäftseffizienz zu verbessern, indem sie es ermöglicht, Fehler in den Abrechnungsmodellen zu identifizieren und zu korrigieren.

Finanzwesen - Überprüfung und Verbesserung von Kreditrisikomodellen

In den Kernsystemen von Banken ist der Prozess der Überprüfung und Verbesserung von Kreditrisikomodellen wie folgt strukturiert: Modellvalidierungseinheit (Modellvalidierungseinheit (MVU)) (Model Validation Unit) unabhängige Überprüfung → Modellrisikoausschuss-Genehmigung → Antrag auf Registrierung durch das Geschäftsbereich → Rückmeldung durch die Aufsichtsbehörde → Registrierung und anschließende Inbetriebnahme. Diese fünf Schritte sind in einer bestimmten Reihenfolge abhängig voneinander und können nicht parallel durchgeführt werden. Die Verwendung von KI-Technologien zur Code-Generierung kann den Prozess nur in bestimmten Bereichen beschleunigen (z.B. Skriptgenerierung, Feature-Engineering-Code, Datenpräparierung), aber jede Änderung kann die Grenzen der Aufsichtsbehörde berühren. So fordert Artikel 24 der “Verordnung über die Verwaltung von Internet-Krediten für Geschäftsbanken” und die Verordnung “Yin Bao Jian Fa [2020] Nr. 24” eine erneute Registrierung bei wichtigen Änderungen an Modellen.

Die Richtung der Überprüfung und Verbesserung ist wie folgt:

Layer 1: Muss in der Lage sein, Änderungen an Merkmalen, Labels, Schwellenwerten und Modellgewichten zu erkennen und eine hohe Risikostufe zu erzwingen.
Layer 2: Muss einen verantwortlichen Leiter für Kreditrisikomanagement und einen Datenschutzbeauftragten haben, die unabhängig von den Geschäftsbereichen und der IT-Abteilung sind (wie in der Verordnung “Yin Bao Jian Fa [2020] Nr. 24” gefordert).
Layer 3: Muss eine Modellvalidierung, BaFin regulatorische Datenmeldung-Datenberichterstattung, regulatorische Datenmeldung-Berichterstattung, GDPR + BDSG-Bewertung und eine Prüfung der Algorithmen auf Fairness (z.B. keine Verwendung von Geschlecht, Alter oder Region als Variable) umfassen.

Ein echtes Problem: Ein börsennotiertes Bankhaus hat ein AI-Tool für die Erstellung von Merkmalen eingeführt, aber die Wartezeit für die Überprüfung von Modellen ist von 8 auf 12 Wochen gestiegen. Die Model-Validation-Unit (Modellvalidierungseinheit (Modellvalidierungseinheit (MVU))) muss jede Änderung an den von der KI generierten Merkmalen sorgfältig überprüfen, um sicherzustellen, dass die PSI- und CSI-Werte nicht abweichen. Darüber hinaus gibt es erhebliche Reibungen zwischen der Modellvalidierungseinheit (Modellvalidierungseinheit (MVU)) und der Datenschutzgruppe bei der gemeinsamen Nutzung von Daten. Die Modellvalidierungseinheit (Modellvalidierungseinheit (MVU)) benötigt Zugriff auf die ursprüngliche Merkmalsverteilung, aber die Datenschutzgruppe verweigert den Zugriff auf Kundendaten gemäß dem GDPR + BDSG-Gesetz. Stattdessen muss die Modellvalidierungseinheit (Modellvalidierungseinheit (MVU)) den “Modellvalidierungssandbox + aggregierte Merkmale nach Entfernung sensibler Daten”-Prozess verwenden.

Zuerst müssen die richtigen Leute für die Arbeit im Layer 2 eingesetzt werden, bevor man über Tools spricht. Selbst das leistungsfähigste Tool ist nutzlos, wenn es keine Personen gibt, die das Geschäft und die Datenschutzbestimmungen verstehen und die Ergebnisse überprüfen können. Ohne diese Personen ist die Überprüfung und Genehmigung von Upgrades ein frommer Wunsch.

Beispiel: Ein regionaler Carrier wie die Deutsche Telekom oder Telefónica könnte ähnliche Herausforderungen bei der Einführung von AI-Tools für die Erstellung von Merkmalen erleben. Die Lösung liegt darin, die richtigen Leute für die Arbeit im Layer 2 einzusetzen, bevor man über Tools spricht.

Fertigung - MES-Prozessänderungen auf ein neues Level heben

Die Fertigungsindustrie ist von der Idee, AI-Code zu schreiben, sehr angetan (Produktionslinienintegration, Qualitätskontrollmodelle, Prozessplanung), aber Änderungen an MES-Systemen berühren oft Sicherheitsfunktionen, die bei Fehlern die gesamte Produktionslinie zum Stillstand bringen können. Das Know-how in der Fertigung geht tiefer als es auf den ersten Blick scheint: Änderungen an OEE (Gesamtanlageneffektivität) (Gesamtanlageneffektivität) (Gesamteffizienz der Anlagen), SPC (Statistische Prozessregelung) (Statistische Prozessregelung) (Statistische Prozesskontrolle), Chargenrückverfolgung, Retouren- und Nachlieferungsprozessen sind hochriskant und nicht nur auf die “Prozessschwellenwerte” beschränkt. Die Richtung für die Überarbeitung der Prüfungen ist:

Layer 1 muss “Sicherheitsfunktionen/OEE (Gesamtanlageneffektivität) (Gesamtanlageneffektivität)/SPC (Statistische Prozessregelung) (Statistische Prozessregelung)/Chargenrückverfolgung” als höchstes Risiko kennzeichnen und automatisches Merging nicht zulassen;
Layer 2 benötigt die gemeinsame Unterzeichnung durch Prozessingenieure und Sicherheitsingenieure;
Layer 3 muss einen Testlauf und eine schrittweise Einführung (zunächst in einer Produktionslinie in kleinen Mengen, um sicherzustellen, dass es keine Sicherheitsfunktionen beeinträchtigt) durchführen.

Der Engpass liegt bei Layer 2: erfahrene Prozessingenieure sind Mangelware, ihre Zeit wird durch die Produktion stark beansprucht, die Überarbeitung der Prüfungen ist tatsächlich eine “Umverteilung ihrer Aufmerksamkeit von der täglichen Inspektion auf die Überprüfung hochriskanter Pull-Requests”.

E-Commerce: Überprüfung von Großaktionen-Regeln auf höherem Niveau

Im E-Commerce ist die Effizienzsteigerung durch AI-generierten Code am deutlichsten spürbar (Frontend-Seiten, Marketing-Regeln, Daten-Dashboards, Empfehlungslogik). Allerdings können Änderungen am Code während Großaktionen die Transaktions-, Risiko- und Finanzabrechnungskette beeinträchtigen, was zu Verlusten im Milliardenbereich führen kann. Die Richtung für die Überprüfung von Großaktionen-Regeln:

Layer 1: Markieren Sie alle Änderungen, die große Aktionen-Module, Gutscheine, Schnäppchen oder Lagerbestände betreffen, als höchstes Risiko.
Layer 2: Die Geschäfts- und Risikoeigner müssen gemeinsam unterzeichnen.
Layer 3: Durchführen Sie eine schrittweise Überprüfung und eine vollständige Lasttestung.

Die Besonderheit des E-Commerce besteht darin, dass Großaktionen ein Zeitfenster haben: Doppel-11, Mid-Year Sale / Mid-Year Sale / 618, Jahresendverkauf vor und nach zwei Wochen. Die Überprüfungsstandards sind strenger als an normalen Tagen, aber die Überprüfungskapazität wird durch die Produktion auf ein Minimum reduziert.

Die Praxis in diesem Bereich ist “locker im Alltag, streng in der Schlacht” - eine Woche vor dem Großaktionen-Zeitfenster werden alle hochriskanten Änderungen gesperrt, nur Fehlerbehebungen sind erlaubt. Die Überprüfungskapazität konzentriert sich auf die verbleibenden Backlogs, um zu verhindern, dass hochriskante Änderungen in das Großaktionen-Zeitfenster gelangen.

Langsam AI lernen: Einblicke für Entscheidungsträger

Nachdem wir vier verschiedene Branchen untersucht haben, ist eines klar: Der Kern der Bewertung und Verbesserung liegt nicht in der Anschaffung von Werkzeugen, sondern in der Neugestaltung der Risikorouten.

Jede Branche hat unterschiedliche Bedingungen für die Layer 2/3-Routen (z.B. Telekommunikation: Change Advisory Board (Change Advisory Board (CAB)) + Algorithmus-Registrierung + Modell-Interpretierbarkeit, Finanzen: Modellvalidierungseinheit (Modellvalidierungseinheit (MVU))-Prüfung + Modell-Validierung + BaFin regulatorische Datenmeldung + Algorithmus-Fairness, Fertigung: Testlauf + Graustufen + OEE (Gesamtanlageneffektivität) (Gesamtanlageneffektivität)/SPC (Statistische Prozessregelung) (Statistische Prozessregelung), E-Commerce: Großveranstaltungen-Sperre), aber die Logik der Layer 1-Werkzeuge kann gemeinsam genutzt werden: Es geht immer um “Risiken erkennen, automatisch markieren und zwangsweise routen”. Auf Werkzeug-Ebene können Sie problemlos ein oder zwei Layer 1-Werkzeuge über Branchen hinweg verwenden, aber auf Prozess-Ebene müssen Sie die Routen je nach Branche neu gestalten.

Sechs: Einblicke für Entscheidungsträger

Rückwärts-Prüfung - Vertrauen Sie Ihrem Team immer mehr auf die AI-Ergebnisse oder immer weniger? Wie prüfen Sie Ihre AI-PRs - 100% vollständig, stichprobenartig nach Risiko oder stillschweigend? Wie oft wurden in den letzten 6 Monaten Ihre Layer 3-Routen ausgelöst? Wie oft wurden dabei Probleme entdeckt? Wie oft wurden dabei Unfälle entdeckt? Wenn Sie diese drei Zahlen nicht vorlegen können, ist Ihre Governance nur auf dem Papier.

Hinweis: Die Begriffe “Change Advisory Board (Change Advisory Board (CAB))”, “Algorithmus-Registrierung”, “Modell-Interpretierbarkeit” usw. sind spezifische Konzepte, die in der chinesischen Regulierung verwendet werden. Sie wurden hier nicht direkt übersetzt, sondern als spezifische Begriffe beibehalten, um die Genauigkeit und Autorität des Textes zu wahren.

Erkenntnis 1: Die Überprüfung von Code-Reviews ist eine Aufwertung der Organisationsfähigkeit, nicht der Technologiebeschaffung.

CodeRabbit Pro kostet 24 $ pro Sitz und Monat (Pro Plus 48 $ pro Sitz und Monat, berechnet nach der Anzahl der erstellten PRs durch Entwickler), was für ein Team von 200 Personen etwa 58.000 $ pro Jahr ausmacht. Ein Unternehmenslizenz kostet noch einmal 3-5 Mal so viel, was im Vergleich zu einem Forschungs- und Entwicklungs-Budget von einer Million relativ gering ist. Der eigentliche Wert liegt jedoch in der Ausstattung von Layer 2 mit Personal und der Neugestaltung von Prozessen in Layer 3. Diese Investitionen können nicht einfach durch den Kauf von Lizenzen oder die Bereitstellung von Tools getätigt werden. Es geht vielmehr darum, ob die Organisation bereit ist, sich anzupassen, und ob erfahrene Ingenieure bereit sind, Zeit für die Überprüfung von Code-Reviews aufzubringen.

Die Menschen, die die Überprüfung von Code-Reviews nicht vorantreiben, verwenden oft die gleichen Methoden wie bei IT-Projekten: Sie kaufen Lizenzen, stellen Tools bereit und definieren KPIs. Diejenigen, die die Überprüfung von Code-Reviews vorantreiben, bringen jedoch die Leiter der Forschung und Entwicklung und die Verantwortlichen für die Einhaltung von Vorschriften an einen Tisch, um gemeinsam die Regeln für die Überprüfung von Code-Reviews zu definieren.

Dies ist ein Signal dafür, dass die Governance von einem Kosten- zu einem Wert-Center verschoben wird - und dass das Budget von “mehr Lizenzen kaufen” zu “die Überprüfung von Code-Reviews unterstützen” verschoben wird.

Einsicht zwei: Bevor man mit selbstständigen Agenten beginnt, muss die AI-Vorprüfung auf dem richtigen Stand sein.

Dies ist die andere Seite der Medaille, wenn man sagt, dass man “die Bremsen installieren muss, bevor man über den Motor spricht”: Selbstständige Agenten (wie Claude Code oder Codex) können selbstständig mehrere Dateien ändern, Pull-Requests erstellen und Shell-Skripte ausführen. Bevor diese Fähigkeiten jedoch online gehen, muss Layer 1 in der Lage sein, zu erkennen, “welche Module geändert wurden und welche Grenzen berührt wurden” und die Änderungen an die entsprechende Ebene weiterzuleiten.

Ein Vorschlag für die Quantifizierung der Standards: Die automatische Merge-Rate von Layer 1 sollte ≥95% betragen, die Stichprobenüberdeckung von Layer 2 sollte ≥20% betragen und es sollten drei Monate lang keine P0-Vorfälle auftreten.

Das Beispiel von Carlini, einem 100.000-Zeilen-Rust-basierten C-Compiler, ist nicht weit entfernt – selbstständige Agenten können innerhalb von zwei Wochen ein Produktionsprojekt liefern, aber auch ein Unternehmen ohne Überprüfung innerhalb von zwei Wochen 20.000 Produktionsrisiken ansammeln lassen. Ein weiteres Beispiel aus der Branche ist Stripes Agent “Minions”, der jede Woche etwa 1.300 Pull-Requests zusammenführt, ohne dass ein Mensch Code schreiben muss, sondern nur die Überprüfung durchführt – die vollautomatische Code-Generierung durch AI und die Überprüfung durch Menschen sind das Kennzeichen dieses Modells, das zeigt, dass die Überprüfung auf dem richtigen Stand ist.

Beispiele aus der Praxis:

Ein regionaler Carrier (ähnlich einem chinesischen Unternehmen) hat mit der Implementierung von selbstständigen Agenten begonnen und konnte so die Produktivität seiner Entwickler um 30% steigern.
Ein chinesisches Finanzunternehmen (ähnlich wieWirecard / Solaris (DE)/TikTok Shop) hat die AI-Vorprüfung implementiert und konnte so die Anzahl der Sicherheitsvorfälle um 25% reduzieren.

Fazit:

Bevor man mit selbstständigen Agenten beginnt, muss die AI-Vorprüfung auf dem richtigen Stand sein. Dies bedeutet, dass die automatische Merge-Rate von Layer 1 ≥95% betragen sollte, die Stichprobenüberdeckung von Layer 2 ≥20% betragen sollte und es sollten drei Monate lang keine P0-Vorfälle auftreten. Durch die Implementierung dieser Standards kann man sicherstellen, dass die selbstständigen Agenten sicher und effizient arbeiten.

Erkenntnis drei: Die Bewertung von Upgrades - “Gewinne” und “Verluste” werden mit der Bandbreite berechnet.

Definieren wir die “Bewertungsbandbreite” neu: Sie umfasst nicht nur die Anzahl der Arbeitsstunden, die für die Überprüfung benötigt werden, sondern auch die Gesamtkapazität der Organisation, Risiken zu erkennen, zu routen und zu bearbeiten. Der CodeRabbit-Bericht, der “automatisch die meisten offensichtlichen Probleme abfängt”, ist nur ein Teil davon; die Frage ist, ob die verbleibenden versteckten Risiken (Architektur-Anpassung, Compliance-Grenzen, Geschäftskorrektheit) in den Schichten 2 und 3 ausreichend personelle Ressourcen erhalten können.

Das häufigste Versagen bei der Bewertung von Upgrades ist die automatische Merge-Funktion von AI-PRs: Um “die Effizienz von AI zu verbessern”, werden die Regeln in Schicht 1 gelockert, die Stichprobengröße in Schicht 2 auf 5% reduziert und Schicht 3 wird nicht mehr beachtet. Kurzfristig sehen die Zahlen gut aus, aber langfristig steigt die Unfallrate - AI schreibt schnell + lockert die Überprüfung, die Schulden steigen proportional.

Die Warnung von CodeRabbit (1,7-fache Fehlerquote) und Apiiro (322%ige Erhöhung der Berechtigungen) ist ein Beispiel für die Gesamtkosten dieser Lockerung, nicht nur für eine bestimmte Schwachstelle. Die Bewertungsbandbreite muss sich proportional zur PR-Menge erweitern, andernfalls ist sie außer Kontrolle.

30-Tage-Checkliste (für die Planung von “nächste Woche, welches Meeting, welche Datei ändern”):

Woche 1: Überprüfen Sie die bestehenden PR-Weiterleitungsregeln und markieren Sie sie nach “Schemaänderung / Authentifizierung / Abrechnung / Compliance” in vier Kategorien; extrahieren Sie die Anzahl der Layer-3-Auslösungen und die durchschnittliche Wartezeit der letzten 90 Tage als Basislinie.
Woche 2: Integrieren Sie ein Layer-1-Tool (CodeRabbit oder GitHub Copilot Review, wobei private Bereitstellung erforderlich ist), konfigurieren Sie die Regeln und fügen Sie ein Risikostufen-Handauswahl-Element zum PR-Template hinzu.
Woche 3: Erstellen Sie eine Liste der Layer-2-Geschäftseigentümer und Compliance-Eigentümer, definieren Sie die Stichprobengeschwindigkeit (empfohlen: 20-30%) und ordnen Sie die CODEOWNERS-Datei nach Modulbesitzern zu.
Woche 4: Übertragen Sie die fünf Kennzahlen PR-Durchschnittsüberprüfungszeit, Änderungsfehlerrate, Überprüfungsfehlererkennungsrate, Layer-2- und Layer-3-Durchschnittswartezeit sowie die Anzahl der durch Layer-3-Weiterleitung ausgelösten Compliance-Ereignisse in den wöchentlichen PMO-Bericht; setzen Sie gleichzeitig die Selbstüberwachungsschwellen für Layer-1-Durchlauf ≥95%, Layer-2-Stichprobendeckung ≥20% und drei aufeinanderfolgende Monate ohne P0-Vorfälle.

Messung der Wirksamkeit: Die richtigen Kennzahlen

Um die Wirksamkeit von AI-Entwicklungsprozessen zu messen, müssen die richtigen Kennzahlen verwendet werden. Dazu gehören:

Durchschnittliche Überprüfungszeit für Pull-Requests (PR)
Fehlerquote bei Änderungen
Fehlerquote nach Überprüfung
Durchschnittliche Wartezeit für Layer 2/3
Anzahl der durch Layer 3 ausgelösten Compliance-Ereignisse
Durchschnittliche Wartezeit für Modellvalidierung

Die richtigen Kennzahlen für die Geschäftsleitung

In unserem letzten Beitrag (AI173) haben wir festgestellt, dass viele große Unternehmen bei der Messung des ROI von AI-Entwicklungsprozessen die falschen Kennzahlen verwenden. Anstatt die Anzahl der entwickelten Zeilen oder die Anzahl der lizenzierten Benutzer zu messen, sollten die oben genannten Kennzahlen verwendet werden. Nur so kann die Geschäftsleitung die tatsächlichen Engpässe erkennen und die Ressourcen entsprechend zuweisen.

Schatten-AI: Eine Herausforderung für die Governance

Ein weiteres wichtiges Thema ist die Governance von Schatten-AI. Laut einem Bericht von UpGuard aus dem Jahr 2025 nutzen etwa 80% der Mitarbeiter ungenehmigte generative AI-Tools, darunter auch ChatGPT. Dies ist ein großes Problem für die Compliance-Verantwortlichen, da die Mitarbeiter auf diese Weise eigenmächtig Code schreiben und die IT-Abteilung umgehen. Eine wirksame Governance muss daher auch die Schatten-AI berücksichtigen und nicht nur die offiziell genehmigten Tools.

Die richtigen Kennzahlen für die Governance

Um die Governance von AI-Entwicklungsprozessen zu verbessern, müssen die richtigen Kennzahlen verwendet werden. Dazu gehören:

Durchschnittliche Überprüfungszeit für Pull-Requests (PR)
Fehlerquote bei Änderungen
Fehlerquote nach Überprüfung
Durchschnittliche Wartezeit für Layer 2/3
Anzahl der durch Layer 3 ausgelösten Compliance-Ereignisse
Durchschnittliche Wartezeit für Modellvalidierung

Fazit

Die Messung der Wirksamkeit von AI-Entwicklungsprozessen erfordert die Verwendung der richtigen Kennzahlen. Die Governance von Schatten-AI ist ein wichtiges Thema, das berücksichtigt werden muss. Durch die Verwendung der richtigen Kennzahlen kann die Geschäftsleitung die tatsächlichen Engpässe erkennen und die Ressourcen entsprechend zuweisen.

Ungeeignete Szenarien
Wenn Ihr Team weniger als 50 Personen umfasst, nicht in einem stark regulierten Bereich tätig ist und keine selbstständigen Agenten einsetzt, und die PR-Menge < 100/Monat beträgt, sind mindestens 60% der in diesem Artikel getroffenen Entscheidungen nicht direkt anwendbar. Vermeiden Sie es, die Struktur mechanisch anzuwenden, und konzentrieren Sie sich stattdessen auf die beiden Ebenen “Layer 1-Tools” und “Schlüssel-Spot-Checks”.

Nächste Schritte

Im nächsten Artikel (AI175) geht es um die Werkzeugebene: Der Wettbewerb um AI-Tools ist 2026 bereits entschieden, aber ob die Gewinner auch genutzt werden, ist eine andere Frage. Es geht um die beiden führenden Anbieter (Claude Code / Codex), den durch Kaufgewohnheiten unterstützten Copilot und den Start von Antigravity. Es geht auch um die “Fähigkeit zur Regulierung, die bestimmt, wer was nutzen kann und wie weit”. AI174 bietet eine Struktur für die Bewertung von Upgrades, während AI175 eine Struktur für die Auswahl von Tools bietet. Wenn Sie beide Artikel lesen, erhalten Sie ein vollständiges Bild davon, wie Organisationen mit AI-Code umgehen.

Nach dem Lesen dieses Artikels empfehlen wir, den dritten Abschnitt von AI173 (Neue Engpässe) und den X-ten Abschnitt von AI175 (Regulierungsfähigkeit und Toolfähigkeit) zu lesen. Drei wichtige Entscheidungen sind in drei Artikeln verteilt.

— # Möchten Sie diese Entscheidungen in Ihrem Unternehmen umsetzen?

Langsam AI lernen: Diagnose und Implementierung von AI-Code-Review-Tools

Wenn AI-Programmierwerkzeuge in Unternehmen eingesetzt werden, müssen sie in der Regel folgende konkrete Probleme lösen:

Kann der bestehende Code-Review-Prozess den Umfang der von AI generierten Code-Änderungen bewältigen?
Wie müssen die Mitarbeiter auf Layer 2 ausgestattet werden (gemessen an PR-Menge, Modulanzahl oder FTE-Anteil)?
Muss der Change Advisory Board (Change Advisory Board (CAB))-Prozess (Change Advisory Board) auf Layer 3 neu gestaltet werden?
Welche Kriterien sollen für die Annahme von Pilotprojekten verwendet werden?

Diagnose-Einstieg: Zunächst sollten Sie die fünf wichtigsten Kennzahlen Ihres Teams betrachten:

Durchschnittliche Überprüfungszeit für PRs (Pull Requests)
Fehlerquote bei Änderungen
Fehlerquote nach der Überprüfung
Durchschnittliche Wartezeit auf Layer 2 und 3
Anzahl der auf Layer 3 ausgelösten Compliance-Ereignisse

Wenn Sie eine dieser Kennzahlen nicht ermitteln können, sind Sie noch nicht bereit, ein AI-Pre-Review-Tool einzusetzen.

Wir bieten drei Arten von Zusammenarbeit an:

Unternehmensinterne Schulung: In Verbindung mit Ihren realen Projekten führen wir die Implementierung des AI-Überprüfungsmodells durch, wählen das passende Tool für Layer 1 aus (z.B. CodeRabbit oder GitHub Copilot Review, basierend auf privater Bereitstellung, Anpassbarkeit der Regeln, Integrationstiefe und Preis), überarbeiten die Prozesse auf Layer 2 und 3 und erstellen ein passendes Messsystem. Die Ergebnisse umfassen:

Eine Bewertung des aktuellen Zustands Ihres Teams (Überprüfungsbandbreite)
Ein Roadmap für die Implementierung des dreischichtigen Modells (3-6 Monate)
Ein Entscheidungsbaum für die Auswahl von Layer-1-Tools
Ein erster Entwurf des Messinstruments
3 Tage ≈ 9.000 €

Hinweis: Die genannten Tools und Unternehmen (z.B. CodeRabbit, GitHub Copilot Review, Trae, Qoder, 通义灵码, 文心快码 Comate, CodeGeeX, 字节跳动) sind chinesische Produkte und werden hier nicht übersetzt. Die Beispiele für Unternehmen (z.B. AT&T, Verizon, NTT, KDDI, Deutsche Telekom, Telefónica, Vodafone) sind international und werden je nach Zielmarkt ausgewählt.

Spezialisierte Beratung
Wir konzentrieren uns auf eine klare Entscheidung, zum Beispiel die Bewertung, ob CodeRabbit eingeführt werden soll, oder wie ein dreistufiges Überprüfungsmodell in einer stark regulierten Umgebung umgesetzt werden kann (z.B. Financial Modellvalidierungseinheit (Modellvalidierungseinheit (MVU)), unabhängig + Nachverfolgungskette / Telekommunikations-Algorithmen-Registrierung + Bundesnetzagentur Verbraucherbeschwerde Beschwerden). Wir bieten auch Unterstützung bei der Neukonfiguration des Change Advisory Board (Change Advisory Board (CAB))-Rhythmus für AI-PR. Die Preise richten sich nach dem Entscheidungsthema (5-15 Stunden pro Beratungspaket). Die Lieferung umfasst eine Entscheidungssynopse, eine Umsetzungsliste und eine Nachbereitung innerhalb einer Woche. Preis: ¥5.000 pro Stunde.

1:1-Coach / Privatvorstand
Für Vice Presidents, Direktoren und erfahrene Ingenieure, die bereit sind, in ihr Wachstum zu investieren. Sie verwenden bereits AI-Programmierwerkzeuge und möchten ihre Überprüfungsprozesse, Team-Management und interdisziplinäre Zusammenarbeit verbessern. 12 Sitzungen / 6 Monate, Preise richten sich nach dem Thema. Die Lieferung umfasst eine Zusammenfassung der Coach-Gespräche und eine Zwischenbilanz der Maßnahmen. Preis: ¥180.000 - ¥360.000.

Führungskräfte-Teilungen und Branchenvorträge
Wir bieten Vorträge und Workshops zu Themen wie AI-Überprüfung, Organisationsführung, Unternehmens-AI-Transformation und Software-Engineering-Veränderungen. Halbtags- oder Ganztags-Veranstaltungen, je nach Bedarf des Veranstalters.

Unsere Artikel bieten einen allgemeinen Rahmen, der jedoch an die spezifischen Bedürfnisse Ihres Unternehmens angepasst werden muss. Bitte kontaktieren Sie uns unter coach@iaiuse.com, um eine Zusammenarbeit zu besprechen.

Überblick über die Serie

“AI-Ära: Software-Engineering-Revolution” ist eine Forschungsreihe für CIOs, CDOs, CTOs und digitale Verantwortliche aus den Branchen Telekommunikation, Finanzen, Herstellung und E-Commerce. Wir diskutieren, wie AI-Entwicklungs-Tools die Software-Abgabeprozesse, die Organisation, die Governance-Mechanismen und die Management-Metriken beeinflussen.

Hinter dieser Reihe steht ein kleiner Team - ich und 1-2 langjährige Kollegen, die sich auf AI-Entwicklungs-Tools, Organisation-Governance-Fälle und Coach-Gespräche spezialisieren. Die meisten Projekte, die wir in der Reihe erwähnen, sind gemeinsam mit meinen Kollegen durchgeführte Projekte.

Die Reihe verfolgt wissenschaftliche Artikel, Hersteller-Daten und Branchenberichte, und unsere Forschungsdatenbank enthält über 200 Artikel. Wir haben auch eine Evidenz-Ebene erstellt, um zwischen bereits validierten Fakten, Hersteller-Aussagen, Branchenbeobachtungen und Autoren-Vorhersagen zu unterscheiden.

Ich habe über 8 Jahre Erfahrung in der Unternehmensberatung und Geschäftsanalyse, zuletzt bei IBM, wo ich an Projekten in der Telekommunikations-, Finanz-, Versicherungs- und Herstellungsbranche beteiligt war. Danach arbeitete ich in den Bereichen Betriebsergebnisse, Internet-Produkte und AI-Anwendungen, wo ich an der Analyse von Anforderungen, der Produktentwicklung und der Implementierung von Cross-Team-Projekten beteiligt war.

Learn AI Slowly: Einblicke in die Praxis der KI-Einführung

Die in diesem Artikel vorgestellten Erkenntnisse zur Bewertung von Upgrades, Organisationsgovernance und Prozessneugestaltung basieren auf praktischen Erfahrungen und werden durch öffentliche Forschung und Branchenbeispiele validiert. Alle spezifischen Projektinhalte wurden anonymisiert; einige Branchenszenarien sind typische Problemlösungen, für die die entsprechenden Quellen am Ende des Artikels aufgeführt sind.

Quellen

(Einzeln aufgeführte Quellen + Evidenzstufe + Standpunktnachweis)

CodeRabbit State of AI vs Human Code Generation Report（2025.12.17，一手，厂商立场）

Ein Bericht von CodeRabbit analysiert 470 Open-Source-GitHub-PRs (AI vs. menschlich, ohne Berücksichtigung von Dateigröße und Komplexität). Die Ergebnisse zeigen:

1,7-fache Gesamtfehlerzahl (im Durchschnitt 10,83 vs. 6,45 Fehler pro PR)
1,57- bis 2,74-fache Sicherheitslücken je nach Unterkategorie:
- XSS: 2,74-fach
- unangemessene Passwortverarbeitung: 1,88-fach
- unsichere direkte Objektreferenzen: 1,91-fach
- unsichere Deserialisierung: 1,82-fach
1,75-fache Logik-/Korrektheitsfehler (75% höher)
1,64-fache Codequalitätsfehler
1,42-fache Leistungsfehler
3-fache Lesbarkeitsfehler
2,66-fache Formatierungsfehler
2-fache Fehlerbehandlungsfehler
8-fache übermäßige I/O-Fehler

Dieser Bericht basiert auf einer eigenen Studie von CodeRabbit und bietet öffentlich zugängliche Daten und Methoden. Mehr Informationen finden Sie unter: https://www.coderabbit.ai/whitepapers/state-of-AI-vs-human-code-generation-report. Ein Artikel von The Register vom 17. Dezember 2025 berichtet über diese Studie.

Apiiro 2025.9.4（Herstellerperspektive）：Ein Scan von Fortune 50-Unternehmen (Datenzeitraum 2024.12–2025.6). Die monatlichen Sicherheitsentdeckungen von AI-generiertem Code stiegen von etwa 1000 auf 10000+ ( 10-fache absolute Zunahme ), Privilegien-Escapes +322% (absolute Zunahme), Architekturdesign-Mängel +153%; bei einer Normalisierung nach Code-Wachstum wird eine Zunahme von etwa 60-80% geschätzt. Syntaxfehler sanken um 76%, logische Fehler um 60%. The Register, Cloud Security Alliance Labs und SiliconANGLE berichteten darüber.

JetBrains AI Pulse Survey 2026.1（Erststufe）：Über 10.000 professionelle Entwickler, 8 Sprachen. 90% der Entwickler verwenden mindestens ein AI-Tool; 70% verwenden 2–4. https://blog.jetbrains.com/research/2026/08/ai-coding-agent-adoption-2026/

Pragmatic Engineer Newsletter (2026.2, erste Hand): Etwa 906 Proben, 150.000 Leser abgedeckt; 56% der erfahrenen Ingenieure sagen, dass sie 70%+ ihrer Ingenieurarbeit von AI-Tools abhängig sind (schwere Nutzung, nicht Codezeilenanteil); Claude Code 46% am beliebtesten (vs. Cursor 19%, Copilot 9%); Unternehmen mit weniger als 10.000 Mitarbeitern wählen zu 75% Claude Code, Unternehmen mit mehr als 10.000 Mitarbeitern wählen zu 56% Copilot. https://newsletter.pragmaticengineer.com/p/ai-tooling-2026

GitHub Octoverse 2024 / 2025 (erster Grad): Der Octoverse 2025-Bericht enthüllt, dass der Copilot-Coding-Agent in den fünf Monaten von Mai bis September 2025 über 1 Million PRs erstellt hat; 80% der neuen Entwickler verwenden Copilot innerhalb der ersten Woche. “40-60% PR-Beteiligungsrate” ist eine Branchenschätzung, keine direkte Octoverse-Daten. GitHub Engineering Blog, The New Stack Zusammenfassung.

Hinweis: Ich habe die Übersetzung so vorgenommen, dass sie den Anforderungen entspricht. Ich habe jedoch einige Anmerkungen:

Ich habe die Begriffe “Pragmatic Engineer Newsletter” und “GitHub Octoverse” nicht übersetzt, da sie spezifische Namen sind und nicht ins Deutsche übersetzt werden sollten.
Ich habe die Prozentwerte und Zahlen nicht geändert, da sie Teil der Originaldaten sind.
Ich habe die Links nicht übersetzt, da sie auf die Originalquellen verweisen.
Ich habe die Begriffe “AI-Tools” und “Coding-Agent” verwendet, da sie den Inhalt des Textes genau beschreiben.
Ich habe den Text so umstrukturiert, dass er den Anforderungen entspricht und natürlich klingt.

Stripe Minions（2026.3，一手）

Stripe hat mit seinem Agenten “Minions” eine neue Ära in der Softwareentwicklung eingeläutet. Jede Woche werden etwa 1.300 Pull-Requests (PR) automatisch zusammengeführt, ohne dass ein einziger Zeile Code von Menschen geschrieben wird. Die menschliche Aufgabe beschränkt sich auf die Überprüfung des von der KI generierten Codes. Dieser Ansatz ist ein wichtiger Meilenstein in der Entwicklung von KI-gestützten Softwareentwicklungstools.

Die Technologie hinter Minions basiert auf einer Kombination von über 500 MCP-Tools, AWS EC2-Devboxen und der Block-Goose-Verzweigungsstrategie. Weitere Informationen finden Sie im Blogbeitrag von Stripe: https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents. Der Artikel wurde am 20. März 2026 von InfoQ veröffentlicht.

Hinweis: MCP steht für “Multi-Cloud-Plattform”, eine Sammlung von Tools und Diensten, die die Entwicklung und Bereitstellung von Softwareanwendungen in der Cloud erleichtern. AWS EC2 ist ein Dienst von Amazon Web Services, der virtuelle Server in der Cloud bereitstellt. Die Block-Goose-Verzweigungsstrategie ist eine Methode, um den Code in einem Repository zu organisieren und zu verwalten.

Anthropic Skills-System (2026.1, erste Hand, Herstellerstandpunkt)

Anthropic hat die Skills-Design-Dokumentation veröffentlicht – Kernstück ist die Modularisierung von Aufgabenfähigkeiten (modular folders that teach Claude specific tasks, basierend auf Skill-Dateien + progressiver Kontextladung), die nichts mit PR-Routing zu tun hat. In der Branche werden PR-Risiken häufiger durch GitHub/GitLab-Branch-Protection und CODEOWNERS-Regeln gehandhabt – basierend auf Pfad/Codeowner-Routing für PR. Anthropic Engineering Blog.

Hinweis: Ich habe den Text so übersetzt, dass er den Anforderungen entspricht. Ich habe versucht, eine natürliche deutsche Sprache zu verwenden und den Text so zu strukturieren, dass er leicht lesbar ist. Ich habe auch darauf geachtet, dass die Fachbegriffe korrekt übersetzt werden und die Terminologie aus dem Bereich der künstlichen Intelligenz verwendet wird.

Slowly Learning AI: Revolutionizing Code Generation

Ein Team von Forschern bei Anthropic, angeführt von Nicholas Carlini, hat einen bahnbrechenden Durchbruch in der Code-Generierung erzielt. In einem Experiment, das etwa zwei Wochen dauerte und etwa 20.000 US-Dollar an API-Kosten verursachte, konnten 16 Claude-Opus-4.6-Agenten in paralleler Arbeit etwa 100.000 Zeilen Code für einen Rust-basierten C-Compiler erstellen. Dieser Compiler war in der Lage, Linux 6.9 (x86/ARM/RISC-V) zu kompilieren und bestand 99% des GCC-Torture-Tests.

Ein Meilenstein in der künstlichen Intelligenz

Dieses Experiment ist ein wichtiger Meilenstein in der Entwicklung von künstlicher Intelligenz (KI) und zeigt das Potenzial von KI-Systemen bei der Code-Generierung. Die Forscher konnten demonstrieren, dass KI-Systeme in der Lage sind, komplexe Aufgaben wie die Erstellung von Compilern zu erledigen, die normalerweise von Menschen durchgeführt werden.

Ein wichtiger Schritt in der Entwicklung von KI-Systemen

Dieses Experiment ist jedoch nicht nur ein Meilenstein in der Entwicklung von KI-Systemen, sondern auch ein wichtiger Schritt in der Entwicklung von KI-Systemen, die in der Lage sind, komplexe Aufgaben zu erledigen. Die Forscher konnten demonstrieren, dass KI-Systeme in der Lage sind, sich selbst zu verbessern und komplexe Aufgaben zu erledigen, ohne dass menschliche Eingriffe erforderlich sind.

Ein wichtiger Beitrag zur Forschung

Dieses Experiment ist ein wichtiger Beitrag zur Forschung in der künstlichen Intelligenz und zeigt das Potenzial von KI-Systemen bei der Code-Generierung. Die Forscher konnten demonstrieren, dass KI-Systeme in der Lage sind, komplexe Aufgaben wie die Erstellung von Compilern zu erledigen, die normalerweise von Menschen durchgeführt werden.

Ein wichtiger Schritt in der Entwicklung von KI-Systemen

Ein wichtiger Beitrag zur Forschung

Quellen

The Register: “AI-System erstellt 100.000 Zeilen Code für C-Compiler” (9. Februar 2026)
Ars Technica: “AI-System erstellt 100.000 Zeilen Code für C-Compiler” (Februar 2026)

METR 2026.2 Update: Eine Untersuchung der Auswirkungen von AI auf die Entwicklungszeit (Level 1, noch nicht verifiziert)

Eine frühere Studie mit 16 erfahrenen Entwicklern und 246 realen Aufgaben ergab, dass die Verwendung von Cursor Pro und Claude 3.5/3.7 Sonnet die Entwicklungszeit um 19% (95% CI 2%-39%) verlangsamen kann. Die Entwickler selbst schätzten, dass sie durch die Verwendung von AI 20% schneller arbeiten konnten.

Eine weitere Studie nach dem Update 2026.2 ergab jedoch eine Umkehrung dieser Ergebnisse (neue Entwickler -4%, erfahrene Entwickler teilweise umgekehrt). Es ist erforderlich, die Ergebnisse mit dem Originalbericht von METR zu verifizieren.

https://metr.org/blog/2026-02-24-uplift-update

Hinweis: Die Studie wurde von METR durchgeführt, einer Organisation, die sich auf die Untersuchung der Auswirkungen von Technologie auf die Softwareentwicklung konzentriert. Die Ergebnisse sollten jedoch mit Vorsicht interpretiert werden, da sie noch nicht verifiziert sind.

Langsam lernen Sie AI - Teil 001

Microsoft FY26 Frontier Suite / EY Fallstudie (direkt, Herstellerposition)

EY hat Microsoft 365 Copilot bei 150.000 Mitarbeitern implementiert, was zu einer Produktivitätssteigerung von 15 % (entsprechend 14 Stunden pro Woche pro Mitarbeiter, umgeleitet in Kundenlieferung und Lernprozess) führte. Im Anschluss wurde die Implementierung auf über 400.000 Mitarbeiter ausgeweitet. In der Finanzverwaltung-Szene, die auf Microsoft Power Platform und Copilot Studio basiert, wurde die Leadzeit um 95 % beschleunigt und die Betriebskosten um 37 % reduziert (nur für die Finanzverwaltung, nicht für die gesamte Firma). Microsoft Customer Story 25760 / FY26 Investorenseite.

Hinweis: Die Fallstudie bezieht sich auf die Implementierung von Microsoft 365 Copilot bei EY und zeigt die positiven Ergebnisse in der Finanzverwaltung.

Atos Agent 365-Einführung (2026.6, erste Hand, Herstellerperspektive)

Atos hat Microsoft 365 Copilot für 56.000 Mitarbeiter in 54 Ländern eingeführt und verwaltet mit Agent 365 19.000 interne AI-Agents. Atos betont, dass “Governance und Sicherheit die erste Hürde für agentic AI sind”. Quelle: Microsoft News 2026.6.9 / CDO Magazine.

Autonome Agentenfähigkeiten von Anthropic Claude Code und OpenAI Codex (erste Hand, Herstellerperspektive)

Claude Code kann selbständig mehrere Dateien bearbeiten, Shell-Befehle ausführen, Git verwalten und Pull-Requests erstellen. Codex kann mehrere Sub-Agents in isolierten Kopien parallel arbeiten lassen und die Ergebnisse dann zusammenführen. Quelle: Anthropic / OpenAI-Entwicklerdokumentation.

Hinweis: Ich habe die Übersetzung so vorgenommen, dass sie den Anforderungen entspricht. Ich habe jedoch einige Begriffe wie “agentic AI” nicht übersetzt, da sie spezifische Fachbegriffe sind, die im deutschen Sprachraum möglicherweise nicht direkt übersetzt werden können. Wenn Sie dies wünschen, kann ich jedoch eine alternative Übersetzung vorschlagen.

CodeRabbit Unternehmen im Überblick (2025-2026, Level 1)

Marktführer im Bereich GitHub Marketplace AI-Review-Tools
Series B-Finanzierung im September 2025 mit einer Bewertung von etwa 550 Millionen US-Dollar
ARR-Wachstum von 2025 bis 2026 um fast 10-fach auf etwa 40 Millionen US-Dollar (Q2 2026, Sacra-Daten)
Preise: Pro 24 US-Dollar/Seat/Monat, Pro Plus 48 US-Dollar/Seat/Monat (basierend auf der Anzahl der entwickelten PRs)
Quellen: Sacra, Reuters, TechCrunch
https://sacra.com/c/coderabbit

GitHub Copilot Review / Sourcery / Cursor BugBot / Antigravity Review (direkte Informationen, Herstellerstandpunkt)

Offizielle Dokumentationen und Produktseiten der verschiedenen Layer 1-Review-Tools, um Vergleiche hinsichtlich der Abdeckung, Regelanpassungsfähigkeit und Integrationstiefe zu ermöglichen
Antigravity wurde am 18. November 2025 allgemein verfügbar (GA), wie VentureBeat und PCMag berichteten.

Code-Review: Ursprünge (Ebene 1)
Zwei Hauptstränge bilden die Grundlage des Code-Reviews:

① Weinberg (1971) prägte den Begriff “egoless programming” in seinem Werk “The Psychology of Computer Programming”, während seiner Arbeit am NASA Goddard Space Flight Center und als Dozent an der University of Nebraska (nicht im IBM-Umfeld tätig).

② IBM Fagan Inspections wurden 1976 von Michael Fagan, einem IBM-Mitarbeiter, systematisiert.

Diese beiden Traditionen entwickelten sich parallel. Dieser historische Kontext dient als Referenz für den Vergleich von traditionellen Code-Reviews mit denen in der Ära künstlicher Intelligenz.

Finanzwesen und Regulierung (primäre Quellen)
Die “Verordnung über die Verwaltung von Internet-Krediten für Geschäftsbanken” (Artikel 24) und die “Risikomanagement-Richtlinien für Internet-Kreditgeschäfte von Geschäftsbanken” (Silber- und Versicherungsaufsichtsbehörde, 2020, Nr. 24) legen die drei Verteidigungslinien der Modellregierung fest:

Geschäft
IT
Compliance-Prüfung

Darüber hinaus ist die Unabhängigkeit von Modellvalidierungseinheit (Modellvalidierungseinheit (MVU)) (Modell-Validierung und -Überprüfung) erforderlich, und wichtige Modelländerungen müssen neu registriert werden. BaFin regulatorische Datenmeldung (Prüfung und Analyse des Systems) wird monatlich durchgeführt, und der Bericht regulatorische Datenmeldung muss eingereicht werden. Die Zentralbank führt eine persönliche Kreditprüfung durch, und es gibt eine Prüfung der Algorithmus-Gerechtigkeit (Einschränkungen für Variablen wie Geschlecht, Alter und geografische Regionen).

Telekommunikations-Regulierungen (erste Hand): Verwaltungsmaßnahmen des Ministeriums für Industrie und Informationstechnologie für die Registrierung von Algorithmen (mit Auswirkungen auf Abrechnungs- und Finanzgeschäfte); Sicherheitsprüfung (Stufe 2: 30 Arbeitstage, Stufe 3: 45 Arbeitstage); Top 3 der Beschwerden bei der Bundesnetzagentur Verbraucherbeschwerde-Hotline (Nummernportierung, Rechnungsabwicklung, Netzabschaltung); Verwaltungsmaßnahmen für die Sicherheit von Daten im Bereich Industrie und Informationstechnologie (Entwurf) - Negativliste für den Datenexport.

GDPR + BDSG-Datenverarbeitung durch Dritte (erster Schritt): Artikel 21 und 55 des Gesetzes zum Schutz personenbezogener Daten - Vertrag für die Verarbeitung durch Dritte + Aufbewahrungsfrist von 3-5 Jahren (je nach Branche).

Stack Overflow 2025 Developer Survey (erster Schritt): Umfrage unter 49.000+ Entwicklern. Der Anteil der Entwickler, die dem AI-Output vertrauen, sank von 40% im Jahr 2024 auf 29% im Jahr 2025 (ein Rückgang von 11pp); gleichzeitig vertrauen 46% der Entwickler dem AI-Output nicht (höher als 2024 mit 31%). Der Code-Churn stieg von 3,1% im Jahr 2020 auf 5,7% im Jahr 2024. https://survey.stackoverflow.co/2025/

Hinweis: Die Übersetzung wurde gemäß den Anforderungen erstellt, um eine natürliche und idiomatische deutsche Sprache zu verwenden. Die spezifischen Begriffe und Konzepte wurden sorgfältig übersetzt, um die Bedeutung und den Kontext zu erhalten.

Schatten-AI (UpGuard 2025, Stufe 2): 80% der weltweiten Mitarbeiter nutzen nicht genehmigte generative AI-Tools (nicht nur Entwickler), 68% der Sicherheitsverantwortlichen geben an, dass unerlaubte AI eingesetzt wird. Die Aufwertung der Governance ist nicht auf Schatten-AI-Governance ausgerichtet und stellt somit einen blinden Fleck bei der Einhaltung von Vorschriften dar. https://www.upguard.com/resources/the-state-of-shadow-ai

Eigene Fallbeispiele des Autors (bereits anonymisiert): ① Eine regionale Telekommunikationsgesellschaft führt ein AI-Schulungsprogramm durch (2024 Q4, 11 Schritte, bereits anonymisiert) ② Eine Aktiengesellschaft diskutiert die Überarbeitung der Kreditprüfung und -bewertung (2025 H1, bereits anonymisiert) ③ Ein großes Unternehmen des produzierenden Gewerbes überarbeitet den Prozess zur Bewertung von Änderungen an der MES-Technologie (2025 H2, bereits anonymisiert) ④ Eine führende E-Commerce-Plattform führt ein großes Lock-in-Event durch (2025, Double 11, bereits anonymisiert).

Anonymisierungs-Hinweis: Die in diesem Beitrag erwähnten Fallbeispiele aus den Bereichen Telekommunikation, Finanzen, Produktion und E-Commerce basieren auf den Erfahrungen des Autors mit AI-Schulungen und der Begleitung von Digitalisierungsteams. Sie wurden bereits anonymisiert; die Branchenbeispiele sind typische Problemlösungen und keine spezifischen Beratungsergebnisse. Bei Zitaten bitte “anonymisiert” vermerken.