AI-Assisted Software Delivery Evidence Review 2026

Executive Summary

Die Frage „Macht AI Entwickler schneller?“ ist zu grob. Studien messen unterschiedliche Aufgaben, Personen, Tools, Zeiträume und Endpunkte. Eine klar umrissene JavaScript-Aufgabe, reale Issues erfahrener Open-Source-Maintainer, organisationsweite Delivery-Metriken und Anbietertelemetrie zu Pull Requests sind keine austauschbaren Experimente.

Dieser Report bewertet deshalb nicht einen universellen Produktivitätseffekt. Er ordnet elf Evidenzbausteine nach Studiendesign und Endpunkt ein und verbindet sie mit einem Betriebsmodell für Reviewkapazität, Secure Software Development und Kosten pro akzeptierter Produktionsänderung.

Die Evidenz ist heterogen:

• Ein randomisiertes Experiment zu einer begrenzten Aufgabe berichtete eine deutliche Beschleunigung.
• Das METR-Feldexperiment mit erfahrenen Maintainers in vertrauten Repositories fand für frühe 2025er Tools eine 19-prozentige Verlangsamung; ein 2026er Update zeigte schwache, selektionsbehaftete Hinweise auf Verbesserungen mit neueren Tools.
• DORA fand organisationsweite Assoziationen, die vor pauschaler Gleichsetzung von Adoption und Delivery Performance warnen.
• Ein longitudinaler 2026er Enterprise-Fall mit 802 Entwicklern und 196.212 Pull Requests erreichte 2,09-mal den früheren Pro-Kopf-Durchsatz, während die Reviewlast pro Reviewer ungefähr mitwuchs. Wegen nicht randomisierter Adoption ist das keine universelle Kausalzahl.
• Security- und Code-Quality-Studien zeigen sowohl Verbesserungsmöglichkeiten als auch relevante Schwachstellen, abhängig von Aufgabe, Tool, Tests und Review.

Die operative Schlussfolgerung lautet nicht „AI-Code vermeiden“. Sie lautet: Erzeugungskapazität darf nicht schneller skaliert werden als Spezifikation, Review, Tests, Security und Produktionsfeedback. Die richtige ökonomische Kennzahl ist nicht Lines of Code oder PR Count, sondern Kosten und Lead Time pro akzeptierter, stabiler Produktionsänderung.

Zitierfähige Kernergebnisse

1. [OBSERVED] Das METR-RCT von 2025 berichtete in seinem spezifischen Setting 19 Prozent längere Bearbeitungszeit bei AI-Zulassung, obwohl Teilnehmer subjektiv eine Beschleunigung wahrnahmen.
2. [OBSERVED] METRs 2026er Update lieferte für neuere Tools schwache Hinweise auf mögliche Beschleunigung, nennt aber Selektions- und Teilnahmeprobleme, die eine starke Interpretation verhindern.
3. [OBSERVED] Der longitudinale Enterprise-Fall von He et al. analysiert 802 Entwickler und 196.212 Pull Requests von Januar 2024 bis April 2026; der Pro-Kopf-Durchsatz erreichte 2,09-mal den Vor-Mandatswert, während die Reviewlast ungefähr mitstieg.
4. [INTERPRETATION] Mehr Output pro Entwickler ist nicht dasselbe wie mehr Wert, Qualität oder Stabilität pro Zeiteinheit.
5. [OBSERVED] Die häufig zitierte Zahl von 8,1 Millionen Pull Requests gehört zum LinearB-Benchmark-Corpus; die +242,7-Prozent-Incident-Darstellung stammt aus einem separaten Faros-Anbieterreport. Die Quellen dürfen nicht vermischt werden.
6. [INTERPRETATION] Review ist eine endliche Servicekapazität. Wenn die PR-Ankunftsrate schneller wächst als substanzielle Prüfung, steigen Queue-Alter, oberflächliche Freigaben oder automatisierter Reviewanteil.
7. [RECOMMENDATION] AI-assistierte Änderungen benötigen dieselben oder strengere risikobasierten Gates wie menschlich geschriebener Code: kleine Batches, Tests, SAST, Dependency Review, Secret Scanning, unabhängige Freigabe, Canary und Observability.
8. [RECOMMENDATION] Unternehmen sollten AI-Wirkung mit kontrollierten lokalen Rollouts und Outcome-Metriken messen, nicht über Selbsteinschätzung oder generierte Zeilen.

---

1. Reviewfrage und Protokoll

Welche belastbaren Aussagen lassen sich bis zum Juli 2026 über den Einfluss AI-assistierter Entwicklung auf Durchsatz, Zeit, Review, Qualität, Security und Delivery treffen?

1.1 Einschlusskriterien

• öffentlich nachvollziehbare Methodik;
• konkrete Stichprobe oder Corpusbeschreibung;
• messbarer Endpunkt;
• dokumentierte Limitationen;
• direkte Relevanz zu Softwareerzeugung, Review oder Delivery;
• Primärquelle oder transparent als Anbietertelemetrie klassifiziert.

1.2 Evidenzgrade

Grad	Typ	zulässige Sprache
A	randomisiertes kontrolliertes Experiment	„verursachte in diesem Setting“ mit Scope
A-	randomisiert, aber relevante Selektions-/Teilnahmeprobleme	„schwache/unsichere Evidenz“
B	quasi-experimentell oder kontrollierter empirischer Benchmark	„steht in Zusammenhang / zeigte im Design“
C	Beobachtungsdaten, Anbietertelemetrie, deskriptives Corpus	„berichtete / beobachtete“; keine universale Kausalität

1.3 Primäre Endpunkte

• Bearbeitungszeit;
• akzeptierter Durchsatz;
• Review-Warte- und Bearbeitungszeit;
• Rework und Reverts;
• Change Failure und Recovery;
• Security Findings;
• Testqualität;
• Kosten pro akzeptierter Produktionsänderung.

---

2. Strukturierter Evidenzreview

2. Review-Protokoll

2.1 Einschlusskriterien

Aufgenommen wurden Quellen, die mindestens eines erfüllen:

• randomisierte oder kontrollierte Vergleichsgruppe
• quasi-experimentelle Identifikationsstrategie
• reale Engineering-Telemetrie mit ausgewiesenem Sample
• empirische Security-/Quality-Analyse mit reproduzierbarer Einheit
• offizieller Benchmark-Corpus mit klarer Stichprobengröße

2.2 Ausschlusskriterien

Nicht als Kernevidenz verwendet wurden:

• reine Hersteller-Testimonials
• Umfragen ohne Bezug zu beobachtbaren Outcomes
• anekdotische „10x Developer“-Behauptungen
• Modellbenchmarks ohne menschlichen Entwicklungsprozess
• Einzelbeispiele ohne Vergleichsbedingung
• Metriken ohne nachvollziehbare Quelle

2.3 Evidenzgrade

Grad	Design	Interpretation
A	randomisiertes kontrolliertes Experiment	hohe interne Aussagekraft für das untersuchte Setting; externe Generalisierung separat prüfen
A-	randomisiertes Design mit wesentlichen Selektions-/Messproblemen	kausale Idee stark, konkrete Effektgröße unsicher
B	quasi-experimentell oder kontrollierter technischer Benchmark	belastbar für definierte Population/Endpunkt, aber mit Confounding- oder Transfergrenzen
C	beobachtende Telemetrie oder deskriptiver Benchmark	reale Breite, aber keine sichere Kausalität
D	Selbstauskunft, Anbieterclaim ohne ausreichend prüfbare Methodik	Hypothesengenerierung, nicht als belastbarer Effekt

[CRITICAL] Anbieterfinanzierung führt nicht automatisch zur Abwertung. Sie wird als Interessenkonflikt und Replikationsgrenze dokumentiert. Ebenso ist ein unabhängiger Preprint nicht automatisch kausal belastbar.

---

---

3. Evidenzmatrix

ID	Quelle	Design	Stichprobe	berichteter Kernbefund	Grad
E01	Peng et al. / Microsoft Research & GitHub	randomisiertes kontrolliertes Experiment	rekrutierte Entwickler; HTTP-Server-Aufgabe in JavaScript	Treatment-Gruppe schloss die klar umrissene Aufgabe 55,8 % schneller ab	A
E02	METR	randomisiertes kontrolliertes Feldexperiment	16 erfahrene OSS-Entwickler, 246 reale Issues in vertrauten Repositories	AI-Zulassung führte in diesem Setting zu 19 % längerer Bearbeitungszeit; Entwickler erwarteten zuvor 24 % Beschleunigung und nahmen danach 20 % Beschleunigung wahr	A
E03	METR Update	fortgesetztes randomisiertes Experiment mit Selektionsproblemen	Rückkehrer und neu rekrutierte OSS-Entwickler; late-2025-Tools	Rückkehrer: geschätzte 18 % Beschleunigung, CI von 38 % Beschleunigung bis 9 % Verlangsamung; neue Entwickler: 4 % Beschleunigung, CI von 15 % Beschleunigung bis 9 % Verlangsamung	A-
E04	DORA / Google Cloud	beobachtende organisationsweite Analyse	Softwareentwicklungsorganisationen im DORA-Datensatz	25 % höhere AI-Adoption war mit 1,5 % geringerem Throughput und 7,2 % geringerer Stability assoziiert	C
E05	Song, Agarwal & Wen	quasi-experimentelle OSS-Analyse mit proprietären Copilot-Nutzungsdaten	kollaborative Open-Source-Projekte und Entwickler	+5,9 % Projektbeiträge, +3,4 % Beteiligung, +2,1 % individuelle Produktivität und +8 % Koordinationszeit	B
E06	Faros AI	beobachtende Engineering-Telemetrie / Vorher-Nachher-Vergleich	zwei Jahre Telemetrie, 22.000 Entwickler, 4.000 Teams	Anbieter berichtet +51 % PR-Größe, +28 % Bugs/PR, 5x Median-Reviewzeit, 3x Incidents/PR und +242,7 % Incidents/PR in einer dargestellten High-Adoption-Auswertung	C
E07	GitHub	randomisiertes kontrolliertes Code-Quality-Experiment	202 gültige Einreichungen erfahrener Python-Entwickler; 1.293 Blindreviews	Copilot-Zugang erhöhte die Wahrscheinlichkeit, alle zehn Tests zu bestehen, um 53,2 %; mehrere Qualitätsmetriken verbesserten sich geringfügig	A
E08	Pearce et al.	kontrollierter Security-Prompt-Benchmark	89 Szenarien, 1.689 generierte Programme	Rund 40 % der generierten Programme wurden als vulnerabel eingestuft	B
E09	Fu et al.	empirische Analyse realer Copilot-Code-Snippets	733 Snippets aus GitHub-Projekten	29,5 % der Python- und 24,2 % der JavaScript-Snippets betroffen; 43 CWE-Kategorien; Warnhinweise ermöglichten bis zu 55,5 % Behebung	B
E10	LinearB	großes deskriptives Benchmark-Corpus	8,1+ Mio. Pull Requests aus 4.800+ Organisationen/Teams, 42 Ländern laut Anbieter	Corpus belegt große Datenbasis; Anbieter rahmt Code Review als Engpass zwischen AI-Adoption und messbarem Engineering Impact	C

Maschinenlesbare Fassung:

data/FDR-2026-07_ai_delivery_evidence_matrix.csv

---

---

4. Warum die Ergebnisse scheinbar widersprüchlich sind

4.1 Unterschiedliche Aufgaben

Eine klar spezifizierte API- oder HTTP-Server-Aufgabe ist nicht dieselbe Arbeit wie ein Issue in einer millionenzeiligen, über Jahre gewachsenen Codebase. AI profitiert von:

• expliziten Anforderungen
• kurzen Kontextfenstern
• bekannten Frameworkmustern
• automatisch prüfbaren Ergebnissen
• geringer impliziter Domänenlogik

Sie wird stärker belastet durch:

• lokale Konventionen
• ungeschriebene Architekturregeln
• historisch gewachsene Abhängigkeiten
• schwer messbare Nichtfunktionsanforderungen
• Review-, Dokumentations- und Migrationspflichten

4.2 Unterschiedliche Nutzer

Ein Einsteiger, ein produktiver Generalist und ein langjähriger Maintainer einer hochkomplexen Codebase besitzen andere Engpässe. AI kann fehlendes Syntaxwissen stark kompensieren, während ein Experte Zeit für Prompting, Prüfung und Korrektur aufwendet, die er bei vertrautem Code nicht benötigt hätte.

4.3 Unterschiedliche Endpunkte

schneller erster Entwurf
≠ schneller akzeptierter Pull Request
≠ schneller Merge
≠ schnellere Produktion
≠ weniger Incidents
≠ höherer Geschäftswert

Die Studien messen jeweils andere Teile dieser Kette. Ein positiver Effekt am Anfang kann durch Review und Rework aufgezehrt werden. Umgekehrt kann ein langsamerer einzelner Task zu besserem Wissenstransfer oder höherer Reichweite führen.

4.4 Werkzeug- und Zeitabhängigkeit

Modelle, Agenten, IDE-Integration und Nutzungsmuster ändern sich innerhalb weniger Monate. Ein 2021-Security-Benchmark ist wichtig als Risikomuster, aber keine direkte Schätzung für ein Modell im Juli 2026. METRs gegensätzliche frühe und spätere Ergebnisse zeigen gerade diese Dynamik – und zugleich, wie schwer sie sauber zu messen ist.

---

---

5. Evidenz nach Outcome

5.1 Individuelle Task-Geschwindigkeit

Die stärkste positive Zahl stammt aus dem kontrollierten HTTP-Server-Experiment: 55,8 Prozent schneller. Die stärkste negative kontrollierte Zahl stammt aus METRs realen OSS-Issues: 19 Prozent langsamer.

Beide können gleichzeitig korrekt sein. Das erste Setting prüft eine begrenzte Aufgabe. Das zweite prüft erfahrene Entwickler in vertrauten, großen Repositories mit impliziten Standards.

[INTERPRETATION] Eine Organisation darf keinen externen Uplift als Forecast übernehmen, ohne die eigene Taskverteilung zu segmentieren.

5.2 Projekt-Output und Koordination

Die OSS-Analyse von Song, Agarwal und Wen berichtet:

• +5,9 % Projektbeiträge
• +3,4 % Beteiligung
• +2,1 % individuelle Produktivität
• +8 % Koordinationszeit

Das ist ein zentraler Mechanismus: AI kann die Zahl der Beiträger und Änderungen erhöhen, während die gemeinsame Abstimmung langsamer wird.

5.3 Delivery Throughput und Stability

DORA berichtet für 25 Prozent höhere AI-Adoption eine Assoziation mit:

• 1,5 Prozent geringerem Delivery Throughput
• 7,2 Prozent geringerer Delivery Stability

Die Daten beweisen keine Kausalität. Sie sind aber konsistent mit einer Warteschlangenlogik: Größere Batches und mehr Änderungen belasten Review und Integration.

5.4 Codequalität

GitHubs kontrolliertes Experiment mit 202 gültigen Einreichungen berichtet eine 53,2 Prozent höhere Wahrscheinlichkeit, alle zehn Unit Tests zu bestehen. Zusätzlich wurden kleine, statistisch signifikante Verbesserungen bei Lesbarkeit, Reliability, Maintainability und Conciseness berichtet.

Die richtige Interpretation ist nicht „AI-Code ist hochwertiger“. Sie lautet:

In dieser standardisierten Aufgabe und Stichprobe erzeugte die Treatment-Gruppe im Mittel bessere gemessene Ergebnisse.

5.5 Security

Pearce et al. erzeugten 1.689 Programme in 89 security-relevanten Szenarien und klassifizierten rund 40 Prozent als vulnerabel. Eine spätere Analyse realer Copilot-Snippets fand Schwächen in 29,5 Prozent der Python- und 24,2 Prozent der JavaScript-Snippets; bis zu 55,5 Prozent der erkannten Probleme konnten mit konkreten Warnmeldungen durch Copilot Chat behoben werden.

[INTERPRETATION] AI erzeugt Security-Risiko und Security-Remediation zugleich. Ohne Scanner, Tests und fachlichen Review bleibt die Richtung unbestimmt.

5.6 Engineering-Telemetrie

Faros berichtet für 22.000 Entwickler und 4.000 Teams unter anderem:

• +51 % PR-Größe
• +28 % Bugs pro PR
• 5-fache Median-Reviewzeit
• 3-fache Incidents pro PR
• 10-fachen Code Churn
• in einer visualisierten High-Adoption-Auswertung +242,7 % Incidents pro PR

Diese Werte sind wichtig, aber als Anbietertelemetrie mit nicht vollständig offenen Rohdaten und Modellen Grad C. Der Report beschreibt die Befunde als von Faros berichtet, nicht als unabhängig verifizierte Kausalität.

---

---

6. Die LinearB-/Faros-Attributionskorrektur

Zwei häufig gemeinsam zitierte Zahlen stammen aus unterschiedlichen Quellen:

• 8,1+ Millionen Pull Requests und 4.800+ Organisationen/Teams: LinearB Software Engineering Benchmarks Report 2026.
• +242,7 Prozent Incidents pro PR: visualisierte Auswertung im Faros-AI-Report „The Acceleration Whiplash“.

[CRITICAL] Die Incident-Zahl darf nicht LinearB zugeschrieben werden. Ebenso beweist die LinearB-Corpusgröße nicht die Faros-Kausalitätsbehauptung.

LinearB wird in diesem Review als großer deskriptiver Benchmark-Corpus erfasst. Seine Anbieterthese, dass Code Review zum Engpass wird, ist mit mehreren anderen Quellen konsistent. Konsistenz ist jedoch kein Ersatz für identische Messung oder unabhängige Replikation.

---

---

7. Ein ökonomisches Modell des Review-Engpasses

7.1 Produktions- und Prüfrate

λ = eintreffende Änderungsmenge pro Zeiteinheit
μ = geprüfte und integrierte Änderungsmenge pro Zeiteinheit

Solange λ < μ, bleibt die Warteschlange kontrollierbar. Nähert sich λ der Reviewkapazität, steigt die Wartezeit überproportional. Überschreitet λ dauerhaft μ, wachsen offene PRs, Kontextverlust und Risikodruck.

AI kann λ erhöhen durch:

• mehr PRs
• größere PRs
• mehr parallele Aufgaben
• mehr Entwickler/Agenten mit Beiträgen

Reviewkapazität μ steigt nicht automatisch. Sie hängt ab von:

• Reviewer-Zeit und Domänenwissen
• Testautomatisierung
• Architekturgrenzen
• Observability
• PR-Größe
• Änderungsrisiko
• Qualität der Spezifikation

7.2 Verdeckte Arbeit

AI-Output erzeugt zusätzliche Arbeit, die nicht als „Coding Time“ erscheint:

• Kontext validieren
• Halluzinationen erkennen
• Dependency- und Lizenzprüfung
• Security Scanning
• Tests schreiben oder korrigieren
• Edge Cases identifizieren
• Rebase und Merge-Konflikte
• Incident- und Rework-Kosten

Eine Produktivitätsmessung, die nur Autorzeit zählt, verschiebt diese Arbeit auf Reviewer und Betrieb.

---

---

8. Messrahmen für Unternehmen

8.1 Vier Ebenen

Ebene 1 – Task

• Bearbeitungszeit
• akzeptierter Output
• Korrekturschleifen
• Toolkosten

Ebene 2 – Pull Request

• Größe und Komplexität
• Pickup-/Reviewzeit
• Zahl Reviewer
• Review-Kommentare
• Rework/Churn
• Test- und Security-Findings

Ebene 3 – Delivery

• Lead Time for Changes
• Deployment Frequency
• Change Failure Rate
• Failed Deployment Recovery Time
• Batch Size

Ebene 4 – Geschäft

• gelieferte Funktion
• Nutzungs-/Umsatzwirkung
• Support- und Incidentkosten
• Wartbarkeit
• Compliance-/Auditaufwand

8.2 Kernformeln

Accepted AI Contribution Rate
= akzeptierte AI-beeinflusste Änderungen / AI-beeinflusste Änderungen

Review Amplification
= zusätzliche Review- und Reworkzeit / eingesparte Autorzeit

Stable Delivery Yield
= Änderungen ohne Rollback oder Incident im Fenster / ausgelieferte Änderungen

AI Engineering ROI
= Wert stabil ausgelieferter Änderungen
  - Toolkosten
  - Review- und Reworkkosten
  - Incident- und Betriebskosten

Keine Formel sollte automatisch unterstellen, dass jede AI-beeinflusste Zeile ohne AI nicht entstanden wäre.

---

---

9. Kontrollarchitektur für AI-Code

Vor der Generierung

• Task und Akzeptanzkriterien schriftlich
• zulässige Repositories, Daten und Tools
• Secret- und PII-Schutz
• Dependency-/Lizenzregeln
• Risiko- und Kritikalitätsklasse

Während der Generierung

• kleine, begrenzte Deltas
• nachvollziehbare Agenten-/Modellversion
• Tool- und Dateizugriffe protokollieren
• keine direkte Produktion ohne kontrollierten Pfad
• Tests parallel erzeugen, aber unabhängig validieren

Vor Merge

• menschlicher Owner
• automatisierte Tests
• SAST, Dependency und Secret Scanning
• Architektur-/Domain-Review bei kritischen Pfaden
• Herkunft und neue Dependencies prüfen
• PR-Größe begrenzen oder zerlegen

Nach Deployment

• Feature-/Release-Telemetrie
• Error Budget und Incident-Verknüpfung
• Rollback-Fähigkeit
• Churn und Hotfixes messen
• Findings in Prompts, Policies und Tests zurückführen

[RECOMMENDATION] AI-generierter Code braucht nicht zwingend einen anderen SDLC. Er braucht einen SDLC, der seine eigene Kapazität und Evidence tatsächlich misst.

---

---

10. Was Entscheider aus der Evidenz nicht behaupten sollten

Nicht belastbar sind pauschale Aussagen wie:

• „AI macht Entwickler 55,8 Prozent schneller.“
• „AI macht erfahrene Entwickler 19 Prozent langsamer.“
• „AI verursacht 242,7 Prozent mehr Incidents.“
• „AI-Code ist sicherer/unsicherer als Menschencode.“
• „Code Review ist immer der einzige Engpass.“

Jede dieser Zahlen ist an ein Design, eine Population, eine Zeit, ein Tool und einen Endpunkt gebunden.

Belastbarer ist:

Kontrollierte und beobachtende Studien zeigen stark heterogene Effekte. Mehr Codeproduktion kann mit höheren Review-, Koordinations-, Stabilitäts- und Security-Anforderungen einhergehen. Organisationen müssen den Nettoeffekt im eigenen Delivery-System messen.

---

3. Evidenzmatrix und Attributionsschutz

Die vollständige, maschinenlesbare Evidenzmatrix liegt in data/FDR-2026-07_ai_delivery_evidence_matrix.csv. Jede öffentliche Zahl muss mit Design, Population, Endpoint und Limitation zitiert werden.

4. Neue Evidenz 2026: Der Review-Engpass im Enterprise-Fall

Die im Juli 2026 veröffentlichte Studie „AI Writes Faster Than Humans Can Review“ erweitert die Evidenzbasis um einen ungewöhnlich großen longitudinalen Unternehmensfall. Sie analysiert 802 Entwickler und 196.212 Pull Requests über Januar 2024 bis April 2026.

4.1 Was beobachtet wurde

Nach Angaben der Autoren:

• erreichte der Pro-Kopf-Durchsatz im April 2026 das 2,09-Fache des Pre-Mandate-Niveaus;
• war der Zuwachs über Senioritätsgruppen verteilt, aber stärker in neuerem Code konzentriert;
• wuchs die Reviewlast pro Reviewer ungefähr mit;
• überholte automatisierter Review die menschliche Reviewaktivität;
• blieben Merge- und Revert-Raten in der betrachteten Aggregation stabil.

4.2 Was daraus nicht folgt

Die Adoption und Nutzungsintensität waren nicht randomisiert. Das Unternehmen war AI-affin, hatte ein explizites 2x-Ziel und bildet einen spezifischen organisatorischen Kontext. Deshalb ist folgende Aussage unzulässig:

„AI verdoppelt die Produktivität von Softwareteams.“

Zulässig ist:

„In einem longitudinalen, nicht randomisierten Enterprise-Fall stieg der gemessene Pro-Kopf-PR-Durchsatz auf 2,09x, während die Reviewlast ungefähr mitwuchs.“

4.3 Der Engpass verschiebt sich

Eine Delivery-Pipeline lässt sich als verkettetes Kapazitätssystem darstellen:

Spezifikation → Codeerzeugung → lokale Validierung → Review → CI → Release → Produktionsfeedback

Die Gesamtkapazität ist durch die langsamste wirksame Stufe begrenzt. Wenn Codeerzeugung beschleunigt wird, aber Spezifikation, Review und Test nicht mitwachsen, entsteht kein proportionaler Outcome-Zuwachs. Stattdessen wachsen:

• offene Pull Requests;
• Reviewer-Kontextwechsel;
• mittlere Diff-Größe;
• Wartezeit bis substanziellem Feedback;
• automatisierte Freigaben ohne ausreichende Kalibrierung;
• Rework nach Merge;
• Produktionsrisiko, das grobe Revert-Metriken möglicherweise nicht erfassen.

---

5. Review Capacity Model

5.1 Grundgleichung

PR-Ankunftsrate λ =
neue review-fähige Änderungen pro Arbeitstag

Review-Service-Rate μ =
Reviewer × verfügbare Reviewminuten / Minuten je Änderung

Wenn λ ≥ μ, wächst der Rückstand. Bei schwankender Ankunft und Bearbeitungszeit kann die Queue bereits deutlich vor 100 Prozent Auslastung instabil werden.

5.2 Beispiel

Vor AI-Adoption:

λ = 40 PR/Tag
5 Reviewer × 90 Reviewminuten / 10 Minuten = μ 45 PR/Tag
Auslastung ρ = 0,89

Nach Verdopplung der Erzeugung:

λ = 80 PR/Tag
μ bleibt 45 PR/Tag
ρ = 1,78

Selbst wenn automatisierte Vorprüfung die menschliche Bearbeitungszeit auf sieben Minuten reduziert:

μ = 5 × 90 / 7 = 64 PR/Tag
ρ = 1,25

Die Queue wächst weiter. Die Organisation muss entweder Ankunft reduzieren, Batchgröße verkleinern, Qualität vor Review erhöhen, Reviewer-Kapazität erweitern oder risikobasiert routen.

5.3 Messbare Review-SLOs

Metrik	Zweck
Time to First Substantive Review	erkennt Warteschlange statt bloß Bot-Kommentar
Review Queue Age p50/p90	zeigt Alter kritischer Änderungen
Review Minutes per 100 Meaningful Lines	normalisiert Aufwand grob nach Diff
Reviewer Load Distribution	erkennt Konzentration auf wenige Experten
Rework after Review	misst Qualität des Feedback-/Autorenzyklus
Escaped Defects by Risk Class	verbindet Review mit Produktionswirkung
Automated vs Human Review Coverage	macht Verschiebung sichtbar
Diff Size and Concern Count	kontrolliert Batchrisiko

„Meaningful Lines“ müssen generierte Lockfiles, Formatierung und Vendored Code ausschließen oder separat ausweisen.

---

6. Kosten pro akzeptierter Produktionsänderung

6.1 Vollständige Formel

Accepted production change cost =
AI-Toolkosten
+ Inferenz/Compute
+ Autorenzeit
+ Reviewerzeit
+ CI/Preview
+ Securityprüfung
+ Rework
+ erwartete Fehler-/Incidentkosten

geteilt durch:

Änderungen, die produktiv akzeptiert wurden
und innerhalb des definierten Fensters
keine korrektive Rücknahme benötigten

6.2 Warum PR Count ungeeignet ist

Ein Pull Request kann:

• nur Formatierung enthalten;
• automatisch erzeugt sein;
• nie gemergt werden;
• einen größeren PR künstlich aufteilen;
• nach kurzer Zeit korrigiert werden;
• technische Schulden oder Sicherheitsrisiken erzeugen;
• wertvolle oder wertlose Funktionalität liefern.

PR Count ist als Durchsatzsignal nützlich, aber kein alleiniger Produktivitäts- oder Wertmaßstab.

6.3 Erwartete Fehlerkosten

Expected defect cost =
Σ (Fehlerwahrscheinlichkeit × Impact × Detection/Recovery Cost)

Ein Team sollte mindestens trennen:

• Pre-Merge Finding;
• Post-Merge/Pre-Release Finding;
• Production Defect ohne Kundenauswirkung;
• Incident mit Verfügbarkeitseinfluss;
• Security Finding;
• Daten- oder Complianceabweichung.

AI-assistierte Herkunft darf in der Root-Cause-Analyse dokumentiert werden, aber nicht als alleinige Ursache behandelt werden. Anforderungen, Architektur, Review, Tests und Releasekontrollen bleiben Teil des Systems.

---

7. Kontrollarchitektur für AI-assistierte Entwicklung

Die Datei data/FDR-2026-07_ai_delivery_governance_controls.csv enthält 20 Mindestkontrollen. Für Tier-1-Systeme wird folgende Gate-Struktur empfohlen.

Gate A - Input und Zugriff

• zugelassene Tools, Modelle und Datenklassen;
• kein Produktionssecret oder unzulässiger personenbezogener Inhalt im Prompt;
• Least Privilege für Repository und Kontext;
• Retention und Training Terms dokumentiert;
• Repository-/Dateiscopes begrenzen.

Gate B - Change Design

• Akzeptanzkriterien vor Codeerzeugung;
• eine fachliche Concern pro Änderung;
• Diff- und File-Limits;
• AI-Assistance-Provenance im PR;
• keine selbstständige Änderung von Auth, Crypto, Permissions oder Payment ohne Spezialreview.

Gate C - Deterministische CI

• Unit-, Integration- und Contract-Tests;
• Type Checking und Linting;
• SAST und Secret Scanning;
• Dependency Review, Lockfiles und SBOM;
• Testqualitätskontrolle, gegebenenfalls Mutation Testing;
• reproduzierbare Builds und signierte Artefakte.

Gate D - Unabhängige Review

• Reviewer ist nicht der Autor;
• risikobasierte Reviewer-Zuweisung;
• Queue-Alter und Last sichtbar;
• automatisierte Review als Unterstützung, nicht unsichtbarer Ersatz;
• Security Trigger für sensible Bereiche;
• Begründung bei Override.

Gate E - Release und Produktion

• ephemeral/preview environment;
• Canary oder progressive Delivery;
• Health Gates und Rollback;
• Deploymentmarker in Logs/Metrics/Traces;
• Change Owner und On-call-Zuordnung;
• escaped defects und Rework erfassen.

Diese Architektur passt zu NIST SSDF, weil sie sichere Entwicklungspraktiken in den gesamten Lifecycle integriert, statt AI-Code als separate Kategorie ohne bestehende Verantwortung zu behandeln.

---

8. Lokales Experimentdesign: 90 Tage statt Glaubenskrieg

8.1 Hypothese

Beispiel:

„Für klar abgegrenzte Backend-Änderungen mittlerer Komplexität reduziert AI-Assistance die Medianzeit bis zur stabilen Produktion um mindestens 15 Prozent, ohne Change Failure, Security Findings oder Reviewerzeit zu verschlechtern.“

8.2 Randomisierung oder gestufter Rollout

Mögliche Designs:

• task-level randomisiert, wenn Aufgaben vergleichbar sind;
• teamweise gestaffelte Einführung;
• matched pairs nach Repository, Komplexität und Entwicklererfahrung;
• A/B in zeitlich begrenzten Sprints;
• Difference-in-Differences bei sauberer Pre-Period.

Selbstselektion muss sichtbar bleiben. Entwickler, die AI freiwillig intensiv nutzen, können sich systematisch von anderen unterscheiden.

8.3 Pre-Registration Light

Vor Start festhalten:

• primärer Endpunkt;
• sekundäre Endpunkte;
• Einschluss-/Ausschlussregeln;
• Messfenster;
• Risikoklassen;
• Analyseplan;
• Umgang mit Ausfällen und Toolwechseln;
• minimale Stichprobe oder Dauer.

Das verhindert, dass nachträglich nur günstige Kennzahlen ausgewählt werden.

8.4 Empfohlenes Metric Set

Aus data/FDR-2026-07_measurement_framework.csv:

• accepted change lead time;
• review queue age;
• review minutes per 100 changed lines;
• rework rate;
• change fail rate;
• failed deployment recovery time;
• escaped security findings;
• test mutation score delta;
• AI-assisted PR share;
• accepted outcome cost.

8.5 Segmentierung

Mindestens nach:

• Entwicklererfahrung;
• Repository-Vertrautheit;
• Tasktyp;
• Risiko;
• Sprache/Stack;
• Tool/Modellversion;
• Greenfield vs Legacy;
• PR-Größe;
• Testabdeckung.

Ein aggregierter Mittelwert kann positive Effekte in einfachen Aufgaben und negative Effekte in komplexen Legacy-Bereichen verdecken.

---

9. Stop-/Scale-Regeln

Scale

AI-Nutzung ausweiten, wenn über mehrere Messfenster:

• Accepted Lead Time sinkt;
• Review Queue nicht wächst;
• Rework und Change Failure stabil oder besser sind;
• Security Findings nicht steigen;
• Cost per Accepted Change sinkt;
• Teams die Kontrollen ohne Umgehung einhalten.

Stop oder begrenzen

• Review Queue überschreitet SLO;
• große AI-Diffs ohne nachvollziehbare Spezifikation;
• Secret-/Data-Policy-Verstöße;
• Security Finding Rate steigt;
• Tests werden generiert, aber Mutation Score sinkt;
• Rework verlagert sich nur in spätere Phasen;
• Toolkosten wachsen schneller als akzeptierte Outcomes;
• Modell-/Toolwechsel macht Vergleichsdaten unbrauchbar.

Degrade Mode

Zwischen Vollnutzung und Verbot:

• nur Erklärung, Tests oder Dokumentation;
• keine autonomen Merges;
• keine sensiblen Repositories;
• kürzere Kontextfenster;
• ausschließlich lokale/vertraglich geeignete Modelle;
• verpflichtendes Pairing bei risikoreichen Änderungen.

---

10. Risikoklassen statt einheitlicher AI-Policy

Eine einzige Regel für Autocomplete, Testgenerierung, Authentifizierungslogik und produktionsnahe Infrastruktur ist zu grob. FW Delta empfiehlt vier Risikoklassen.

Klasse A - Assistive, nicht ausführbare Inhalte

Beispiele:

• Erklärung vorhandenen Codes;
• Entwurf interner Dokumentation;
• Umformulierung von Kommentaren;
• nicht produktive Beispiele;
• Such- und Navigationshilfe.

Mindestkontrollen:

• zugelassenes Tool;
• keine verbotenen Daten;
• menschliche Plausibilitätsprüfung;
• keine ungeprüfte Übernahme externer Quellen oder Lizenzen.

Klasse B - Niedrigrisiko-Code mit starker Deterministik

Beispiele:

• einfache Datenkonvertierung;
• Boilerplate;
• Tests für klar definierte Funktionen;
• UI-Komponenten ohne sensible Logik;
• interne Skripte mit begrenztem Scope.

Mindestkontrollen:

• normale Code Review;
• deterministische Tests;
• Lint/Type Check;
• Secret und Dependency Scan;
• kleine Diffs.

Klasse C - Geschäfts- oder datenrelevante Logik

Beispiele:

• Pricing, Payroll, Rechnung, CRM-Routing;
• personenbezogene Daten;
• externe APIs mit Schreibwirkung;
• Datenmigrationen;
• wichtige Background Jobs.

Zusätzliche Kontrollen:

• schriftliche Akzeptanzkriterien;
• Contract-/Integrationstests;
• unabhängige Fachfreigabe;
• Reconciliation;
• Preview/Canary;
• AI-Assistance-Provenance;
• Rollback- und Datenkorrekturplan.

Klasse D - Security-, Safety- oder Systemgrenze

Beispiele:

• Authentifizierung und Autorisierung;
• Kryptografie;
• Secret Management;
• Payments;
• Infrastruktur- und IAM-Policies;
• sicherheitskritische Parser;
• regulierte Hochrisikofunktionen.

Zusätzliche Kontrollen:

• Spezialreview;
• Threat Model;
• negative und adversariale Tests;
• SAST/DAST/Fuzzing nach Kontext;
• Dependency/SBOM Policy;
• keine autonome Freigabe;
• dokumentierte menschliche Verantwortung;
• gestufter Rollout und enges Monitoring.

Die Klassen bewerten die Wirkung der Änderung, nicht die vermeintliche Qualität des Modells. Derselbe Modelloutput kann in Klasse A harmlos und in Klasse D existenziell sein.

---

11. Spezifikationsqualität als vorgelagerter Engpass

AI kann schlechte Anforderungen schneller in Code übersetzen. Das ist keine Produktivitätssteigerung. Für messbare Delivery muss die Spezifikation mindestens enthalten:

• gewünschtes Verhalten;
• Nicht-Ziele;
• Eingaben, Ausgaben und Fehlerzustände;
• Daten- und Berechtigungsgrenzen;
• Akzeptanztests;
• Performance-/Zuverlässigkeitsanforderungen;
• Migrations- und Rollbackverhalten;
• Observability;
• Verantwortlicher Entscheider.

11.1 Specification Readiness Score

Kriterium	0	1	2
Outcome	unklar	Feature beschrieben	messbarer Geschäft-/Nutzeroutcome
Scope	offen	grobe Grenze	explizite In-/Out-of-Scope-Liste
Interfaces	implizit	teilweise	versionierte Contracts
Error States	fehlen	häufige Fälle	vollständige Risikoklassen
Tests	keine	Beispiele	automatisierbare Akzeptanzkriterien
Security/Data	nicht erwähnt	generisch	konkrete Daten- und Trust-Grenzen
Rollback	fehlt	manuell	getesteter Plan
Observability	fehlt	Logs	Metriken, Traces, SLO/Alerts

Ein Task unter einem festgelegten Schwellenwert sollte nicht an einen Agenten delegiert werden, sondern zuerst geklärt werden. Das verhindert, dass hohe Outputgeschwindigkeit die Zahl falsch verstandener Änderungen erhöht.

11.2 Prompt ist kein Vertrag

Ein Prompt kann Teil der Interaktion sein, aber die dauerhafte Spezifikation sollte:

• versioniert;
• reviewbar;
• toolunabhängig;
• testbar;
• mit Code und Entscheidung verknüpft sein.

Damit bleibt der Entwicklungsprozess auch bei Modellwechsel nachvollziehbar.

---

12. Automatisierter Review: Kalibrierung statt blindem Vertrauen

Automatisierter Review kann Queue-Druck reduzieren, aber er erzeugt eigene False Positives und False Negatives. Ein Bot-Kommentar ist keine substanzielle Review.

12.1 Kalibrierungsdatensatz

Für jede relevante Finding-Klasse:

• 100 bis 500 historische oder synthetische Beispiele;
• bestätigte positive und negative Fälle;
• Risikoschwere;
• Sprache/Framework;
• Fixbarkeit;
• menschliche Goldbewertung.

12.2 Metriken

Precision = bestätigte Findings / alle Findings
Recall = gefundene relevante Fälle / alle relevanten Fälle

Zusätzlich:

• Mean Time to Triage;
• Override Rate;
• wiederkehrende Fehlalarmklassen;
• escaped findings;
• Reviewerzeit, die der Bot spart oder zusätzlich erzeugt;
• Wirkung nach Modell-/Regelupdate.

Ein Tool mit niedriger Precision kann die Queue verschlimmern, obwohl es mehr Kommentare produziert. Ein Tool mit hoher Precision, aber sehr niedrigem Recall darf nicht als vollständige Kontrolle behandelt werden.

12.3 Autonomiegrenzen

Aktion	mögliche Automatisierung	Voraussetzung
Style/Lint Fix	auto-commit	deterministisch und reversibel
Dependency Update	PR-Erstellung	Lockfile, Tests, Policy
Low-risk Finding	Vorschlag	menschliche Annahme
Security Finding	Block/Route	kalibrierte Regel und Owner
Merge	nur sehr enger Scope	Branch Protection, Tests, geringe Risikoklasse
Production Deploy	progressive Automation	Health Gates, Rollback, Accountability

---

13. Statistischer Analyseplan für das lokale Experiment

13.1 Primärer Endpunkt

accepted_change_lead_time als Median oder log-transformierte Zeit, weil Deliveryzeiten häufig schief verteilt sind.

13.2 Sekundäre Endpunkte

• Review Queue Age;
• Reviewer Minutes;
• Rework binnen 14/30 Tagen;
• Change Failure Rate;
• Recovery Time;
• Security Findings;
• Cost per Accepted Change.

13.3 Schätzung

Je nach Design:

• Difference in Means/Medients mit Bootstrap-Intervall;
• Mixed-Effects-Modell mit Entwickler und Repository als Random Effects;
• Difference-in-Differences bei gestaffelter Einführung;
• Survival Analysis für Lead Time;
• Negative-Binomial-/Poisson-Modell für Count-Metriken;
• Sensitivitätsanalyse ohne extreme Diffs oder Bot-PRs.

13.4 Confounder

• Taskkomplexität;
• Repository-Vertrautheit;
• Developer Seniority;
• Modell-/IDE-Version;
• Teamwechsel;
• Parallelinitiativen;
• Saison-/Releasephase;
• Testinfrastruktur;
• freiwillige Adoption;
• Änderungen an Reviewregeln.

13.5 Minimaler Interpretationsstandard

Jede Ergebnisfolie enthält:

1. Effektgröße;
2. Unsicherheitsintervall;
3. Stichprobe;
4. Zeitraum;
5. Design;
6. relevante Confounder;
7. praktische Bedeutung;
8. Entscheidung und nächste Messung.

Ein p-Wert ohne Effektgröße und Kontext ist für eine Deliveryentscheidung unzureichend.

---

14. Datenschutz, IP und Arbeitsorganisation

14.1 Datenminimierung

AI-Provenance sollte nicht zu permanenter Leistungsüberwachung einzelner Entwickler degenerieren. Erfassen, was zur Sicherheit und Wirkungsmessung notwendig ist:

• Tool-/Modellklasse;
• materielle AI-Assistance ja/nein;
• Repository/Risikoklasse;
• Change-/Outcome-Metriken;
• keine unnötigen Promptinhalte;
• begrenzte Retention und klare Zugriffsrechte.

14.2 Vertrauliche Informationen

Vor Toolfreigabe klären:

• Training/Retention;
• Region und Subprozessoren;
• Admin-/Supportzugriff;
• IP- und Outputbedingungen;
• Logging;
• Löschung;
• Enterprise Security Controls;
• erlaubte Repository- und Datenklassen.

14.3 Verantwortlichkeit

Der menschliche Autor oder Owner bleibt verantwortlich für die eingereichte Änderung. Gleichzeitig ist ein Incident kein Anlass, Verantwortung ausschließlich auf die einzelne Person abzuwälzen. Toolauswahl, Spezifikation, Reviewkapazität, CI und Releasepolitik sind Management- und Systementscheidungen.

14.4 Skill-Erhalt

Ein Team muss kritische Systeme auch ohne dasselbe Modell bedienen können. Maßnahmen:

• regelmäßige manuelle Debug-/Reviewübungen;
• Architekturwissen dokumentieren;
• Rotation von Reviewerrollen;
• keine Blackbox-Automation ohne Runbook;
• Postmortems und Lernzeit;
• Modelle als Assistenz, nicht einzige Wissensquelle.

---

15. 30/60/90-Tage-Implementierung

Tage 0–30 - Baseline und Grenzen

• Tool- und Datenpolicy beschließen;
• Risikoklassen definieren;
• Baseline von mindestens vier Wochen sichern;
• AI-Assistance-Provenance einführen;
• Review Queue und Rework messbar machen;
• Tier-D-Änderungen zunächst ausschließen;
• 2–3 klar umrissene Tasktypen wählen.

Gate: Messdaten, Owner, Hypothese und Stop-Regeln sind vorhanden.

Tage 31–60 - Kontrollierter Rollout

• randomisierte oder gestaffelte Einführung;
• kleine Diffs erzwingen;
• CI-/Security-Gates schärfen;
• automatisierten Review auf Kalibrierungsset testen;
• wöchentliche Outcome-Analyse;
• qualitatives Feedback strukturiert erfassen;
• Tool-/Modellupdates versionieren.

Gate: Kein negativer Trend bei Security, Change Failure und Review Queue.

Tage 61–90 - Skalieren oder begrenzen

• Effektgrößen und Intervalle berechnen;
• Segmente mit positiver/negativer Wirkung bestimmen;
• Kosten pro Accepted Change ermitteln;
• Controls nach Findings anpassen;
• nur geeignete Tasktypen ausweiten;
• nächste 90-Tage-Hypothese registrieren;
• Executive Decision Record veröffentlichen.

Gate: Skalierung erfolgt nach Outcome, nicht nach Nutzungsquote.

---

16. Executive Scorecard

Dimension	Kernfrage	Ampel-Beispiel
Adoption	Wird das Tool im erlaubten Scope genutzt?	Information, nicht Zielwert
Throughput	Kommen akzeptierte Änderungen schneller in Produktion?	Trend plus Intervall
Review	Bleibt Queue und Aufwand beherrschbar?	p90 Queue unter SLO
Quality	Sinkt oder steigt Rework?	14-/30-Tage-Kohorte
Stability	Bleiben Change Failure und Recovery stabil?	DORA-nahe Metriken
Security	Werden Findings früher erkannt?	nach Severity und Phase
Economics	Sinkt Cost per Accepted Change?	Vollkosten, nicht Toolpreis
Learning	Kennt das Team Grenzen und Failure Modes?	Drills, Postmortems, Updates

Keine einzelne Ampel darf den Rest verdecken. Höherer Durchsatz bei wachsendem Security-Exposure ist kein grünes Gesamtergebnis.

---

17. Visualisierungsspezifikation

Chart 1 - Evidence Landscape

• Datei: data/FDR-2026-07_ai_delivery_evidence_matrix.csv;
• X: Jahr;
• Y: Evidenzgrad;
• Größe: Stichprobe/Corpus nur kategorisch, da Einheiten heterogen;
• Farbe/Symbol: Endpoint;
• kein Meta-Mittelwert.

Chart 2 - Effekt und Unsicherheit

• nur Studien mit vergleichbarem Zeitendpunkt und Intervallen;
• METR 2025 und 2026 separat;
• positive/negative Richtung klar definieren;
• keine Anbietertelemetrie in denselben kausalen Forest Plot mischen.

Chart 3 - Review Queue

• simulierte λ/μ-Szenarien;
• Queue Age über Zeit;
• Annahmen sichtbar;
• zeigt Kapazitätsengpass, nicht empirisches Branchenergebnis.

Chart 4 - Control Pipeline

• fünf Gates von Input bis Produktion;
• Controls aus FDR-2026-07_ai_delivery_governance_controls.csv;
• Evidence-Artefakt je Gate.

Chart 5 - Outcome Scorecard

• Before/After oder Control/Treatment;
• Lead Time, Review, Quality, Security, Stability, Cost;
• keine einzelne zusammengesetzte „AI Productivity“-Zahl ohne Gewichtung.

---

18. Reproduzierbarkeit

Dateien

• data/FDR-2026-07_ai_delivery_evidence_matrix.csv
• data/FDR-2026-07_ai_delivery_governance_controls.csv
• data/FDR-2026-07_measurement_framework.csv

Reviewregeln

1. Studiendesign und Endpunkt nie weglassen.
2. Anbietertelemetrie als solche kennzeichnen.
3. Korrelation nicht als Kausalität formulieren.
4. unterschiedliche Aufgaben und Populationen nicht zu einem Durchschnittseffekt aggregieren.
5. Tool-/Modellzeitpunkt nennen.
6. Konfidenzintervalle und Autoreneinschränkungen darstellen.
7. LinearB- und Faros-Zahlen nicht vermischen.
8. arXiv-Preprints nicht als abschließend peer-reviewed darstellen.
9. lokale Experimente versionieren und Pre-Period archivieren.
10. AI-Provenance datenschutz- und arbeitsrechtlich angemessen gestalten.

---

19. Grenzen

1. Die Evidenzbasis entwickelt sich schnell.
2. Studien unterscheiden sich stark in Aufgaben und Populationen.
3. Anbieterfinanzierung oder proprietäre Daten können Replikation begrenzen.
4. PR- und Code-Metriken erfassen Geschäftswert nur indirekt.
5. Security Benchmarks älterer Modelle sind nicht direkt auf 2026er Systeme übertragbar.
6. Ein lokales Experiment kann Hawthorne-, Lern- und Selection-Effekte enthalten.
7. AI-Assistance ist oft schwer exakt zu messen, wenn mehrere Tools parallel genutzt werden.
8. Produktionsqualität kann sich erst nach längerer Zeit zeigen.
9. Der Report ist keine Empfehlung für oder gegen ein bestimmtes Produkt.
10. Vor Veröffentlichung sind neue Studien und aktualisierte Versionen erneut zu prüfen.

---

20. Zulässige und unzulässige Aussagen

Zulässig:

„Die bis Juli 2026 verfügbare Evidenz zeigt stark kontextabhängige Effekte; kontrollierte Aufgaben, reale Maintainerarbeit und Enterprise-Telemetrie liefern unterschiedliche Ergebnisse.“

Unzulässig:

„AI macht Entwickler nachweislich immer schneller.“

Zulässig:

„Ein Enterprise-Fall erreichte 2,09x PR-Durchsatz pro Entwickler und ungefähr doppelte Reviewlast.“

Unzulässig:

„AI verdoppelt die Softwareproduktivität.“

Zulässig:

„METR fand in seinem frühen-2025-Setting eine 19-prozentige Verlangsamung.“

Unzulässig:

„AI verlangsamt Softwareentwicklung grundsätzlich um 19 Prozent.“

---

21. Versionshistorie

• 1.0 · Juli 2026 · Zehn bestehende Evidenzitems plus longitudinaler 2026er Enterprise-Fall, Review-Capacity-Modell, 17 Controls und 90-Tage-Experimentdesign konsolidiert.
• Live-Version offen · Preprints, DORA, METR und neue kontrollierte Studien vor Veröffentlichung aktualisieren.

22. Quellen

1. Peng, S. et al., „The Impact of AI on Developer Productivity: Evidence from GitHub Copilot“, 2023, https://www.microsoft.com/en-us/research/publication/the-impact-of-ai-on-developer-productivity-evidence-from-github-copilot/.
2. Becker, J. et al. / METR, „Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity“, 10.07.2025, https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/.
3. Becker, J. et al. / METR, „We are Changing our Developer Productivity Experiment Design“, 24.02.2026, https://metr.org/blog/2026-02-24-uplift-update/.
4. DORA, „The Impact of Generative AI in Software Development“, https://dora.dev/ai/gen-ai-report/, abgerufen im Juli 2026.
5. Song, F.; Agarwal, A.; Wen, W., „The Impact of Generative AI on Collaborative Open-Source Software Development“, arXiv:2410.02091v3, 14.05.2026, https://arxiv.org/abs/2410.02091.
6. Faros AI, „The AI Engineering Report 2026: The Acceleration Whiplash“, https://www.faros.ai/research/ai-acceleration-whiplash, abgerufen im Juli 2026.
7. GitHub, „Does GitHub Copilot improve code quality? Here’s what the data says“, https://github.blog/news-insights/research/does-github-copilot-improve-code-quality-heres-what-the-data-says/, abgerufen im Juli 2026.
8. Pearce, H. et al., „Asleep at the Keyboard? Assessing the Security of GitHub Copilot’s Code Contributions“, IEEE S&P 2022 / arXiv:2108.09293, https://arxiv.org/abs/2108.09293.
9. Fu, Y. et al., „Security Weaknesses of Copilot-Generated Code in GitHub Projects: An Empirical Study“, arXiv:2310.02059, https://arxiv.org/abs/2310.02059.
10. LinearB, „2026 Software Engineering Benchmarks Report“, https://linearb.io/resources/software-engineering-benchmarks-report, abgerufen im Juli 2026.
11. LinearB, „8 million pull requests reveal where engineering productivity breaks down“, https://linearb.io/blog/8-million-prs-engineering-productivity, abgerufen im Juli 2026.
12. Google Cloud, „2024 Accelerate State of DevOps Report“, https://dora.dev/research/2024/dora-report/, abgerufen im Juli 2026.
13. NIST, „Secure Software Development Framework (SSDF) Version 1.1“, https://csrc.nist.gov/pubs/sp/800/218/final, abgerufen im Juli 2026.
14. OWASP, „Top 10 for Large Language Model Applications“, https://genai.owasp.org/llm-top-10/, abgerufen im Juli 2026.
15. He, Hao; Agarwal, Shyam; Denisov-Blanch, Yegor; Azaletskiy, Pavel; Koyejo, Sanmi; Vasilescu, Bogdan (2026), „AI Writes Faster Than Humans Can Review: A Longitudinal Study of an Enterprise 2x Mandate“, arXiv:2607.01904, https://arxiv.org/abs/2607.01904, abgerufen im Juli 2026.
16. NIST, „Secure Software Development Practices for Generative AI and Dual-Use Foundation Models“, SP 800-218A, https://csrc.nist.gov/pubs/sp/800/218/a/final, abgerufen im Juli 2026.
17. DORA, „State of AI-assisted Software Development 2025“, https://dora.dev/dora-report-2025/, abgerufen im Juli 2026.

---

Disclosure und Haftungsausschluss

FW Delta entwickelt AI-gestützte Automatisierung und Software. Das Unternehmen kann wirtschaftlich von Implementierungs- und Governance-Projekten profitieren. Der Report enthält deshalb positive, negative und unsichere Evidenz und trennt kontrollierte Studien von Anbietertelemetrie.

Der Report ersetzt keine Security-, Datenschutz-, Arbeitsrechts- oder Produktfreigabe. Lokale Daten, Risikoklasse und regulatorischer Kontext sind individuell zu prüfen.