Was LLMs beweisbar leisten, und wo die Belege aufhören

Ich habe nach Belegen gesucht, nicht nach Gegenbelegen. Es gibt sie. Sie hören alle an derselben Stelle auf.

Amazon hat 4.500 Entwicklerjahre gespart. Morgan Stanley 280.000 Entwicklerstunden. Nubank arbeitet achtmal effizienter. Goldman Sachs rechnet mit dem dreifachen Durchsatz.

Vier Zahlen, vier Pressemeldungen, keine einzige nachvollziehbare Messung. Bei Amazon ist die Quelle ein Tweet des CEO, dem Amazon-Entwickler öffentlich widersprochen haben. Bei Morgan Stanley übersetzt das Werkzeug Legacy-Code in englische Beschreibungen, es schreibt keine Zeile modernen Code. Die Nubank-Zahl steht in einer Fallstudie des Anbieters. Und Goldman Sachs erwartet das Dreifache. Erwartet.

Ich habe im August 2026 gesucht, was es jenseits davon gibt. Nicht Gegenbelege, sondern Belege. Untersuchungen, die zeigen, dass Teams mit LLMs schneller oder besser werden, und zwar so, dass man es nachvollziehen kann.

Es gibt sie. Sie sind stärker, als ich erwartet hatte.

Und sie enden alle vor der Auslieferung.

Ich kann keine Statistik

Das muss vorher raus, sonst funktioniert der Rest nicht.

Ich bin kein Entwickler und ich bin kein Wissenschaftler. Ich bin Team Lead eines Kanban-Teams und lese diese Studien als jemand, der wissen will, ob er seinem Team Lizenzen kaufen soll. Wenn in einem Paper „Hedges' g = 0,33“ steht, muss ich nachschlagen, was das bedeutet.

Was ich kann, ist eine einzige Frage stellen. Sie ist banaler, als man denkt.

Wurde gewürfelt?

Also: Hat jemand per Zufall entschieden, welche Entwickler das Werkzeug bekommen und welche nicht? Oder haben sich die Leute selbst dafür entschieden?

Daran hängt fast alles. Wenn Leute sich selbst entscheiden, greifen die Neugierigen, die Schnellen und die mit den einfachen Aufgaben zuerst zu. Danach vergleicht man nicht mehr "Werkzeug" gegen "kein Werkzeug". Man vergleicht Menschen gegen Menschen und schreibt dem Werkzeug zu, was an den Leuten lag.

Zweite Frage, die ich stellen kann: Wer hat gemessen, und was hatte er davon? Ein Anbieter, der seine eigene Wirkung ausrechnet, ist nicht automatisch unglaubwürdig. Aber er ist eine andere Sorte Beleg als eine Universität, die eine Kontrollgruppe mitlaufen lässt.

Dritte Frage: Was genau wurde gezählt? Codezeilen sind etwas anderes als Commits, und Commits sind etwas anderes als ein Release. Warum das der eigentliche Knackpunkt ist, habe ich an anderer Stelle aufgeschrieben.

Mehr Werkzeug brauche ich nicht. Und es reicht überraschend weit.

Vier Mal wurde gewürfelt

Ich habe genau vier Untersuchungen gefunden, in denen jemand per Zufall entschieden hat, wer das Werkzeug bekommt. Vier. Nach vier Jahren Debatte.

Die größte ist die beste. Sechs Forscher um Cui und Demirer haben drei Feldexperimente begleitet, bei Microsoft, bei Accenture und in einem großen Konzern, der anonym bleiben wollte. Insgesamt 4.867 Entwickler. Ein Teil bekam GitHub Copilot, der andere nicht, und wer in welche Gruppe kam, wurde ausgewürfelt. Veröffentlicht wurde das in Management Science, einer Fachzeitschrift mit Gutachterverfahren.

Ergebnis: Die Copilot-Gruppe hat rund 26 Prozent mehr Pull Requests pro Woche fertig bekommen.

Jetzt die Einschränkung, und die ist genauso wichtig. Zu so einer Zahl gehört immer eine Angabe, wie sicher sie ist. Hier steht 10,3 daneben (der Standardfehler, ein Maß für die Unsicherheit). Nach der üblichen Regel rechnet man diesen Wert doppelt in beide Richtungen, also gut 20 Prozentpunkte nach oben und nach unten. Damit landet man zwischen ungefähr 6 und ungefähr 46 Prozent. Die 26 sind nur die Mitte eines breiten Korridors.

Dazu kommt: Von den drei Firmen war der Effekt nur bei Microsoft deutlich größer als seine eigene Unsicherheit. Bei den anderen beiden kann die Zahl genauso gut Zufall sein. Und getestet wurde Copilot in der Fassung von 2022 und 2023, also intelligentes Autovervollständigen. Nicht das, was heute in deiner IDE sitzt.

Die zweite gewürfelte Studie kommt von Google. 96 eigene Entwickler, eine vorgegebene Aufgabe, Sommer 2024. Wer die Werkzeuge bekam, brauchte 96 Minuten, wer sie nicht hatte, 114. Das sind die 21 Prozent, die überall zitiert werden. Was fast immer weggelassen wird, steht im Paper selbst: „our confidence interval is large“. Übersetzt heißt das, die Autoren halten ihre eigene Zahl für zu unsicher, um sich darauf zu verlassen. Sie schreiben außerdem, dass man ein Laborergebnis von einer einzelnen Aufgabe nicht auf die Praxis übertragen darf.

Die dritte hat gar nichts gefunden. Eine große Softwarefirma hat drei Wochen lang 106 Entwickler begleitet, aufgeteilt in Copilot-Neulinge, eine Kontrollgruppe ohne Zugang und Leute, die es schon länger nutzten. In den gemessenen Daten bewegte sich nichts. Nicht die Anzahl der Änderungen, nicht die Pull Requests, nicht die Zeit. Was sich bewegte, war die Stimmung: 84 Prozent berichteten von positiven Veränderungen in ihrer täglichen Arbeit. Die Studie ist kurz und klein, sie beweist also nicht, dass es keinen Effekt gibt. Sie zeigt, wie weit Gefühl und Messung auseinanderliegen können.

Und die vierte ist die, die ich selbst zu oft benutzt habe.

Meine eigene Lieblingszahl hält nicht

METR hat 2025 sechzehn erfahrene Open-Source-Entwickler an echten Aufgaben in ihren eigenen Projekten gemessen und kam auf 19 Prozent mehr Zeit mit LLM-Werkzeugen. Dieselben Leute schätzten hinterher, sie seien 20 Prozent schneller gewesen. Diese Zahl habe ich im Juli im Plateau-Artikel benutzt und im August noch einmal, das zweite Mal mit einer Einschränkung. Die Einschränkung war zu schwach.

METR hat das Verfahren im Februar 2026 aufgegeben, und der entscheidende Grund arbeitet gegen mich, nicht für mich. Zwischen 30 und 50 Prozent der Teilnehmer haben Aufgaben absichtlich nicht eingereicht, bei denen ein LLM stark geholfen hätte, weil sie diese Aufgaben nicht ohne Werkzeug bearbeiten wollten. Ein Teilnehmer erledigte in der Gruppe ohne Werkzeug keine einzige Aufgabe. Gemessen wurden also bevorzugt die Aufgaben, bei denen Handarbeit sowieso reicht.

Dazu kam ein praktisches Problem. Zeit messen funktioniert nicht mehr, wenn jemand drei Agenten parallel laufen lässt und die Wartezeit für andere Arbeit nutzt. Und die Rekrutierung scheiterte, weil Entwickler nicht mehr ohne LLM arbeiten wollen, auch nicht für Geld.

Eine Wiederholung der 19 Prozent gibt es nicht, nur die Selbstauflösung durch die Urheber. Wer die Zahl heute als Beweis anführt, macht dasselbe wie die Anbieter mit ihren Pressemeldungen, nur in die andere Richtung. Ich eingeschlossen.

Damit liegt die ehrliche Zwischenbilanz auf dem Tisch. Vier Mal wurde gewürfelt, und heraus kamen plus 26 Prozent, plus 21 Prozent mit dem Hinweis „zu unsicher“, gar nichts, und minus 19 Prozent mit anschließendem Rückzug. Wer sich aus diesen vier eine aussucht, betreibt keine Recherche.

Die großen Zahlen, bei denen niemand gewürfelt hat

Alles, was zu den heutigen Werkzeugen existiert, ist nicht gewürfelt. Zu Claude Code, Cursor, Codex oder Devin gibt es kein einziges Zufallsexperiment. Das macht die Zahlen nicht wertlos. Es heißt, dass man genauer hinsehen muss, wie die Forscher das Problem umgangen haben.

Am saubersten macht das eine Untersuchung des Microsoft-Rollouts von Claude Code und der Copilot-Kommandozeile, Anfang 2026, Zehntausende Engineers, vier Monate beobachtet und gegen mehr als ein Jahr Vorlauf verglichen. Weil niemand gewürfelt hat, haben die Forscher zwei Dinge gemacht. Erstens vergleicht jeder Entwickler nur mit sich selbst, also seine Wochen mit Werkzeug gegen seine Wochen ohne. Zweitens haben sie ihren Rechenweg auf ein frei erfundenes Startdatum angewendet, an dem gar nichts passiert ist. Da kam auch nichts heraus. Das ist ein gutes Zeichen, denn es zeigt, dass die Methode nicht überall Effekte findet, wo man sie hinschickt.

Ergebnis: 24 Prozent mehr zusammengeführte Pull Requests, mit einer Bandbreite von 14 bis 34 Prozent (das Konfidenzintervall, also der Bereich, in dem der echte Wert sehr wahrscheinlich liegt). Über vier Monate ließ der Effekt nicht nach.

Und dann steht im Paper ein Satz, den ich einem Anbieter nicht glauben würde: „a merged PR is not the same as the value it delivers“. Ein zusammengeführter Pull Request ist nicht dasselbe wie der Wert, den er liefert. Das schreiben die Autoren über ihre eigene Kennzahl.

Die aufschlussreichste Untersuchung ist aber eine andere. Ein Forschungsteam hat eine Firma begleitet, die ihren Entwicklern im Juni 2025 per Ansage verordnet hat, den Durchsatz zu verdoppeln. 802 Entwickler, über 196.000 Pull Requests, 28 Monate, Cursor und Claude Code ohne Lizenzgrenze. Die Vorgabe wurde erfüllt, am Ende stand der 2,09-fache Durchsatz pro Kopf.

Dann rechnen die Autoren aus, wie viel davon überhaupt auf die Werkzeuge zurückgeht. Antwort: etwa das 1,42-fache. Der Rest ist die Vorgabe. Menschen, die eine Verdopplung liefern sollen, schneiden ihre Pull Requests eben anders zu.

Der Titel des Papers ist gleichzeitig sein Ergebnis: AI Writes Faster Than Humans Can Review.

Wenn man alles zusammenwirft, was es an Vergleichsstudien gibt, kommt man an einer Auswertung von 23 Studien vom Mai 2026 vorbei. Sie findet einen Effekt auf die Produktivität, der als mittelgroß gilt (in der Studie steht Hedges' g = 0,33; das ist ein Maß für die Stärke eines Effekts, und 0,33 liegt im mittleren Bereich). Kein Faktor zehn, kein Faktor zwei. Zwei Nebenbefunde finde ich wichtiger als die Zahl selbst. Erstens: Je näher eine Studie an echten Arbeitsbedingungen ist, desto kleiner der Effekt. Im Labor groß, in Firmen klein. Zweitens: Auf Lernen und Kompetenzaufbau findet dieselbe Auswertung keinen Effekt.

Wo es funktioniert, und da braucht es keine Statistik

Jetzt der Teil, der mich am meisten überzeugt hat, und ausgerechnet dort kommt man ohne Statistik aus. Wenn eine Firma 3.500 Dateien in sechs Wochen umbaut, muss man keine Kontrollgruppe suchen. Man muss nur wissen, wie lange das vorher gedauert hätte.

Airbnb hat rund 3.500 Testdateien von einem Test-Framework auf ein anderes umgezogen. 75 Prozent liefen im ersten Durchlauf von vier Stunden durch, nach vier Tagen Nachjustieren waren es 97 Prozent, der Rest von Hand. Sechs Wochen statt der geschätzten anderthalb Jahre. Dass die anderthalb Jahre von Airbnb selbst geschätzt sind, schwächt die Zahl, aber nicht das Muster.

Google hat 39 solche Umbauten über zwölf Monate protokolliert, und zwar bis auf die Ebene einzelner Änderungen: 595 Codepakete, 93.574 Einzeländerungen, gemacht von drei Entwicklern. Knapp drei Viertel der Pakete kamen vom Modell, ein gutes Drittel ging ohne jede menschliche Nachbearbeitung durch. In einer Schwesterarbeit steht der Satz, der mir seit Wochen nachgeht: 5.359 Dateien umgebaut, 87 Prozent des generierten Codes unverändert übernommen, und der Engpass war das Review.

Meta geht denselben Weg, nur strenger. Bei ihrem Testgenerator ACH muss jeder Vorschlag erst beweisen, dass er einen absichtlich eingebauten Fehler findet, bevor ihn überhaupt ein Mensch zu sehen bekommt. Von 31.677 solchen künstlichen Fehlern bleiben am Ende 571 Tests übrig, von denen die Engineers 73 Prozent behalten. Das sind weniger als zwei von hundert. Und trotzdem ein guter Handel, weil der Ausschuss nichts kostet außer Rechenzeit.

Bei Uber kommen inzwischen etwa 11 Prozent aller neuen Tests, die reviewt und übernommen werden, aus dem Generator. Auch hier ein ehrlicher Satz der Autoren: Testabdeckung ist nicht dasselbe wie Wirksamkeit.

Und im Review gibt es tatsächlich eine harte Zahl zur Wartezeit. Atlassian hat zwölf Monate laufenden Betrieb in Bitbucket ausgewertet, über 2.000 Repositories und mehr als 54.000 automatisch erzeugte Kommentare. Die Durchlaufzeit eines Pull Requests sank um 30,8 Prozent, in der Mitte der Verteilung von 20,7 auf 14,4 Stunden. Menschen schrieben 35,6 Prozent weniger Kommentare. Im selben Paper steht auch, dass maschinelle Kommentare seltener zu einer Änderung führen als menschliche, 38,7 gegen 44,5 Prozent. Wer die eigene Schwachstelle mitveröffentlicht, hat vermutlich sauber gemessen.

Wo es zusammenbricht

Sobald es um Bedeutung geht und nicht um Mechanik, kippt das Bild.

Google hat 178 echte Fehler aus dem eigenen Ticketsystem von einem Agenten reparieren lassen und dabei etwas gemacht, was fast niemand macht: doppelt bewertet. Stufe eins heißt, die Tests sind grün. Stufe zwei heißt, ein Mensch hat nachgesehen, ob der Fix inhaltlich das Richtige tut.

Bei Fehlern, die eine Maschine gemeldet hatte, waren 73 Prozent der Fixes grün und 43 Prozent auch inhaltlich richtig. Bei Fehlern, die ein Mensch beschrieben hatte, waren es 25,6 Prozent grün und 17,9 Prozent richtig. Anders gesagt: Bei gut vier von fünf echten, von einem Menschen gemeldeten Fehlern liefert der Agent keinen brauchbaren Fix.

Der Abstand zwischen „grün“ und „richtig“ ist dabei der eigentliche Befund. Grüne Tests behaupten eine Korrektheit, die nicht da ist. Jede Zahl, die diese zweite Prüfung nicht gemacht hat, ist zu optimistisch. Das sind fast alle.

Im Review sieht man dasselbe von der anderen Seite. Wie oft ein maschineller Review-Kommentar tatsächlich angenommen wird, liegt über verschiedene unabhängige Quellen zwischen sieben und 39 Prozent, bei Google 7,5 Prozent, bei Atlassian 38,7. Eine Untersuchung bei Mozilla und Ubisoft hat die Kommentare danach sortiert, worum es ging. Vorschläge zu Aufräumen und Stil wurden zu 18 Prozent angenommen. Vorschläge zur Funktionalität zu 4,8 bis 5,2 Prozent.

Das Werkzeug räumt Code auf, aber es erkennt nicht, ob der Code das Richtige tut.

Der Engpass wandert

Dass Beschleunigung an einer Stelle nur den Engpass verschiebt, habe ich im Messartikel durchgerechnet. Ich wiederhole das hier nicht. Interessant ist, wie oft mir das in dieser Recherche begegnet, ohne dass jemand danach gesucht hätte.

Die Studie mit der Verdopplungsvorgabe misst neben dem Durchsatz auch die Kosten: größere Pull Requests, längere Reviewzeiten, und einen Punkt, an dem maschinelles Review das menschliche in der Menge überholt. Bei Google war der Engpass des Umbaus nicht das Erzeugen, sondern das Review. Bei Atlassian sinkt die Durchlaufzeit genau deshalb, weil das Werkzeug Reviewarbeit übernimmt und nicht Entwicklungsarbeit.

Und je näher jemand am Ergebnis misst, desto kleiner werden die Zahlen. Eine Auswertung in Science über rund 170.000 Entwickler kommt auf plus 3,6 Prozent Ausstoß im Quartal. Das ist die breiteste Stichprobe im ganzen Feld und gleichzeitig die kleinste Zahl, und sie steht in der angesehensten Zeitschrift.

Bain hält im Technology Report die dazu passende Obergrenze fest. Codeschreiben und Testen sind 25 bis 35 Prozent der Zeit von der Idee bis zum Launch. Selbst ein Werkzeug, das diesen Anteil auf Null drückt, kann die anderen zwei Drittel nicht anfassen.

Das ist keine Meinung über LLMs. Das ist Bruchrechnen.

Zu Prozessen gibt es nichts

Ich habe gezielt danach gesucht, ob LLMs im Daily, im Refinement, im Planning oder in der Retro etwas messbar verbessern. Es gibt dazu keine belastbare Untersuchung. Kein Experiment, keine Kontrollgruppe, keine Messung von Meetingdauer oder Ergebnis vor und nach der Einführung.

Das Beste, was existiert, ist eine Fallstudie von der XP-Konferenz 2024 bei der Österreichischen Post: drei Scrum-Teams, LLM-Assistenten im Daily und im Refinement, mehrere Runden. Gemessen wurde ausschließlich, wie die Teilnehmer das fanden. Vier von sieben schätzten die konkreten Hinweise. Ob die Meetings kürzer wurden, weiß niemand, weil es keiner erhoben hat.

Bei Anforderungen und Backlog-Arbeit ist die Lage ähnlich. Es gibt eine ganze Literatur darüber, ob ein Modell User Stories schreibt, die einer Qualitätsvorgabe genügen. Es gibt keine einzige Untersuchung dazu, ob dadurch das Refinement kürzer wird, die Rückfragen weniger werden oder weniger Stories hinterher umgebaut werden müssen.

Wenn dir also jemand ein Werkzeug verkauft, das dein Daily verbessert, dann gibt es dafür keinen Beleg. Nicht einen schwachen, sondern keinen.

Vier Zahlen, die du nicht mehr zitieren solltest

Die ZoomInfo-Studie wird ständig als Produktivitätsstudie gehandelt. Sie zählt über 400 Entwickler hinweg, wie oft Vorschläge angenommen wurden und wie zufrieden die Leute waren. Ob irgendetwas schneller ging, steht da nicht.

Die 91 Prozent längere Reviewzeit, die überall herumgehen, werden dem DORA-Report zugeschrieben. Sie stehen nicht drin. Genauso wandern Messdaten der Firma Faros als DORA-Zahlen durch die Diskussion.

Einen DORA-Report für 2026 mit eigenen Erhebungen gibt es nicht. Was unter dem Namen kursiert, ist ein Rechenmodell auf den Umfragedaten von 2025.

Und die Annahmequote taugt grundsätzlich nicht als Erfolgsmaß. Faros meldet in seiner Auswertung über 22.000 Entwickler einen Anstieg von 20 auf 60 Prozent, und im selben Datensatz stehen deutlich mehr Nacharbeit und mehr Störungen pro Pull Request. Das ist ein Anbieterbericht ohne offengelegte Methode, entsprechend vorsichtig zu lesen. Aber eine Kennzahl, die nach oben zeigt, während das Ergebnis nach unten geht, misst nichts.

Was du daraus machst

Die Beweislage ist besser als der Zynismus und viel enger als das Versprechen. Wo die Aufgabe mechanisch ist und eine Maschine prüfen kann, ob das Ergebnis stimmt, funktioniert es messbar gut. Wo es um Bedeutung geht, trifft es in einem von fünf bis einem von zwanzig Fällen. Und über den Pull Request hinaus hat noch niemand einen Gewinn nachgewiesen, der auf dem Weg zur Auslieferung nicht auf einen Bruchteil zusammenfällt.

Für mich folgt daraus etwas, das ich vor der Recherche anders gesehen habe. Die Frage ist nicht, ob du LLMs einsetzt, sondern wofür du sie zuerst einsetzt. Und die Antwort steht in den Daten: nicht die Feature-Entwicklung. Der Umbau, den keiner anfassen will. Die Testabdeckung in dem Modul, das seit drei Jahren ohne Tests läuft. Die tausend Lint-Verstöße, die niemand aufräumt. Alles, wo ein Automat prüfen kann, ob es stimmt, und wo bisher Arbeit liegen bleibt, weil sie langweilig ist.

Das sind genau die Stellen, an denen Airbnb, Google, Meta und Uber ihre nachprüfbaren Zahlen geholt haben. Und es sind Stellen, an denen ein Fehlschlag nichts kostet. Wenn 98 von 100 generierten Tests Ausschuss sind, wirfst du sie weg. Wenn 82 von 100 generierten Fehlerbehebungen falsch sind, geht das nicht.

Wie du den Effekt danach messen willst, steht im Messartikel. Das Kurzformat: Reviewzeit getrennt von Entwicklungszeit, gegen deine eigene Baseline, ab heute. Und wenn dich jemand nach der Beschleunigung fragt, dann nenne die Zahl, die zählt. Nicht Commits. Releases.

Recherchestand ist der 18. August 2026, und ich habe jede Zahl in der Originalquelle nachgesehen. Wenn ich etwas falsch verstanden habe, und bei Statistik ist das nicht unwahrscheinlich, dann sag es mir. Dann korrigiere ich den Artikel und schreibe dazu, was sich geändert hat.

Diskussion gern auf Mastodon unter @nobsagile. Kontakt.

Quellen

• Cui, Demirer, Jaffe, Musolff, Peng, Salz: The Effects of Generative AI on High-Skilled Work. Evidence from Three Field Experiments with Software Developers, Management Science, 2025. Drei Zufallsexperimente, 4.867 Entwickler. pubsonline.informs.org · PDF
• Paradis, Grey, Madison, Nam, Macvean u. a.: How much does AI impact development speed? An enterprise-based randomized controlled trial, Google, 2024. 96 Entwickler, eine Aufgabe. arxiv.org/abs/2410.12944
• Butler, Suh, Haniyur, Hadley: Dear Diary. A Randomized Controlled Trial of Generative AI Coding Tools in the Workplace, 2024. 106 Teilnehmer, drei Wochen. arxiv.org/abs/2410.18334
• METR: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, 2025. arxiv.org/abs/2507.09089 und die Aufgabe des Verfahrens: We are Changing our Developer Productivity Experiment Design, 2026. metr.org
• Murphy-Hill, Butler, Savelieva: Adoption and Impact of Command-Line AI Coding Agents. A Study of Microsoft's Early 2026 Rollout of Claude Code and GitHub Copilot CLI, 2026. arxiv.org/abs/2607.01418
• He, Agarwal, Denisov-Blanch, Azaletskiy, Koyejo, Vasilescu: AI Writes Faster Than Humans Can Review. A Longitudinal Study of an Enterprise 2x Mandate, 2026. 802 Entwickler, 196.212 Pull Requests. arxiv.org/abs/2607.01904
• Maier, Gunzenhäuser, Schweisthal, Schneider, Feuerriegel: A meta-analysis of the effect of generative AI on productivity and learning in programming, 2026. 23 Studien. arxiv.org/abs/2605.04779
• Demirer, Musolff, Yang: Writing Code vs. Shipping Code. Productivity Effects Across Generations of AI Coding Tools, NBER Working Paper w35275, 2026. nber.org/papers/w35275
• Daniotti, Wachs, Feng, Neffke: Who is using AI to code?, Science, 2026. science.org
• Tantithamthavorn u. a.: RovoDev Code Reviewer. A Large-Scale Online Evaluation of LLM-based Code Review Automation at Atlassian, ICSE-SEIP 2026. arxiv.org/abs/2601.01129
• Google: Resolving Code Review Comments with Machine Learning, ICSE-SEIP 2024. dl.acm.org
• Olewicki, Da Silva, Mujahid, Castelluccio, Khomh, Adams: Impact of LLM-based Review Comment Generation in Practice. A Mixed Open-/Closed-source User Study, 2024. Mozilla und Ubisoft. arxiv.org/abs/2411.07091
• Rondon, Wei, Cambronero, Cito, Sun, Sanyam, Tufano, Chandra: Evaluating Agent-based Program Repair at Google, 2025. 178 Fehler aus dem internen Ticketsystem. arxiv.org/abs/2501.07531
• Meta: Mutation-Guided LLM-based Test Generation at Meta (ACH), FSE 2025. arxiv.org/abs/2501.12862
• Rastenis, Chou, Roy Choudhary, Just: Automated Software Test Generation at Industry Scale, ICSE-SEIP 2026, Uber. PDF
• Ziftci, Nikolov, Sjövall, Kim, Codecasa, Kim: Migrating Code At Scale With LLMs At Google, FSE 2025. arxiv.org/abs/2504.09691 sowie How is Google using AI for internal code migrations?, ICSE-SEIP 2025. arxiv.org/abs/2501.06972
• Covey-Brandt: Accelerating Large-Scale Test Migration with LLMs, Airbnb Engineering, 2025. medium.com
• Bain: Technology Report 2025. Codeschreiben und Testen als Anteil der Zeit von Idee bis Launch. bain.com
• Faros AI: The AI Engineering Report 2026, 2026. Anbieterbericht, Messdaten von 22.000 Entwicklern. faros.ai
• Cabrero-Daniel, Herda, Pichler, Eder: Exploring Human-AI Collaboration in Agile. Customised LLM Meeting Assistants, XP 2024. link.springer.com
• Esders: LLMs beschleunigen dein Team. Nur an der falschen Stelle. no-bullshit-agile.de und Warum LLMs auf einem Plateau sind. no-bullshit-agile.de sowie Work-Feedback Loop. no-bullshit-agile.de/wfl