Softwareentwicklung mit KI

Management-Zusammenfassung

Rund um das Programmieren mit KI kursieren zwei Erzählungen, die sich zu widersprechen scheinen. Die eine sagt: KI macht Entwickler dramatisch schneller, bald schreibt sich Software fast von selbst. Die andere sagt: Eine sorgfältige Studie hat gezeigt, dass erfahrene Entwickler mit KI sogar *langsamer* wurden. Beide Erzählungen stützen sich auf echte, seriöse Untersuchungen — und beide sind, für sich genommen, irreführend. Der Zweck dieses Moduls ist, die Forschungslage so zu ordnen, dass ein Unternehmer daraus eine belastbare Entscheidung ableiten kann, statt einer Schlagzeile zu folgen.

Der belegbare Kern lautet: Der Nutzen von KI beim Programmieren ist real, aber extrem ungleich verteilt — und zwar entlang von drei Achsen: Erfahrungsstand des Menschen, Vertrautheit mit der Aufgabe und Reifegrad des Codes, an dem gearbeitet wird. Für klar umrissene Neuentwicklung durch weniger erfahrene Personen sind große Geschwindigkeitsgewinne gut belegt (eine kontrollierte Studie mit GitHub Copilot maß 55,8 % schnellere Fertigstellung einer klar definierten Aufgabe; [BELEGT]). Für erfahrene Entwickler, die an ihrem eigenen, großen, langjährig gepflegten Code arbeiten, kann sich der Effekt umkehren: In einer randomisierten Studie von METR (2025) brauchten solche Entwickler *mit* KI-Werkzeugen 19 % länger — während sie selbst glaubten, 20 % schneller gewesen zu sein ([BELEGT]).

Dieser Widerspruch ist kein Fehler in den Studien, sondern die eigentliche Erkenntnis. Die Forschung nennt das Muster „jagged frontier" (gezackte Grenze): KI hebt die Leistung bei manchen Aufgaben stark, verschlechtert sie bei anderen — und die Grenze verläuft unintuitiv, sodass man ohne Prüfung nicht weiß, auf welcher Seite man steht (Dell'Acqua et al., 758 Berater, 2023; [BELEGT]). Hinzu kommen zwei gut belegte Nebenwirkungen, die einen Unternehmer direkt angehen: KI-gestützt entstandener Code zeigt in großflächigen Auswertungen Zeichen sinkender Wartbarkeit (mehr Duplikate, weniger Refactoring; Anbieterauswertung GitClear, [ANBIETERANGABE]), und Teams, die KI stark einsetzen, verbessern zwar die individuelle Produktivität, verschlechtern aber im Mittel die Liefer­stabilität (DORA 2024; [BELEGT]).

Für den Nicht-Techniker-Unternehmer folgt daraus keine Absage an KI, sondern eine Präzisierung: KI ist ein Beschleuniger für das erste Drittel des Weges — Ideen, Prototypen, Standardbausteine, Verstehen fremden Codes — und ein trügerischer Begleiter im letzten Drittel, wo Korrektheit, Sicherheit und Wartbarkeit über Jahre zählen. Wer das erste Drittel nutzt und das letzte Drittel mit Prüfung, Test und menschlicher Verantwortung absichert, gewinnt. Wer die Schlagzeile „schreibt sich selbst" für bare Münze nimmt, baut technische Schulden auf, die er nicht sieht — bis sie teuer werden.

Kernaussagen mit Einzelquellen

Jede Aussage trägt eine Statusmarke. „[BELEGT]" = durch benannte Primärstudie gedeckt; „[ANBIETERangabe]" = Zahl stammt von einem interessengebundenen Anbieter/ Werkzeughersteller; „[STRITTIG]" = Befund existiert, ist aber umstritten oder schwach generalisierbar; „[UNKLAR]" = nicht sicher belegbar.

1. Eine kontrollierte Studie (Peng, Kalliamvakou, Cihon, Demirer, 2023) fand, dass

Entwickler mit GitHub Copilot eine klar umrissene Programmieraufgabe (einen HTTP-Server in JavaScript schreiben) im Mittel 55,8 % schneller abschlossen als die Kontrollgruppe. Die Autoren sind bei GitHub/Microsoft tätig. — arXiv 2302.06590, 13.02.2023. [BELEGT] (mit Interessenhinweis).

1. Eine randomisierte kontrollierte Studie von METR (2025) fand das Gegenteil für

einen anderen Kontext: 16 erfahrene Open-Source-Entwickler brauchten bei 246 realen Aufgaben in ihren eigenen großen Repositorys 19 % länger, wenn sie KI-Werkzeuge (überwiegend Cursor Pro mit Claude 3.5/3.7) nutzen durften — sie *schätzten* sich jedoch um 20 % schneller ein. — metr.org, 10.07.2025; arXiv 2507.09089. [BELEGT].

1. Der Effekt von KI ist stark erfahrungsabhängig: In einer Feldstudie mit

5.179 Kundendienst-Mitarbeitern (Brynjolfsson, Li, Raymond) stieg die Produktivität im Mittel um 14 %, bei Neulingen/gering Qualifizierten um 34 %, bei erfahrenen Kräften kaum. — NBER Working Paper 31161, 2023 (rev.); erschienen Quarterly Journal of Economics 2025. [BELEGT] (Analogie aus dem Kundenservice, nicht aus dem Coding).

1. Die „jagged frontier": In einem Feldexperiment mit 758 Beratern der

Boston Consulting Group (Dell'Acqua et al.) erledigten KI-Nutzer *innerhalb* der KI-Stärken 12,2 % mehr Aufgaben, 25,1 % schneller und in höherer Qualität; bei einer Aufgabe *außerhalb* der KI-Stärken waren sie 19 Prozentpunkte seltener korrekt. — HBS Working Paper 24-013, Sept. 2023; SSRN 4573321; Organization Science 2025. [BELEGT].

1. Sicherheit: In einer Nutzerstudie (Perry, Srivastava, Kumar, Boneh, Stanford)

schrieben Teilnehmer *mit* KI-Assistent (Codex davinci-002) signifikant unsichereren Code — glaubten aber häufiger, sicheren Code geschrieben zu haben. — arXiv 2211.03622; ACM CCS 2023. [BELEGT].

1. Team- vs. Individualebene: Der DORA-Report 2024 (Google) fand, dass

KI-Einsatz die individuelle Produktivität und Zufriedenheit hebt, aber die Liefer­stabilität und den Durchsatz im Mittel senkt: Eine Steigerung der KI-Nutzung um 25 % war mit −1,5 % Durchsatz, −7,2 % Stabilität und −2,6 % Zeit für wertvolle Arbeit assoziiert. — dora.dev, Accelerate State of DevOps Report 2024. [BELEGT].

1. Code-Wartbarkeit: Eine Auswertung von 211 Mio. geänderten Codezeilen

(2020–2024) durch den Analyse-Anbieter GitClear zeigt steigende Code-Duplikate (von 8,3 % der geänderten Zeilen 2021 auf 12,3 % 2024) und sinkendes Refactoring (von 25 % auf unter 10 %); erstmals überstieg kopierter Code den „verschobenen"/wiederverwendeten Code. — gitclear.com, 2025/2026. [ANBIETERANGABE] (interessengebundener Werkzeughersteller).

1. Benchmark-Realität: Auf dem verbreiteten Coding-Benchmark SWE-bench stiegen

KI-Ergebnisse laut Stanford HAI AI Index 2025 zwischen 2023 und 2024 um 67,3 Prozentpunkte — ein enormer Sprung. — hai.stanford.edu, AI Index 2025. [BELEGT]. Zugleich argumentiert die Analyse „The SWE-Bench Illusion" (2025), dass hohe Benchmark-Werte teils Memorierung statt echter Problemlösung spiegeln: Auf externen, weniger „bekannten" Repositorys fiel die Trefferquote von 60–76 % auf unter 53 %. — arXiv 2506.12286. [STRITTIG].

1. Kompetenzverfall (schwächster Beleg, bewusst so markiert): Eine

Preprint-Studie des MIT Media Lab („Your Brain on ChatGPT", n = 55, Aufgabe: Aufsätze) maß bei LLM-Nutzern schwächere EEG-Vernetzung und schlechtere Erinnerung an den eigenen Text („cognitive debt"). Kleine Stichprobe, kein Coding, noch nicht peer-reviewed. — arXiv 2506.08872, 2025. [STRITTIG].

Thematische Kapitel

A2 — Produktivität: Wie viel schneller — und wann das Gegenteil?

Recherche. Die am häufigsten zitierte Positivzahl stammt aus der Copilot-Studie von Peng et al. (2023): Rekrutierte Entwickler, die eine klar definierte Aufgabe lösten (einen HTTP-Server in JavaScript implementieren), waren mit Copilot im Mittel 55,8 % schneller als ohne ([BELEGT], arXiv 2302.06590). Die Studie berichtet zusätzlich *heterogene* Effekte: Weniger erfahrene und jüngere Entwickler profitierten stärker. Wichtig für die Einordnung: Die Autoren arbeiten bei GitHub bzw. Microsoft, dem Anbieter des getesteten Werkzeugs — kein Ausschlusskriterium, aber ein Grund, die Zahl nicht isoliert zu lesen.

Dem steht die METR-Studie von 2025 gegenüber ([BELEGT], metr.org 10.07.2025; arXiv 2507.09089). Sie ist methodisch besonders streng (randomisiert, reale Aufgaben statt Laboraufgabe) und maß das Gegenteil: 16 erfahrene Entwickler, die an ihren *eigenen* großen Repositorys (im Schnitt 22.000+ GitHub-Sterne, über 1 Mio. Codezeilen) arbeiteten, brauchten mit KI-Werkzeugen 19 % *länger*. Bemerkenswert ist die Selbst­täuschung: Dieselben Entwickler glaubten hinterher, 20 % schneller gewesen zu sein. Die Autoren betonen selbst die Grenzen: Das Ergebnis gilt nicht automatisch für Neulinge, für unvertrauten Code oder für andere Domänen.

Analyse. Auf den ersten Blick widersprechen sich +55,8 % und −19 % fundamental. Bei genauem Hinsehen messen beide Studien schlicht *verschiedene Situationen*. Peng: klar umrissene Neuaufgabe, kein Altlastcode, gemischte Erfahrung, Laborsetting. METR: offene reale Aufgaben, riesige vertraute Codebasis, Top-Experten, echte Arbeitsumgebung. Der scheinbare Widerspruch löst sich auf, sobald man die *Bedingungen* mitliest. Genau davor warnt jede seriöse Lektüre: Eine einzelne Produktivitätszahl ohne Kontext (Wer? Welche Aufgabe? Welcher Code?) ist wertlos. Auffällig ist zudem, dass die Selbstwahrnehmung in beiden Studien nach oben verzerrt ist — Menschen *fühlen* sich mit KI schneller, auch wenn sie es nicht sind. Für Messungen im eigenen Betrieb heißt das: Gefühlte Zeitersparnis ist kein Beleg.

Auswertung. Für wen gilt was? Der große Geschwindigkeitsgewinn ist plausibel für Aufgaben, die *neu, klar umrissen und standardnah* sind, und für Personen mit *wenig* Vorerfahrung, die sonst lange suchen müssten. Der Nulleffekt oder Negativeffekt droht bei *erfahrenen* Fachkräften in *großen, vertrauten, eigenwilligen* Systemen — dort kostet das Prüfen und Korrigieren der KI-Vorschläge mehr Zeit, als es spart. Ein Unternehmer sollte daher nie fragen „Macht KI schneller?", sondern „Bei *welcher* unserer Aufgaben, für *welche* Person?".

Für den Nicht-Techniker-Unternehmer: Erwarten Sie den größten Zeitgewinn dort, wo etwas *von null* entsteht und die Aufgabe klar ist — ein Prototyp, ein kleines Tool, ein Standardformular. Erwarten Sie ihn *nicht* automatisch dort, wo an einem gewachsenen, geschäftskritischen System geschraubt wird. Und trauen Sie keiner Produktivitätszahl, die nicht sagt, für wen und wofür sie gemessen wurde — auch nicht dem eigenen Bauchgefühl.

A3 — Codequalität, technische Schuld, Wartbarkeit

Recherche. Der Analyse-Anbieter GitClear wertete 211 Mio. geänderte Codezeilen (2020–2024, u. a. aus Repositorys von Google, Microsoft, Meta) aus und berichtet: Der Anteil duplizierter Codeblöcke stieg von 8,3 % (2021) auf 12,3 % (2024); der Anteil von Refactoring (dem Aufräumen/Wiederverwenden bestehenden Codes) sank von 25 % auf unter 10 %; erstmals überstieg „copy/paste" den Anteil „verschobenen", also wiederverwendeten Codes ([ANBIETERANGABE], gitclear.com). GitClear verkauft Analyse-Werkzeuge und hat ein Interesse an der Erzählung „Code wird schlechter, messt es mit uns" — die Zahlen sind dennoch aus echten Repositorys und methodisch offengelegt.

Auf Systemebene stützt der DORA-Report 2024 (Google) das Bild aus unabhängiger Quelle: Höhere KI-Nutzung war mit *geringerer* Liefer­stabilität assoziiert ([BELEGT], dora.dev) — dazu ausführlich Kapitel A-Team unten.

Analyse. „Duplikate steigen, Refactoring sinkt" ist genau das Muster, das man erwartet, wenn Code schneller *produziert* als *durchdacht* wird. KI macht das Hinzufügen neuer Zeilen billig; das Aufräumen bleibt Menschenarbeit und wird unter Zeitdruck zuerst gestrichen. Der Befund ist korrelativ, nicht kausal sauber bewiesen — GitClear kann nicht zweifelsfrei zeigen, dass *die KI* die Ursache ist. Aber die Richtung passt zu unabhängigen Befunden (DORA) und zur Theorie. Gegenargument: Manche Duplikation ist harmlos oder wird später bereinigt; und Werkzeug-Anbieter neigen zur Dramatisierung. Beides zusammengenommen: Der Trend ist ernst zu nehmen, die genaue Größe unsicher ([STRITTIG] hinsichtlich Kausalität, [ANBIETERANGABE] hinsichtlich der Zahlen).

Auswertung. Technische Schuld ist für einen Unternehmer kein abstraktes Ingenieursthema, sondern eine *versteckte Bilanzposition*: Code, der heute billig entsteht, aber schlecht wartbar ist, verteuert jede spätere Änderung. Wer mit KI viel Code schnell erzeugt, ohne Aufräumen einzuplanen, tauscht sichtbare Anfangsgeschwindigkeit gegen unsichtbare Folgekosten. Das gilt besonders, wenn Nicht-Techniker Code „von der KI" übernehmen, ohne dass jemand die Wartbarkeit beurteilen kann.

Für den Nicht-Techniker-Unternehmer: Fragen Sie bei jedem KI-gestützten Software­projekt nicht nur „Läuft es?", sondern „Kann ein anderer Mensch es in einem Jahr noch ändern?". Verlangen Sie, dass Aufräumen (Refactoring, Tests, Dokumentation) fester Teil des Auftrags ist — nicht der erste Posten, der beim Tempo gestrichen wird. Billiger Code, den niemand pflegen kann, ist teuer.

A4 — Debugging, Tests und Sicherheit

Recherche. Die Stanford-Studie von Perry et al. (2023, ACM CCS; arXiv 2211.03622) ließ Teilnehmer sicherheitsrelevante Programmieraufgaben lösen — mit und ohne KI-Assistenten (Codex davinci-002). Ergebnis: Die KI-Gruppe schrieb *signifikant unsichereren* Code, hielt ihn aber häufiger für sicher ([BELEGT]). Ein Zusatzbefund: Teilnehmer, die der KI *weniger* vertrauten und ihre Eingaben sorgfältiger formulierten, produzierten sicherere Ergebnisse — kritische Nutzung schützt also teilweise.

Analyse. Die Kombination aus „schlechteres Ergebnis" und „höheres Vertrauen" ist das gefährlichste Muster überhaupt, weil es die eigene Kontrolle untergräbt: Wer glaubt, sicher zu sein, prüft weniger. Das deckt sich mit der Selbst­überschätzung aus der METR-Studie (Kapitel A2) und mit dem, was die Human-Factors-Forschung „Automation Bias" nennt (siehe GF-Abhandlung 2 „Autonomie"). Einschränkung: Perry et al. nutzten ein älteres Modell (2022); heutige Modelle sind besser. Aber der *Mechanismus* — überzeugend formulierter, doch fehlerhafter Vorschlag senkt die Wachsamkeit — ist modellunabhängig und dürfte fortbestehen, solange KI flüssig, aber nicht fehlerfrei formuliert.

Auswertung. Sicherheit ist der Bereich, in dem der Satz „sieht richtig aus" besonders trügt. Gerade weil KI plausiblen Code erzeugt, verschiebt sich die Fehlerquelle von „offensichtlich kaputt" zu „unauffällig unsicher". Für ein Unternehmen mit Kundendaten, Zahlungsverkehr oder regulierten Prozessen ist das ein Haftungs- und Reputationsrisiko, kein Komfortthema.

Für den Nicht-Techniker-Unternehmer: Behandeln Sie KI-geschriebenen Code wie die Arbeit eines schnellen, selbstbewussten Praktikanten: nützlich, aber niemals ungeprüft in den Produktivbetrieb. Bestehen Sie auf einer unabhängigen Sicherheits- und Testprüfung durch einen Menschen, bevor irgendetwas live geht, das mit Geld, personenbezogenen Daten oder Recht zu tun hat. Der überzeugende Ton der KI ist kein Qualitätsnachweis.

A5 — Neulinge vs. Profis: die gezackte Grenze

Recherche. Das klarste Bild zur Verteilung des Nutzens liefert die „jagged frontier"-Studie (Dell'Acqua et al., 758 BCG-Berater, 2023; SSRN 4573321; Organization Science 2025). *Innerhalb* der Aufgaben, die im KI-Können liegen, erledigten Nutzer 12,2 % mehr Aufgaben, 25,1 % schneller und in höherer Qualität. Bei einer bewusst *außerhalb* platzierten Aufgabe (die aussah wie eine KI-Aufgabe, es aber nicht war) waren KI-Nutzer 19 Prozentpunkte seltener korrekt ([BELEGT]). Ergänzend zeigt die Kundenservice-Studie (Brynjolfsson/Li/Raymond, 5.179 Agenten): +14 % im Mittel, +34 % bei Neulingen, kaum Effekt bei Erfahrenen ([BELEGT]).

Analyse. Zwei Muster überlagern sich. Erstens *Nivellierung*: KI hebt die Schwachen stärker als die Starken — im Kundenservice belegt, in der Softwareentwicklung plausibel (Peng-Studie zeigt größere Effekte bei Jüngeren). Zweitens *Zackenrisiko*: Die Grenze zwischen „KI hilft" und „KI schadet" ist unsichtbar und unintuitiv. Wer sie nicht kennt, wird gerade *außerhalb* der KI-Stärken zu KI-gläubig und wird schlechter. Beides zusammen erklärt, warum pauschale Aussagen scheitern: Der Anfänger bei einer Standardaufgabe und der Experte bei einer Grenzaufgabe erleben gegensätzliche Effekte.

Auswertung. Für die Personalfrage im Unternehmen heißt das Differenzierung: KI kann weniger erfahrene Kräfte messbar produktiver machen — aber nur mit Leitplanken, weil ihnen die Erfahrung fehlt, die Zacken zu erkennen. Erfahrene Kräfte gewinnen weniger Tempo, sind aber wertvoller denn je als *Prüfinstanz*: Sie erkennen, wann die KI daneben liegt. Die naive Rechnung „mit KI brauchen wir keine Erfahrenen mehr" ist durch die Datenlage nicht gedeckt — im Gegenteil.

Für den Nicht-Techniker-Unternehmer: KI ist am ehesten ein *Verstärker für Ihr Mittelfeld* — sie hebt solide, weniger erfahrene Kräfte spürbar. Sie ersetzt aber nicht die erfahrene Person, die beurteilt, ob das Ergebnis stimmt. Investieren Sie das gesparte Tempo in Prüfung, nicht in noch mehr ungeprüften Output. Und misstrauen Sie jedem Angebot, das verspricht, mit KI ganz ohne Fachleute auszukommen.

A6 — Kompetenzaufbau oder Kompetenzverfall?

Recherche. Der Befund ist hier bewusst dünn und als solcher zu kennzeichnen. Die meistzitierte Arbeit zum „Verfall" ist ein MIT-Media-Lab-Preprint („Your Brain on ChatGPT", n = 55, Aufgabe: Aufsätze schreiben; arXiv 2506.08872, 2025): LLM-Nutzer zeigten schwächere EEG-Vernetzung und erinnerten ihren eigenen Text schlechter; die Autoren prägen dafür den Begriff „cognitive debt". Kleine Stichprobe, keine Programmieraufgabe, noch nicht peer-reviewed — daher [STRITTIG]. Auf der anderen Seite steht der belegte *Aufbau*-Effekt: Die Kundenservice-Studie fand Hinweise, dass KI-Unterstützung Neulinge schneller lernen lässt (Brynjolfsson et al.; [BELEGT]).

Analyse. Die Studienlage ist echt gespalten und darf nicht geglättet werden. Es gibt kein starkes, direkt auf das Programmieren übertragbares Ergebnis, das „Kompetenzverfall durch KI" beweist. Es gibt einen plausiblen Mechanismus (wer Lösungen nur abnimmt, übt das Lösen nicht) und einen schwachen ersten Beleg dafür aus einer anderen Domäne. Es gibt zugleich einen belegten Lern­beschleuniger-Effekt bei Anfängern. Auflösung: Es kommt vermutlich auf die *Nutzungsweise* an — KI als Erklär- und Übungspartner baut Kompetenz auf; KI als reiner Antwort­automat, dessen Ergebnis man ungeprüft übernimmt, baut sie ab. Perry et al. (Kapitel A4) stützen das indirekt: kritische Nutzer schnitten besser ab.

Auswertung. Für ein Unternehmen ist die Kompetenzfrage strategisch, nicht pädagogisch: Wenn die eigene Mannschaft über Jahre nur noch KI-Vorschläge abnickt, verliert sie die Fähigkeit, diese Vorschläge zu beurteilen — genau die Fähigkeit, die laut Kapitel A5 den Wert der Erfahrenen ausmacht. Das ist ein schleichendes Risiko, das sich erst in der Krise zeigt (wenn die KI versagt und niemand mehr weiß, warum).

Für den Nicht-Techniker-Unternehmer: Verlangen Sie, dass KI bei Ihnen als *Lernwerkzeug* eingesetzt wird — die Leute sollen verstehen, was sie übernehmen, nicht nur, dass es läuft. Das ist kein moralischer Appell, sondern Risikovorsorge: Ihre teuerste Fähigkeit ist die, ein KI-Ergebnis beurteilen zu können. Sie erhalten sie nur, wenn Ihre Leute sie weiter üben. Belegt ist dieser Verfall noch nicht hart — plausibel und billig vorzubeugen aber allemal.

A7 — Große Codebasen vs. Greenfield; und was Benchmarks wert sind

Recherche. Die METR-Studie (A2) ist der beste Beleg dafür, dass große, gewachsene Systeme („Brownfield") die härteste Umgebung für KI sind — dort wurde der Negativ­effekt gemessen ([BELEGT]). Für die Frage „aber die KI wird doch rasend schnell besser?" liefert der Stanford HAI AI Index 2025 die Rahmenzahl: Auf dem Coding-Benchmark SWE-bench legten Systeme zwischen 2023 und 2024 um 67,3 Prozentpunkte zu ([BELEGT], hai.stanford.edu). Diese Zahl ist aber mit Vorsicht zu lesen: Die Analyse „The SWE-Bench Illusion" (2025, arXiv 2506.12286) zeigt, dass ein Teil der hohen Werte auf *Memorierung* beruht — auf externen, dem Modell unbekannteren Repositorys fiel die Trefferquote von 60–76 % auf unter 53 % ([STRITTIG]).

Analyse. Hier prallen zwei Wahrheiten aufeinander. Erstens: Der Fortschritt ist real und schnell — die Benchmark-Sprünge sind kein Marketing. Zweitens: Benchmarks überschätzen die Praxisfähigkeit, weil sie oft aus öffentlichem Code bestehen, den die Modelle im Training „gesehen" haben. Der Alltag eines Unternehmens besteht aber gerade aus *nicht-öffentlichem*, eigenwilligem Code — genau der Situation, in der METR den Negativeffekt maß und „SWE-Bench Illusion" den Einbruch zeigt. Die ehrliche Lesart: Auf bekannten, standardnahen Aufgaben ist KI beeindruckend; auf dem eigenen, gewachsenen, undokumentierten System deutlich schwächer, als die Benchmark-Schlagzeile suggeriert.

Auswertung. Für Investitionsentscheidungen bedeutet das: Man darf den Benchmark-Fortschritt als Richtung ernst nehmen, aber nicht 1:1 auf das eigene Altsystem übertragen. Der sicherste Nutzen liegt weiter bei Neuem und Standardnahem; der Einsatz an der geschäftskritischen Altlast braucht Prüfung im *eigenen* Kontext (kleiner Pilot, gemessen), nicht Vertrauen in die Rangliste.

Für den Nicht-Techniker-Unternehmer: Lassen Sie sich von Benchmark-Sprüngen die Richtung zeigen, nicht die Entscheidung abnehmen. Bevor Sie KI auf Ihr wichtigstes, gewachsenes System loslassen, verlangen Sie einen kleinen, gemessenen Test *an Ihrem eigenen Code* — nicht an einer öffentlichen Beispielaufgabe. Was auf der Rangliste glänzt, muss bei Ihnen noch nichts taugen.

A8 — Gesamtbild der Studienlage: die Widersprüche stehen lassen

Recherche & Analyse. Fasst man die belegten Befunde zusammen, ergibt sich kein einheitliches „KI hilft/schadet", sondern ein Koordinatensystem: Nutzen hoch bei (a) geringer Vorerfahrung, (b) klarer, standardnaher, neuer Aufgabe, (c) kleinem oder unkritischem System — Nutzen niedrig oder negativ bei (a) hoher Expertise, (b) offener Aufgabe an der Fähigkeitsgrenze, (c) großem, vertrautem, geschäftskritischem System. Quer dazu laufen drei belegte Nebenwirkungen: Selbst­überschätzung (METR, Perry), sinkende Wartbarkeit (GitClear, DORA) und mögliche Kompetenzatrophie ([STRITTIG]). Der Fortschritt der Modelle (HAI) ist real, aber Benchmarks überschätzen die Praxis (SWE-Bench Illusion).

Auswertung. Die wichtigste Meta-Erkenntnis für einen Entscheider ist methodisch: *Jede* pauschale KI-Produktivitätszahl ist ohne die drei Achsen (Person, Aufgabe, System) bedeutungslos, und die Selbstwahrnehmung der Nutzer ist als Messgröße unbrauchbar. Wer im eigenen Haus über KI-Einsatz entscheidet, braucht deshalb eigene, kleine, ehrliche Messungen — keine Marketingfolien.

Für den Nicht-Techniker-Unternehmer (Gesamt-Fazit des Moduls)

Was heißt das konkret für einen Unternehmer, der von Technik keine Ahnung hat, aber vermutet, dass hier seine Lösung liegt?

Die Forschung gibt eine überraschend klare, praktische Antwort — nur eben nicht die Schlagzeilen-Antwort. KI im Programmieren ist weder Wundermittel noch Blendwerk; sie ist ein *Beschleuniger mit scharfen Kanten*. Nutzen Sie sie dort, wo sie belegt stark ist: beim schnellen Entstehen von Neuem, beim Verstehen und Prototypisieren, beim Anheben weniger erfahrener Kräfte. Sichern Sie sie dort ab, wo sie belegt trügt: bei Sicherheit, bei geschäftskritischer Altlast, bei allem, was über Jahre gewartet werden muss. Und akzeptieren Sie die unbequemste Einzel­erkenntnis: Das *Gefühl*, mit KI schneller zu sein, ist kein Beleg — mehrere Studien zeigen, dass Menschen sich hier systematisch überschätzen.

Konkret bedeutet das drei Führungsentscheidungen, die keinen Technikhintergrund verlangen. Erstens: Trennen Sie „schnell bauen" von „sicher betreiben" — das erste darf die KI beschleunigen, das zweite bleibt geprüfte Menschenverantwortung. Zweitens: Halten Sie erfahrene Prüfkompetenz im Haus; sie ist im KI-Zeitalter wertvoller, nicht überflüssiger. Drittens: Messen Sie klein und ehrlich im eigenen Kontext, bevor Sie groß entscheiden. Wer diese drei Dinge tut, holt den realen Nutzen und vermeidet die belegten Fallen — und genau das ist der Punkt, an dem aus „ich verstehe es nicht" ein kontrolliertes „ich lasse es kontrolliert bauen" wird.

Quellenliste + „schnell veraltend"

Primärstudien & amtliche/institutionelle Quellen

• Peng, S.; Kalliamvakou, E.; Cihon, P.; Demirer, M. (2023): *The Impact of AI on

Developer Productivity: Evidence from GitHub Copilot.* arXiv:2302.06590, 13.02.2023. https://arxiv.org/abs/2302.06590 — [BELEGT] (Autoren bei GitHub/Microsoft).

• METR (2025): *Measuring the Impact of Early-2025 AI on Experienced Open-Source

Developer Productivity.* metr.org, 10.07.2025; arXiv:2507.09089. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/ — [BELEGT].

• Dell'Acqua, F. et al. (2023): *Navigating the Jagged Technological Frontier.* HBS

Working Paper 24-013; SSRN 4573321; Organization Science 2025. https://www.hbs.edu/faculty/Pages/item.aspx?num=64700 — [BELEGT].

• Brynjolfsson, E.; Li, D.; Raymond, L. (2023): *Generative AI at Work.* NBER Working

Paper 31161; Quarterly Journal of Economics 2025. https://www.nber.org/papers/w31161 — [BELEGT].

• Perry, N.; Srivastava, M.; Kumar, D.; Boneh, D. (2023): *Do Users Write More

Insecure Code with AI Assistants?* ACM CCS 2023; arXiv:2211.03622. https://arxiv.org/abs/2211.03622 — [BELEGT].

• DORA / Google (2024): *Accelerate State of DevOps Report 2024.*

https://dora.dev/research/2024/dora-report/ — [BELEGT] (Exakte Prozentwerte −1,5 %/−7,2 %/−2,6 % je +25 % KI-Nutzung; über Report referiert, Stand 11/2024).

• Stanford HAI (2025): *AI Index Report 2025*, Kap. Technical Performance.

https://hai.stanford.edu/ai-index/2025-ai-index-report/technical-performance — [BELEGT] (SWE-bench +67,3 Prozentpunkte 2023→2024).

• Liang et al. (2025): *The SWE-Bench Illusion.* arXiv:2506.12286.

https://arxiv.org/abs/2506.12286 — [STRITTIG] (Kritik an Benchmark-Aussagekraft).

• MIT Media Lab (2025): *Your Brain on ChatGPT: Accumulation of Cognitive Debt.*

arXiv:2506.08872. https://arxiv.org/abs/2506.08872 — [STRITTIG] (Preprint, n=55, Aufsatz-Aufgabe, kein Coding).

Anbieter-/interessengebundene Quellen (als solche gekennzeichnet)

• GitClear (2025/2026): *AI Copilot Code Quality Research* (211 Mio. Codezeilen,

2020–2024). https://www.gitclear.com/ai_assistant_code_quality_2025_research — [ANBIETERANGABE].

Schnell veraltend (vor Drucklegung neu prüfen)

• Alle Produktivitäts-/Qualitätszahlen sind modell- und werkzeuggebunden: METR- und

Peng-Ergebnisse gelten für die getesteten Modell­generationen (2023 bzw. Anfang 2025); neuere Modelle können verschieben. METR hat angekündigt, das Studiendesign fortzuentwickeln (metr.org, 02/2026) — Folgeergebnisse beobachten.

• DORA erscheint jährlich; die 2025er-Ausgabe kann die 2024er-Befunde relativieren.
• Stanford HAI AI Index erscheint jährlich; Benchmark-Zahlen veralten binnen Monaten.
• GitClear aktualisiert die Serie fortlaufend; die 2026er-Zahlen können abweichen.
• SWE-bench-Landschaft (Verified, Pro, Kritiken) ändert sich schnell — Stand prüfen.

Selbstprüfungs-Notiz (zweistufiger Faktencheck)

Durchgang 1 (Entwurf): Recherche der Anker laut Auftrag; Entwurf mit Statusmarken.

Durchgang 2 (Selbstprüfung): Jede Kernzahl gegen die Primärquelle gegengeprüft. Bestätigt aufgelöst: Peng 55,8 % (arXiv-Abstract); METR 19 % langsamer, 16 Entwickler, 246 Aufgaben, Selbsteinschätzung +20 % (METR-Blog); Dell'Acqua 758 Teilnehmer, +12,2 %/25,1 %/höhere Qualität innen, −19 Prozentpunkte außen (HBS-Seite); Brynjolfsson 5.179 Agenten, +14 %/+34 % (NBER-Seite); Perry unsicherer Code trotz höheren Sicherheitsgefühls (arXiv); DORA −1,5 %/−7,2 %/−2,6 % je +25 % KI-Nutzung (über den Report referiert; die dora.dev-Primärseite bestätigt die *qualitative* Aussage „senkt Stabilität und Durchsatz", die exakten Prozentwerte stammen aus der Berichterstattung über den Report und sind vor Druck gegen die PDF zu verifizieren — als kleine Restunsicherheit markiert); HAI SWE-bench +67,3 Prozentpunkte (über die Berichterstattung zum AI Index; die HAI-Kapitelseite ist grafiklastig, die Zahl vor Druck gegen das PDF prüfen); SWE-Bench Illusion 60–76 % → <53 % (arXiv).

Relativiert/eingeordnet, nicht verworfen:

• Peng-Studie: als methodisch valide, aber anbieternah gekennzeichnet und der

METR-Studie kontrastierend gegenübergestellt (kein Glätten des Widerspruchs).

• GitClear: als [ANBIETERANGABE] geführt; Kausalität als [STRITTIG] markiert.
• „Cognitive debt": bewusst als schwächster Beleg [STRITTIG] geführt (Preprint,

kleine Stichprobe, andere Domäne) — nicht als Beweis für Coding-Kompetenzverfall ausgegeben.

Bewusst NICHT behauptet: Keine Übertragung der Kundenservice-Zahlen (14/34 %) direkt auf das Programmieren (nur als Erfahrungs-Achsen-Beleg genutzt); keine Aussage, KI ersetze Entwickler; keine Einzelstudie als allgemeingültig ausgegeben.

Zwei Restunsicherheiten für die Redaktion: (1) exakte DORA-Prozentwerte gegen das Report-PDF; (2) exakte HAI-SWE-bench-Zahl gegen das AI-Index-PDF — beide qualitativ gesichert, numerisch vor Druck final gegenzulesen.