Die Fabrik kehrt zurück

Wie KI den Traum von der Software-Fabrik wiederbelebt, und ob die Agilität das überleben kann

Veröffentlicht von Polity | Juli 2026
Autoren: Alexandre Kotcherguine, Vision Officer & Investor, Polity;
Kevin Riedl, Managing Partner, Wavect GmbH

Dieser Artikel befasst sich mit Methoden der Softwareentwicklung und Organisationsdesign. Er stützt sich auf Originalforschung, amtliche Dokumente und Unternehmensangaben aus erster Hand, geprüft bis 2. September 2026. Herstellerstudien und Benchmark-Ergebnisse sind als solche gekennzeichnet. Nichts darin stellt professionelle, rechtliche oder Anlageberatung dar.

Das Wichtigste vorab

1968 forderte Douglas McIlroy auf der NATO Conference on Software Engineering eine Industrie massenproduzierter, aus Katalogen bestellbarer Softwarekomponenten. Es war eine einflussreiche industrielle Analogie für eine wiederholbare Software-Lieferkette. In den 1970er und 1980er Jahren folgten konkrete Softwarefabrik-Programme; das Agile Manifesto von 2001 verstand sich später als Alternative zu dokumentationsgetriebenen, schwergewichtigen Entwicklungsprozessen. Dieser Artikel argumentiert, dass agentische KI McIlroys Vision in neuer Form wiederbelebt: passgenauer Code auf Abruf statt Komponenten aus einem Katalog. Die Evidenz ist gemischt. GitClears Herstellerstudie von 2026 meldet schlechtere Wartbarkeitssignale; METRs randomisierte Studie von Anfang 2025 zeigte erfahrene Entwickler mit KI langsamer, obwohl sie sich schneller einschätzten; und METRs späteres Experiment konnte wegen Selektions- und Messproblemen keine belastbare aktuelle Schätzung liefern. Die Engineering-Disziplin wandert daher nach oben im Stack, in Spezifikation und Validierung. Stripes Bericht aus erster Hand liefert ein Produktionsbeispiel: Mehr als tausend vollständig von Minions geschriebene Pull Requests werden wöchentlich gemerged, aber Menschen prüfen sie, und die Agenten laufen in einer umfangreichen Tool- und Testumgebung. Die entscheidende Variable ist Governance, nicht das Modell allein.

Der Traum, der zweimal scheiterte

Das Argument für die Industrialisierung von Software ist so alt wie der Name der Disziplin. Die Organisatoren nannten das Treffen von 1968 NATO Software Engineering Conference; der Bericht dokumentiert sowohl das Ziel, Software Engineering zu etablieren, als auch Uneinigkeit über seine Bedeutung (1). McIlroy schlug dort Familien und Kataloge standardisierter Komponenten vor und verglich sie ausdrücklich mit Schrauben, Widerständen und industriellen Baugruppen (2). Die Analogie ähnelt Taylors Zerlegung und Standardisierung von Arbeit, doch die Bezeichnung von McIlroys Vorschlag als „explizit tayloristisch“ ginge über seinen Text hinaus. Michael Cusumanos Feldforschung dokumentiert Hitachis Software Works ab 1969 und Fabrikinitiativen bei NEC, Toshiba und Fujitsu ab Mitte der 1970er Jahre (3).

Diese Programme etablierten keine universelle Katalogwirtschaft für Software. Cusumano beschreibt stattdessen unternehmensspezifische Kombinationen aus Werkzeugen, wiederverwendbaren Assets, standardisierten Methoden, Training und Qualitätskontrolle, mit unterschiedlichen Ergebnissen (3). Die siebzehn Unterzeichner des Agile Manifesto trafen sich 2001 dagegen auf der Suche nach einer Alternative zu dokumentationsgetriebenen, schwergewichtigen Entwicklungsprozessen (4). Der historische Befund trägt daher eine engere Analogie als ein schlichtes zweimaliges Scheitern: Industrielle Ansätze erzielten lokale Prozess- und Qualitätsgewinne, beseitigten aber nicht den Bedarf an Kontext, Anpassung und Engineering-Urteil.

Warum es diesmal anders ist

Agentische KI verändert die Mechanik auf eine Weise, wie es die Software Factory nie konnte. McIlroys Komponenten mussten von Menschen geschrieben, katalogisiert, generalisiert und gewartet werden, bevor irgendjemand sie bestellen konnte; der Overhead der Generalisierung war es, der die Wiederverwendung tötete. Ein Coding Agent kollabiert diesen Overhead. Er holt keine vorgefertigte Komponente aus dem Regal; er synthetisiert auf Abruf eine passgenaue, aus einer Beschreibung der Absicht, gegen den spezifischen Kontext der Codebasis vor ihm. Der Katalog ist nicht länger endlich und von Menschen gepflegt; er ist, faktisch, die latente Kapazität des Modells, das benötigte Teil zu erzeugen, wenn man danach fragt.

Die Fähigkeit ist nicht länger spekulativ, doch die Benchmark-Historie braucht Präzision. Das ursprüngliche SWE-bench-Paper von 2023 meldete als bestes Ergebnis 1,96 Prozent auf dem vollständigen Testset. SWE-bench Verified wurde erst später eingeführt, daher war dieser Wert kein Verified-Score. Anthropic meldete im Februar 2026 für Claude Opus 4.6 einen Verified-Wert von 80,84 Prozent; zugleich dokumentierten die offiziellen Benchmark-Betreiber Kontaminationsbedenken und ein eng zusammengerücktes Spitzenfeld (5). Anthropics Economic Index, basierend auf Stichproben aus Claude.ai und der First-Party-API, die O*NET-Aufgaben zugeordnet wurden, berichtete im März 2026, dass bei rund 49 Prozent der Berufe Claude für mindestens ein Viertel ihrer Aufgaben verwendet worden war. Das ist kumulativ beobachtete Plattformabdeckung, nicht der Anteil aller Arbeit, den KI tatsächlich erledigt (6). Die Ergebnisse zeigen, dass erhebliche Coding-Arbeit delegiert werden kann, belegen aber nicht von selbst autonome End-to-End-Auslieferung.

Die alte Spannung, jetzt messbar

Ist die Mechanik neu, so ist die Gefahr alt, und Herstellerforschung quantifiziert inzwischen mehrere Warnsignale. GitClears Studie vom Juni 2026 analysierte 623 Millionen Änderungen von 2023 bis zum ersten Halbjahr 2026. Gegenüber 2023 meldet sie 35 Prozent weniger funktionsübergreifende Aufrufe, 70 Prozent weniger verschobene Refactoring-Zeilen, 81 Prozent mehr Codeblock-Duplikation, 41 Prozent mehr Copy-and-Paste innerhalb eines Commits und 15 Prozent mehr Zwei-Wochen-Churn (7). Der Bericht misst Korrelationen in GitClears Datensatz und ist keine kontrollierte Kausalschätzung des KI-Effekts. In Ward Cunninghams ursprünglicher Metapher kann schnelleres Ausliefern bei aufgeschobener Konsolidierung Technical Debt erzeugen, deren Zinsen die Delivery später bremsen (8).

Das Produktivitätsbild ist ebenso zweischneidig. Mitte 2025 führte die Non-Profit-Organisation METR die erste randomisierte kontrollierte Studie des Feldes zu KI-Coding-Unterstützung durch: Sechzehn erfahrene Open-Source-Developer, die an reifen, ihnen gut vertrauten Repositories arbeiteten, erledigten 246 reale Aufgaben, wobei die KI-Nutzung zufällig erlaubt oder untersagt wurde (8). Die Developer prognostizierten eine Beschleunigung um 24 Prozent; Fachökonomen und Machine-Learning-Forscher prognostizierten noch größere Gewinne. Das gemessene Ergebnis war das Gegenteil: Aufgaben dauerten mit KI im Schnitt 19 Prozent länger. Auffälliger als die Verlangsamung war die Wahrnehmungslücke: Selbst nachdem sie sie erlebt hatten, schätzten die Developer, KI habe sie um 20 Prozent beschleunigt. Das ist Goodharts Schatten in neuem Umfeld: Jede sichtbare Metrik (Commit-Volumen, Pull-Request-Zahl, ausgelieferte Zeilen) kann steigen, während das, was zählt, die Zeit bis zu einem korrekten und wartbaren Ergebnis, sich in die Gegenrichtung bewegt. Eine komplementäre Sorge, die Praktiker inzwischen Comprehension Debt nennen, benennt das tiefere Risiko: Wenn die Generierung das Verständnis überholt, werden die einzigen Menschen, die KI-Output verlässlich reviewen können (die Senior Engineers), zum Engpass, und die Probleme, die sie übersehen, erreichen die Produktion.

Ein erster Einwand: Die Signale verändern sich

Das ehrliche Gegenargument lautet, dass jede Zahl eine Momentaufnahme ist. METRs Experiment mit Werkzeugen von Ende 2025 lieferte Schätzungen in die Gegenrichtung: 18 Prozent Beschleunigung für zehn zurückgekehrte Teilnehmer und 4 Prozent für neu rekrutierte Teilnehmer. Beide Konfidenzintervalle schlossen jedoch null ein, und METR erklärte das Experiment wegen Teilnehmer- und Aufgabenselektion sowie unzuverlässiger Zeitmessung zu einem unzuverlässigen Signal für den aktuellen Produktivitätseffekt (10). DORA fand ebenfalls ein verändertes, aber weiter gemischtes Bild: 2024 waren je 25 Prozent mehr KI-Adoption mit 1,5 Prozent weniger Durchsatz und 7,2 Prozent weniger Stabilität verbunden; 2025 war höhere Adoption sowohl mit mehr Durchsatz als auch mit mehr Instabilität assoziiert (11). Diese Beobachtungsdaten beweisen keine Ursache.

Die neuere Evidenz schärft das praktische Argument, ohne eine einfache Umkehr zu belegen. Modelle, Werkzeuge und Teilnehmerverhalten änderten sich, während die Messung schwieriger wurde. Besserer Kontext, Agent-Harnesses, Review-Workflows und Spec-first-Praktiken bleiben plausible, überprüfbare Mittel zum Risikomanagement, doch METRs Follow-up kann sie nicht als Ursache schnellerer Arbeit isolieren. Organisationen sollten deshalb ihre eigenen End-to-End-Ergebnisse messen, einschließlich Review-Zeit, Nacharbeit, Vorfällen und Wartbarkeit.

Wohin das Handwerk wandert: nach oben im Stack

Die Auflösung des Paradoxons lautet, dass KI die Engineering-Disziplin nicht abschafft; sie verlagert sie. Die Praktiken, die die Agile-Unterzeichner verteidigten (testgetriebene Entwicklung, Continuous Integration, Refactoring, die Pflege der Codegesundheit), werden nicht obsolet, wenn eine Maschine die Zeilen schreibt. Sie wandern vom Tastenanschlag zur Spezifikation, vom Akt, Code zu tippen, zum Akt, ihn zu definieren, einzugrenzen und zu verifizieren. Der klarste Ausdruck dieser Wanderung ist der rasche Aufstieg von Spec-Driven Development im Lauf von 2025-26. Das ist die Praxis, eine strukturierte, versionierte Spezifikation (Ziele, Constraints, Akzeptanzkriterien) zu schreiben, bevor ein Coding Agent aufgerufen wird. Der Agent hat dann eine explizite Absicht zu implementieren statt einen vagen Prompt zu interpretieren.

Für die konkrete Toolentscheidung statt des historischen Arguments behandelt unser GitHub-Spec-Kit-Test für Produktionsteams aktuelle Befehle, Grenzen, Security Boundary, Kosten und Pilotdesign.

Andrej Karpathy prägte „Vibe Coding“ im Februar 2025 für einen bewusst lockeren Workflow, in dem Entwickler den Code weitgehend nicht mehr lesen und Modelländerungen akzeptieren. Sein ursprünglicher Beitrag beschrieb ihn als passend für Wegwerf-Wochenendprojekte, nicht als Produktionsmethode (12). Spec-Driven Development ist eine strukturiertere Gegenfamilie. GitHubs Spec Kit behandelt etwa Ziele, Constraints und Akzeptanzkriterien als versionierte Inputs, aus denen Pläne und Implementierungen abgeleitet werden (13). Das macht Spezifikationen nicht automatisch korrekt und nicht jedes Coding-Tool spec-driven. Es verlagert prüfbare Absicht früher in den Workflow, ähnlich wie testgetriebene Entwicklung erwartetes Verhalten vor der Implementierung definiert.

Die menschliche Rolle verschiebt sich entsprechend. Der Engineer der agentischen Fabrik verbringt weniger Zeit damit, grundlegenden Code zu schreiben, und mehr Zeit mit Architektur, Spezifikationspräzision und Quality Gatekeeping: Product Ownership im vollsten Sinn. Die Metapher, die in der Praktikerliteratur wiederkehrt, trifft es: Die KI trägt die Steine; der Architekt entwirft und inspiziert weiterhin die Pyramide. Das ist keine Schmälerung des Engineering-Urteils, sondern seine Konzentration, und genau deshalb finden Organisationen, die das Urteil herausnehmen und erwarten, das Modell werde es liefern, die Duplikation und den Churn, die GitClear gemessen hat. Das Modell liefert Code. Es liefert keine Sorgfalt.

Agilität bewahren: das Governance-Problem

Hier trifft das Argument wieder auf das ältere über Enterprise Agile, denn die Fehlermodi reimen sich. Die ursprüngliche Software Factory entfernte das handwerkliche Urteil und nannte das Ergebnis Industrialisierung; Enterprise Agile entfernte die technischen Praktiken und behielt die Zeremonien; die sorglose Einführung von KI entfernt das Verständnis und behält das Velocity-Dashboard. In jedem Fall bleibt die sichtbare, auditierbare Oberfläche erhalten, während die tragende Substanz ausgehöhlt wird. Die agentische Fabrik ist deshalb nicht automatisch eine Wiederherstellung der Agilität; sie ist eine Weggabelung. Auf dem einen Pfad wird KI zum ultimativen De-Engineering-Instrument: eine Maschine zur Erzeugung ungereviewten, duplikativen, kontextblinden Codes im industriellen Maßstab, bei der jede Produktivitätsmetrik grün leuchtet, während sich Technical Debt und Comprehension Debt darunter aufzinsen. Auf dem anderen wird sie zum ersten Werkzeug, das den Durchsatz der Fabrik und die Anpassungsfähigkeit des Handwerks zugleich liefert.

Was die Pfade trennt, ist Governance, und ihre Bestandteile sind inzwischen einigermaßen gut verstanden. Dazu gehören Spezifikationsdisziplin als organisatorische Fähigkeit statt individueller Gewohnheit (lebende, versionskontrollierte Specs, die über jede einzelne Agent-Session hinaus bestehen); automatisierte Quality Gates zwischen Agent-Output und menschlicher Abnahme, damit ein Agent, der tausend Pull Requests pro Woche produziert, selbst bei einer Schwachstellenquote von nur einem Prozent nicht stillschweigend zehn neue Schwachstellen ausliefert; Review-Workflows, umgerüstet auf die neuen Fehlermodi, die strukturell und sicherheitsförmig sind statt tippfehlerförmig; und persistenter, governter Kontext (geteiltes Gedächtnis, Konventionen und Constraints, die mit der Codebasis reisen, damit der Agent aufhört, die Duplikation wieder einzuschleppen, zu der das Modell standardmäßig neigt). Für regulierte Domänen (Finanzdienstleistungen, Gesundheitswesen und die On-Chain-Finanzinfrastruktur, in der Polity arbeitet) ist diese Governance-Schicht kein optionaler Feinschliff; sie ist die Voraussetzung, unter der agentischer Durchsatz überhaupt zulässig wird. Die Kontrolle, die die ursprüngliche Fabrik von oben auferlegte und die Enterprise Agile als Zeremonie verordnete, wird hier neu gedacht als Disziplin, die in das Entwicklungssubstrat selbst eingebettet ist, nah am Engineer, ausgedrückt als ausführbare Spezifikation und automatisierte Verifikation statt als Vorarbeiterbuch.

Für manche regulierten Einsätze ist das auch eine rechtliche Designfrage. Nach dem konsolidierten EU Artificial Intelligence Act gelten Kapitel III Abschnitte 1 bis 3 ab 2. Dezember 2027 für Hochrisikosysteme nach Anhang III und ab 2. August 2028 für produktbezogene Hochrisikosysteme nach Anhang I. Artikel 11, 12 und 14 verlangen technische Dokumentation, automatische Ereignisaufzeichnung und wirksame menschliche Aufsicht für Systeme, die tatsächlich in die Hochrisikokategorien fallen (14). Eine versionierte Spezifikation, ein Pipeline-Audit-Trail und ein menschliches Freigabe-Gate können diese Kontrollen unterstützen, sind aber nicht automatisch gleichbedeutend mit Rechtskonformität. Klassifizierung und die weiteren Pflichten brauchen eine systemspezifische Prüfung.

Die Fabrik wird real: ein Fallbeispiel

Im Februar 2026 beschrieb Stripe seine unbeaufsichtigten One-Shot-Coding-Agents namens Minions. Nach Stripes Angaben werden jede Woche mehr als tausend vollständig von Minions geschriebene Pull Requests nach menschlichem Review gemerged. Stripes Developer Keynote bestätigte mehr als tausend wöchentlich bis in Produktion ausgelieferte Pull Requests mit menschlicher Prüfung und Freigabe. Der Jahresbericht für 2025 nennt 1,9 Billionen US-Dollar Gesamtvolumen, ohne zu behaupten, jeder Minion arbeite an zahlungskritischem Code (15).

Stripe führt das Ergebnis auf weit mehr als ein Modell zurück: isolierte Entwicklungsumgebungen, Repository-Kontext, ortsspezifische Regeln, Linting, selektive Tests aus einer Suite von über drei Millionen Tests und menschliches Review. Minions basieren auf einem Fork von Blocks Open-Source-Agent Goose, während Stripes Plattform und interne Werkzeuge unternehmensspezifisch sind. Der Bericht belegt, dass hoher Agentendurchsatz mit deterministischen Prüfungen und menschlicher Freigabe vereinbar ist. Er veröffentlicht aber keinen kontrollierten Vergleich, keine Fehlerrate und keine Kosten pro Pull Request (15).

Fazit: die Fabrik mit Gewissen

McIlroys Vorschlag von 1968 hatte beim Ziel recht und beim Weg unrecht. Er glaubte, Industrialisierung erfordere standardisierte, von Menschen katalogisierte Teile und den tayloristischen Apparat, sie zu verwalten; dieser Weg tötete die Agilität, die Software braucht, und das Urteil, das Engineers beisteuern. Agentische KI erreicht das Ziel über eine andere Straße (passgenaue Komponenten auf Abruf generieren statt generische bestellen) und beseitigt damit das spezifische Hindernis, an dem die Fabrik ein halbes Jahrhundert lang scheiterte. Aber sie erbt die Ursünde in neuer Form. Die Versuchung, das Modell als Ersatz für Engineering-Kultur zu behandeln statt als ein von ihr geführtes Instrument, ist dieselbe Versuchung, die erst die buchstäbliche Fabrik und dann Enterprise Agile aushöhlte, nun verfügbar mit weit größerer Geschwindigkeit und in weit größerem Maßstab.

Der stärkste Einwand bleibt: Wenn Agenten künftig spezifizieren, schreiben, testen und reviewen können, könnte „das Handwerk bewahren“ nur eine Übergangsphase beschreiben. Stripe zeigt bereits, dass Menschen nicht jede gemergte Änderung selbst tippen müssen. Das veröffentlichte System stützt sich jedoch weiter auf menschliches Review, deterministische Prüfungen und von Engineers gestaltete Infrastruktur. Der dauerhafte Punkt ist daher nicht, dass jeder Pull Request immer gleich manuell geprüft werden muss. Eine verantwortliche Organisation muss weiterhin festlegen, was gebaut werden soll, welcher Nachweis als korrekt gilt, welche Fehler tolerierbar sind und wann Automatisierung eine Änderung freigeben darf.

Die Lektion, die die Agile-Unterzeichner zwei Jahrzehnte lang zu vermitteln versuchten, gilt unverändert für die agentische Ära: Die Leichtigkeit des Prozesses muss durch die Stärke des Engineerings darunter verdient werden. KI macht die Leichtigkeit fast gratis und die Stärke fast optional, und genau deshalb muss die Stärke jetzt eine bewusste Entscheidung sein, codiert in Spezifikationen, durchgesetzt durch Quality Gates und verantwortet von Menschen, deren Rolle vom Schreiben des Codes zum Governen seiner Entstehung aufgestiegen ist. Die Fabrik ist zurückgekehrt. Ob sie Software industrialisiert oder de-engineert (ob sie Agilität bewahrt oder bloß deren Zerstörung automatisiert), wird nicht das Modell entscheiden. Es wird, wie immer schon, davon entschieden, ob die Organisation sich dafür entscheidet, das Handwerk zu behalten.

Die Geschichte von Enterprise Agile lehrte, dass eine Methode nicht dann gefährlich wird, wenn sie falsch ist, sondern wenn ihre Zeremonien das Handwerk überleben, das ihnen Bedeutung gab. Die agentische Fabrik stellt dieselbe Prüfung bei höherer Geschwindigkeit: Sie wird die Organisationen belohnen, die ihre Engineering-Disziplin nach oben im Stack verlagern, und schneller als je zuvor jene bestrafen, die das Verschwinden des Tippens mit dem Verschwinden der Notwendigkeit zu engineeren verwechseln.

Über Polity

Dieser Artikel ist Teil eines fortlaufenden Programms für Governance- und Thought-Leadership-Publikationen, das innerhalb des Polity-Governance-Modells entwickelt wird. Politys zentrale These lautet, dass dauerhafte Ergebnisse von der Governance-Architektur geformt werden: den Regeln, Anreizen und Institutionen, durch die Arbeit, Wert und Verpflichtung entstehen. Die agentische Software-Fabrik ist genau in diesem Sinn ein Governance-Problem: Dieselbe codegenerierende Fähigkeit industrialisiert oder de-engineert, je nach der Disziplin, die um sie gelegt wird. Polity baut Infrastruktur für regulierte digitale Finanzsysteme mit Governance-Frameworks, die dezentrale Systeme mit institutionellen Compliance-Anforderungen verbinden; die Frage, wie autonome Softwareproduktion mit hohem Durchsatz in eine regulierte Umgebung aufgenommen werden kann, ohne Assurance zu opfern, gehört zu denen, mit denen es sich direkt befasst.

Über Wavect

Die Wavect GmbH ist eine österreichische Software-Engineering-Agentur, die produktorientierte Software für Start-ups, Scale-ups und Enterprises entwickelt. Das Spektrum reicht von Full-Stack-Entwicklung über Fractional Engineering und Product Leadership bis zu Software Quality Assurance und angewandter Arbeit in künstlicher Intelligenz, Blockchain und Zero-Knowledge-Systemen. Wavect hat für das Polity-Programm Softwareentwicklungs- und Qualitätssicherungsleistungen erbracht. Co-Autor Kevin Riedl ist Managing Partner des Unternehmens. Weitere Informationen unter https://wavect.io.

Disclaimer: Dieser Artikel dient ausschließlich Informations- und Bildungszwecken. Er stellt weder professionelle, rechtliche, finanzielle noch Engineering-Management-Beratung dar und ist keine Empfehlung für eine Methode, ein Produkt, einen Service oder eine Organisation. Forschungszahlen wurden bis 2. September 2026 anhand der zitierten Quellen geprüft; mehrere stammen aus kontrollierten Studien mit begrenzter Stichprobe oder aus beobachtenden Herstellerdaten und werden entsprechend gekennzeichnet. Co-Autor Kevin Riedl ist Managing Partner der Wavect GmbH, die Softwareentwicklungs- und Qualitätssicherungsleistungen für das Polity-Programm erbringt. Die geäußerten Ansichten sind jene der Autoren.

Literatur und Primärquellen

1. Naur, P. and Randell, B. (eds.) (1969). Software Engineering: Report on a Conference Sponsored by the NATO Science Committee. Original 1968 conference report. NATO report (reviewed 2 September 2026).
2. McIlroy, M.D. (1968). “Mass Produced Software Components”. Author-hosted text (reviewed 2 September 2026).
3. Cusumano, M.A. (1989). The Software Factory: A Historical Interpretation. Field research based on company data, site visits and manager interviews. Computer History Museum archive (reviewed 2 September 2026).
4. Agile Manifesto authors (2001). Official history; official manifesto (reviewed 2 September 2026).
5. Jimenez, C.E. et al. (2023). SWE-bench; Anthropic (2026), Claude Opus 4.6 System Card; SWE-bench public experiments. Original paper; system card; experiment records (reviewed 2 September 2026).
6. Anthropic (2026). “Anthropic Economic Index report: Learning curves”. Economic Index (reviewed 2 September 2026).
7. GitClear (2026). The Maintainability Gap: AI Code Quality in 2026. Vendor observational research covering 623 million changes. GitClear report (reviewed 2 September 2026).
8. Cunningham, W. (1992). “The WyCash Portfolio Management System”; Becker, J. et al. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. Cunningham report; METR study (reviewed 2 September 2026).
9. Becker, J. et al. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. METR study; paper (reviewed 2 September 2026).
10. METR (2026). “We Are Changing Our Developer Productivity Experiment Design”. METR follow-up (reviewed 2 September 2026).
11. DORA (2024; 2025). Official software-delivery research. 2024 report; 2025 report; 2025 errata (reviewed 2 September 2026).
12. Karpathy, A. (2025). Original “vibe coding” post (reviewed 2 September 2026).
13. GitHub (2026). “What is Spec-Driven Development?” Spec Kit documentation (reviewed 2 September 2026).
14. European Union (2024, consolidated 27 July 2026). Regulation (EU) 2024/1689, Articles 11, 12, 14 and 113, as amended by Regulation (EU) 2026/1744. Consolidated AI Act; amending regulation (reviewed 2 September 2026).
15. Stripe (2026). Minions engineering posts, developer keynote and 2025 annual letter. Part 1; Part 2; keynote; annual letter (reviewed 2 September 2026).