Fünf Stufen der KI-Entwicklung: Warum die J-Kurve alle erwischt

Ein Framework sagt: AI-Tools können Softwareentwicklung fundamental verändern — wenn man seinen Workflow komplett umbaut. Eine Studie sagt: AI-Tools haben erfahrene Entwickler im Schnitt 19% langsamer gemacht. Beide haben Recht. Und zusammen erklären sie, warum sich die Investition in AI-Coding-Tools für so viele Teams noch nicht auszahlt.

Am 23. Jänner 2026 hat Dan Shapiro — CEO von Glowforge, Wharton Research Fellow — ein Stufenmodell veröffentlicht: "The Five Levels: from Spicy Autocomplete to the Dark Factory." Gleichzeitig liefert ein Randomized Controlled Trial von METR mit 16 erfahrenen Open-Source-Entwicklern harte Zahlen, die dem Marketing-Narrativ von "10x Productivity" widersprechen.

Auf den ersten Blick ein Widerspruch. Auf den zweiten Blick erzählen beide dieselbe Geschichte: Das Tool war nie das Problem. Was wir damit tun — oder eben nicht tun — ist es.

Das ist der erste Teil einer dreiteiligen Serie über die "Dark Factory Gap" in der Softwareentwicklung. Hier geht es um das Warum: Warum der Return on AI-Investment oft ausbleibt, obwohl die Technologie funktioniert. Teil 2 behandelt die Architektur-Patterns, die Level 4 und 5 möglich machen. Teil 3 die Konsequenzen für Teams, Rollen und Organisationen.

Aber dieser Post steht für sich. Die zentrale These: Die Lücke zwischen "wir haben ein AI-Tool installiert" und "wir haben unsere Entwicklung um AI herum neu gebaut" ist größer als sie aussieht. Und genau in dieser Lücke liegt sowohl das Problem als auch die Chance.

Die fünf Stufen: Von Spicy Autocomplete zur Dark Factory

Shapiro hat sein Framework bewusst an die Stufen des autonomen Fahrens angelehnt — ursprünglich von der NHTSA (National Highway Traffic Safety Administration) 2013 vorgeschlagen, heute als SAE J3016 die Standard-Taxonomie. Die Parallele ist präzise: Beim autonomen Fahren wirkten viele Systeme, die grob als SAE Level 2 gelten (z. B. Teslas Autopilot), "fast selbstfahrend". Zehn Jahre später wissen wir: Der Sprung von Level 2 zu Level 4 ist nicht inkrementell. Er erfordert eine komplett andere Architektur.

Man kann sich das auch musikalisch vorstellen: Level 0-2 ist Playback — man spielt ein bestehendes Stück nach, nur mit einem besseren Instrument. Level 3-5 ist Jazz — man improvisiert, aber innerhalb einer Struktur, die man vorher aufgebaut hat. Der Qualitätssprung liegt nicht im Instrument, sondern im Verständnis der Struktur.

Level 0 — Spicy Autocomplete

Tab-Completion auf Steroiden. GitHub Copilot im Grundmodus. "Kein einziges Zeichen trifft die Festplatte ohne deine Freigabe", wie Shapiro es formuliert. Der Entwickler schreibt Code, das AI-Tool schlägt den nächsten Block vor, man akzeptiert oder verwirft.

Für repetitive Boilerplate-Patterns spart das Zeit. Aber es ändert nichts am Workflow. Man entwickelt genauso wie vorher, nur mit einer etwas intelligenteren Autocomplete.

Level 1 — Lane-Keeping und Cruise Control

Man übergibt diskrete Aufgaben an einen "AI-Intern". "Schreib mir Unit Tests für diese Funktion." "Generiere die Swagger-Doku für diesen Endpoint." Der Entwickler bestimmt Tempo und Richtung, das Tool erledigt klar abgegrenzte Teilaufgaben.

Das Entwicklertempo ändert sich nicht fundamental. Man spart Zeit bei einzelnen Tasks, aber der Gesamtprozess bleibt gleich. Wie beim Auto: Tempomat hält die Geschwindigkeit, aber man steuert trotzdem selbst.

Level 2 — Autopilot auf der Autobahn

Pair Programming mit AI. Man arbeitet interaktiv, diskutiert Architekturentscheidungen, lässt das Tool größere Blöcke generieren, iteriert gemeinsam. Der Entwickler bleibt am Steuer, aber die AI übernimmt längere Strecken.

Shapiro schätzt, dass sich 90% der Entwickler, die sich für "AI-native" halten, hier befinden. Sein zentraler Punkt: "This is where most people think they're done. They are not."

Level 2 fühlt sich produktiv an. Man hat einen Copiloten, der mitdenkt. Und genau das macht diese Stufe tückisch: Man hat das Gefühl, etwas fundamental verändert zu haben — aber der Workflow ist im Kern der gleiche. Schnelleres Werkzeug, gleicher Prozess. Das ist wie Tempomat plus Spurhalteassistent: angenehmer, aber man sitzt immer noch selbst im Sitz.

Level 3 — Waymo mit Sicherheitsfahrer

Hier verschiebt sich die Rolle: Der Entwickler wird zum Code Reviewer. "Dein Leben besteht aus Diffs", sagt Shapiro. Die AI generiert den Code, der Entwickler prüft, korrigiert, gibt frei. Man schreibt weniger Code und liest mehr.

Das klingt nach einem kleinen Unterschied zu Level 2, ist aber ein kategorischer Sprung. Bei Level 2 entwickelt man mit der AI. Bei Level 3 entwickelt die AI, und man überprüft. Das erfordert eine komplett andere Kompetenz: Man muss Code reviewen können, den man nicht selbst geschrieben hat, in einer Geschwindigkeit, die den Produktivitätsgewinn nicht wieder auffrisst.

Oder anders formuliert: Bei Level 2 braucht man jemanden, der Code schreiben kann. Bei Level 3 braucht man jemanden, der Code lesen kann — und zwar schnell genug, um den Vorteil nicht wieder zu verspielen. Das sind unterschiedliche Skills, und der zweite ist oft schwerer aufzubauen als der erste.

Shapiros Beobachtung: "Almost everyone tops out here." Der Sprung zu Level 4 erfordert nicht mehr nur ein besseres Tool, sondern eine andere Arbeitsweise. Andere Rollen. Andere Organisationsform.

Level 4 — Robotaxi

Der Entwickler wird zum Product Manager. Man schreibt Spezifikationen, definiert Agent Skills, reviewt Pläne — und geht dann für 12 Stunden weg. Wenn man zurückkommt, ist der Code geschrieben, die Tests laufen, das Deployment steht.

Das am besten dokumentierte Beispiel ist StrongDM: Ein Team von drei Personen — Justin McCarthy, Jay Taylor und Navan Chauhan — arbeitet seit Sommer 2025 auf diesem Level. Ihr Open-Source-Agent "Attractor" ist bemerkenswert: Das Repository besteht im Wesentlichen aus drei Markdown-Spezifikationsdateien. Der Output: CXDB mit 16.000 Zeilen Rust, 9.500 Zeilen Go und 6.700 Zeilen TypeScript. Simon Willison, einer der angesehensten Stimmen in der Developer-Community, nannte es "the most ambitious form of AI-assisted software development I've seen yet."

Drei Personen. Drei Spec-Files. Zehntausende Zeilen produktiver Code in mehreren Sprachen.

Level 5 — Die Dark Factory

Der Name kommt von Fanucs "Lights-Out"-Roboterfabrik in Japan — einer Fabrik, die im Dunkeln läuft, weil keine Menschen drin sind, die Licht brauchen. Übertragen auf Software: "Eine Black Box, die Spezifikationen in Software verwandelt." Teams von weniger als fünf Personen.

Level 5 ist heute noch theoretisch für die meisten Anwendungsfälle. Aber die Richtung ist erkennbar. Und wer jetzt versteht, was den Sprung von Level 2 zu Level 4 möglich macht, steht besser da als wer darauf wartet, dass das Tool den Sprung von selbst macht.

Die J-Kurve: Warum AI-Tools zunächst langsamer machen

Die METR-Studie: 19% langsamer, nicht schneller

Im Juli 2025 hat METR (Model Evaluation & Threat Research) ein Randomized Controlled Trial veröffentlicht, das in seiner Rigorosität seinesgleichen sucht. 16 erfahrene Open-Source-Entwickler. 246 reale Tasks in Repositories, zu denen sie selbst beitragen. Mit und ohne AI-Tools.

Das Ergebnis: AI-Tools haben die Arbeit um 19% verlangsamt. Das 95%-Konfidenzintervall entspricht einer Verlangsamung zwischen ~2% und ~40% — statistisch signifikant. Kein Messfehler, kein Artefakt.

Der wirklich bemerkenswerte Teil: Vor der Studie haben die Teilnehmer geschätzt, dass sie mit AI 24% schneller wären. Nach der Studie — nachdem sie die Ergebnisse gesehen hatten — glaubten sie immer noch, 20% schneller gewesen zu sein. Die subjektive Wahrnehmung und die gemessene Realität lagen nicht nur auseinander, sie lagen in entgegengesetzter Richtung.

Wer sich jetzt fragt, ob die eigene Wahrnehmung des AI-Produktivitätsgewinns vielleicht auch zu optimistisch ist — das ist eine lohnende Frage. Es geht dabei nicht um ein Urteil, sondern um ein Messbarkeits-Problem: Ohne harte Daten lügt uns unser Gefühl an. Mir eingeschlossen.

Die breitere Datenlage bestätigt, dass das Bild komplexer ist als "10x Developer Productivity":

• Peng et al. (2023): 55,8% schneller mit GitHub Copilot — aber bei genau einer Aufgabe (HTTP-Server in JavaScript). Eine Aufgabe. Ein Kontext. Begrenzte Aussagekraft.
• Panto AI (Anbieterbericht): Die mediane Pull-Request-Größe steigt mit Copilot um 17-23%. Mehr Code heißt nicht besserer Code — mehr Code heißt mehr zu reviewen, mehr zu testen, mehr zu warten.
• Sonar 2026: 38% der Entwickler sagen, dass das Review von AI-generiertem Code mehr Aufwand erfordert als bei menschlich geschriebenem Code.
• ACM TOSEM: 29,5% der Python-Snippets und 24,2% der JavaScript-Snippets von Copilot enthalten Sicherheitsschwachstellen.
• Stack Overflow Developer Survey 2025: 46% der Entwickler vertrauen der Genauigkeit von AI-Output nicht (2024: 31%) — ein Anstieg um 15 Prozentpunkte.

AI-Tools können punktuell massiv beschleunigen — bei isolierten, gut definierten Tasks. In der Gesamtrechnung eines komplexen Softwareprojekts mit Reviews, Testing, Debugging und Wartung sieht die Bilanz anders aus.

Brynjolfssons J-Kurve: Der theoretische Rahmen

Erik Brynjolfsson, einer der einflussreichsten Ökonomen im Bereich Technologie und Produktivität, hat 2021 im American Economic Journal: Macroeconomics eine Theorie veröffentlicht, die erklärt, warum das so ist.

Seine These: General Purpose Technologies (GPTs) — und dazu zählen AI-Coding-Tools — erfordern komplementäre Investitionen, bevor sie Produktivitätsgewinne bringen. Neue Prozesse. Neue Skills. Organisatorische Umstrukturierungen. Und während diese Investitionen laufen, sinkt die gemessene Produktivität erst einmal.

Das ist die J-Kurve: Erst runter, dann hoch. Die Phase des Absinkens kann Jahre dauern.

Wer in Infrastruktur denkt, kennt das Muster: Eine Organisation stellt von manuellen Deployments auf CI/CD um. Die ersten drei Monate sind langsamer, nicht schneller — Pipelines aufbauen, Tests schreiben, Prozesse umstellen. Der Gewinn kommt erst, wenn die neue Infrastruktur steht und die alten Gewohnheiten weg sind.

Die Logik für AI-Tools ist dieselbe:

1. Unternehmen kaufen AI-Tools (Copilot-Lizenzen, ChatGPT Enterprise, Cursor-Seats).
2. Entwickler nutzen die Tools on top ihrer bestehenden Workflows.
3. Produktivität ändert sich kaum oder sinkt sogar (METR-Effekt: Kontextwechsel, Prompt-Engineering-Overhead, Review-Mehraufwand).
4. Management fragt nach dem ROI — verständlicherweise.
5. Einige Unternehmen stoppen. Die anderen redesignen ihre Workflows.
6. Erst nach der Umstrukturierung steigen die Produktivitätsgewinne.

Sinngemäß die zentrale Erkenntnis: Die größten Effekte sehen Organisationen nicht durch Tool-Rollout, sondern durch Workflow-Redesign. Wer Copilot installiert und "done" sagt, bleibt bei moderaten Gewinnen. Wer Arbeitsprozesse um AI herum neu organisiert, sieht in Feldstudien aus Wissensarbeit (z. B. Support, Consulting) deutlich größere Effekte.

Die Kluft in Zahlen

McKinsey hat im November 2025 eine Umfrage unter Softwareorganisationen veröffentlicht, die das quantifiziert: 15 Prozentpunkte Leistungsunterschied zwischen den Softwareorganisationen, die AI am effektivsten einsetzen, und denen, die es am wenigsten tun. Das ist ein erheblicher Abstand.

Die Erklärung liegt nicht in den Tools. McKinsey beschreibt explizit, dass starke Effekte mehr erfordern als reine Tool-Adoption — es braucht Rollen- und Prozess-Overhaul. Sonar quantifiziert den Review-Mehraufwand. Die METR-Studie zeigt die Diskrepanz zwischen Gefühl und Messung. Zusammen ergibt sich ein konsistentes Bild: Wer AI auf bestehende Prozesse drauflegt, sieht marginale Gewinne. Wer Workflows fundamental umgestaltet, sieht ein Vielfaches.

Die Feldstudien quantifizieren den Unterschied. Brynjolfsson, Li und Raymond (NBER 2023) messen in einem Fortune-500-Kundenservice rund 14% Produktivitätssteigerung durch AI-Assistenz — das ist der "Layering"-Effekt, AI auf bestehende Prozesse draufgesetzt. Dell'Acqua et al. (Harvard Business School 2023) zeigen, was passiert, wenn Berater AI tief in ihre Workflows integrieren: 25,1% schnellere Bearbeitung, 12,2% mehr abgeschlossene Aufgaben und über 40% höhere Qualität — allerdings nur innerhalb der Fähigkeitsgrenze des eingesetzten Modells. Jenseits dieser Grenze sanken die Ergebnisse. Die Zahlen sind in Feldstudien beobachtet, nicht universelle Konstanten — aber das Muster ist konsistent.

Mollick (Wharton) argumentiert qualitativ in dieselbe Richtung: Nicht "AI bolted onto the old way", sondern Prozesse neu designen. Die meisten Organisationen sind noch in der ersten Phase. Das ist kein Vorwurf — organisatorischer Wandel braucht Zeit, Budget und die Bereitschaft, kurzfristig langsamer zu sein. Genau die Ressourcen, die im Tagesgeschäft am knappsten sind.

Das Stufenmodell trifft die J-Kurve

Wenn man Shapiros fünf Stufen und Brynjolfssons J-Kurve übereinanderlegt, ergibt sich ein Muster:

Level 0-2 = Oberhalb der J-Kurve: Ein Tool installiert, marginale Verbesserungen, alles fühlt sich okay an. Kein Workflow-Redesign nötig. Kein Organisationswandel. Copilot schlägt Code vor, Cursor generiert Funktionen, man arbeitet wie vorher — nur mit Assistent.

Level 2-3 = Der Abstieg in die J-Kurve: Die einfachen Gewinne sind ausgereizt. Reviews werden aufwändiger. Die Code-Qualität schwankt. Sicherheitsprobleme tauchen auf. Man investiert in Prompts, in Kontext-Dokumente, in bessere Instructions — und die messbare Produktivität sinkt erst einmal. Genau das hat METR gemessen.

Level 3-4 = Der Boden und der Aufstieg: Hier passiert der eigentliche Wandel. Man schreibt nicht mehr Code mit AI-Hilfe — man schreibt Spezifikationen, die AI in Code umsetzt. Man braucht andere Skills (Spec Writing, Code Review statt Code Writing), andere Prozesse (Spec-driven statt iterative Development), andere Rollen (PM-Developer statt Individual Contributor). Das sind die komplementären Investitionen, die Brynjolfsson meint.

Level 4-5 = Oben angekommen: StrongDM mit drei Personen und drei Spec-Files. Der obere Arm der J-Kurve. Aber man kommt nur dort an, wenn man durch den Boden gegangen ist.

Die Struktur erzeugt eine vorhersagbare Dynamik: Level 2 fühlt sich komfortabel an. Es fühlt sich produktiv an. Der Abstieg in die J-Kurve sieht von oben riskant aus. Also bleibt man stehen. Das ist keine Dummheit — das ist eine rationale Reaktion auf sichtbares Risiko bei unsicherem Gewinn. Jede Organisation, die bei Level 2 verharrt, hat Gründe dafür. Das System erzeugt dieses Verhalten: Quartalsziele belohnen kurzfristige Stabilität, nicht langfristige Transformation.

Aber es bleibt ein lokales Maximum. Und wer die Struktur versteht, kann bewusst entscheiden, ob und wann der Abstieg sich lohnt.

Meine Perspektive

Ich kenne dieses Muster nicht, weil ich es bei Kunden beobachte. Ich kenne es, weil ich es selbst durchlaufen habe. Mehrfach.

Wir kaufen Terraform. Nutzen es wie Bash-Skripte. Kein State Management, keine Module, kein Testing. "Bringt nix." Dann baut man es richtig auf und versteht plötzlich, warum es so designed ist. Kubernetes, Docker, CI/CD — das gleiche Muster, jedes Mal. Tool kaufen, auf bestehende Prozesse draufsetzen, enttäuscht sein. Dann, irgendwann, den Prozess umbauen und merken: Das Tool war nie das Problem. Der Prozess war es.

Bei Infralovers evaluieren wir AI-Workflows systematisch auf verschiedenen Stufen — weil unsere Kunden auf unterschiedlichen Levels stehen und jeweils andere Herausforderungen haben. Wir validieren Arbeitsweisen von strukturiertem Prompting (Level 1) über Review-zentrierte Workflows (Level 3) bis zu spezifikationsgetriebenem Arbeiten (Level 4) in unserer eigenen Praxis. Mein persönlicher Workflow ist heute auf Level 4: Ich beschreibe das gewünschte Ergebnis, AI-Agenten übernehmen die Umsetzung, ich reviewe. Aber der eigentliche Wert liegt nicht darin, wo wir selbst stehen. Er liegt im praxiserprobten Wissen über die Übergänge — und darin, Teams auf ihrem jeweiligen Level gezielt befähigen zu können.

Aber der Weg dahin war nicht das, was man auf einer Konferenzfolie zeigt. Wir haben Workflows dreimal umgebaut, bevor etwas hängengeblieben ist. Es gab Wochen, in denen wir mit dem alten Ansatz schneller gewesen wären. Drei Umbauten. Drei Mal "das funktioniert so nicht." Das war unsere J-Kurve.

Wir hatten den Vorteil, sie als kleines Team durchlaufen zu können — mit kurzen Entscheidungswegen und der Freiheit, zwei Wochen langsamer zu sein, ohne dass jemand den ROI-Report auf den Tisch legt. Diesen Luxus haben größere Organisationen nicht. Mehr Abstimmungsbedarf, Quartalsplanung, Budgetzyklen, Reporting-Strukturen — das System erzeugt Trägheit, nicht die Menschen darin. Ein 20-köpfiges Entwicklungsteam kann sich nicht einfach zwei Wochen freischaufeln, um von Level 2 auf Level 3 zu wechseln. Zumindest nicht ohne Plan, ohne Rückendeckung und ohne eine realistische Vorstellung davon, wie die J-Kurve für ihre spezifische Situation aussieht.

Wir experimentieren auf uns selbst, damit wir Teams dort abholen können, wo sie stehen. Das heißt nicht "kopiert unser Setup." Es heißt: Wir kennen den Weg, wir kennen die Stellen, an denen es wehtut, und wir können helfen, den Abstieg in die J-Kurve so zu planen, dass er überlebbar ist.

Die Lücke ist nicht technologisch. Sie ist organisatorisch. Und sie lässt sich schließen — mit bewussten Entscheidungen, realistischen Zeitplänen und der Bereitschaft, durch den Boden der J-Kurve zu gehen statt davor stehenzubleiben.

Was das für Engineering-Führungskräfte im DACH-Raum bedeutet

Wenn du als CTO, VP Engineering oder Head of Development gerade merkst, dass sich die AI-Investition noch nicht so auszahlt wie erhofft — hier ist, was mir in meiner eigenen Erfahrung und in der Arbeit mit Kunden geholfen hat.

1. Die J-Kurve ist real — und das ist okay

Die Phase der geringeren Produktivität ist kein Zeichen, dass AI-Tools nicht funktionieren. Sie ist ein notwendiger Durchgang. Wenn dein Team Copilot seit sechs Monaten nutzt und die Metriken sich kaum verändert haben, ist das genau das, was Brynjolfsson vorhergesagt hat. Die Frage ist nicht "warum wirkt das nicht?" sondern "welche komplementären Investitionen würden den Durchbruch ermöglichen?"

2. Miss, was tatsächlich passiert

Die METR-Studie hat gezeigt, dass Entwickler ihren eigenen AI-Produktivitätsgewinn um fast 40 Prozentpunkte überschätzen. Das ist keine Kritik an Entwicklern — es ist ein grundlegendes Messproblem. Ohne harte Daten gibt es kein valides Bild.

Cycle Time, Deployment Frequency, Change Failure Rate — die DORA-Metriken sind ein guter Anfang. Aber: vorher und nachher messen. Nur die Nachher-Messung ist wertlos, weil die Baseline fehlt.

3. Trenne Tool-Adoption von Workflow-Transformation

Copilot-Lizenzen kaufen ist Tool-Adoption. Den Entwicklungsprozess so umbauen, dass AI-Agents selbständig Specs umsetzen können, ist Workflow-Transformation. Die Feldstudien zeigen den Unterschied: ~14% Produktivitätsgewinn durch Assistenz-Layering (Brynjolfsson et al.), über 25% durch tiefe Workflow-Integration (Dell'Acqua et al.) — und McKinsey misst 15 Prozentpunkte Leistungsunterschied zwischen den effektivsten und den am wenigsten effektiven Softwareorganisationen.

Konkret heißt das: Nicht nur in Lizenzen investieren, sondern in Spec-Writing-Fähigkeiten, in Code-Review-Kompetenz für AI-generierten Code, in Prompt-Engineering als Kernkompetenz, in die Dokumentation, die AI-Agents brauchen, um autonom arbeiten zu können.

4. Starte mit einem Pilotprojekt, nicht mit einem Rollout

Ein Team, ein Projekt, ein Workflow. Die Freiheit (und die Zeit), von Level 2 auf Level 3 zu wechseln. Experimentieren, scheitern, lernen. Dokumentieren, was passiert. Und dann skalieren basierend auf den eigenen Daten, nicht auf Anbieter-Versprechen.

5. Plan für den Rollenwandel

Der Weg von Level 2 zu Level 4 verändert, was ein "Entwickler" tut. Weniger Code schreiben, mehr Specs schreiben. Weniger implementieren, mehr reviewen. Weniger Individual Contributor, mehr Product-Manager-artig. Das ist nicht für jeden etwas — und das ist okay. Manche Entwickler werden in der neuen Rolle aufblühen. Andere werden Support brauchen. Das gehört eingeplant.

Nächste konkrete Schritte

• Diese Woche: Frag dein Team, auf welchem Shapiro-Level sie sich sehen. Dann vergleiche die Selbsteinschätzung mit dem, was die Metriken sagen. Die Differenz ist aufschlussreich.
• Diesen Monat: Identifiziere einen Workflow, der sich für ein Level-3-Experiment eignet. Bestandscode mit guter Testabdeckung ist ideal — man sieht schnell, ob der AI-generierte Code die Tests besteht.
• Dieses Quartal: Investiere in Enablement statt in weitere Tool-Lizenzen. Spec-Writing-Workshops. Code-Review-Trainings für AI-generierten Code. Dokumentationsstandards für AI-lesbare Codebases. Das sind die komplementären Investitionen, die den Durchbruch durch die J-Kurve ermöglichen.

Das ist Teil 1 einer dreiteiligen Serie über die "Dark Factory Gap" in der Softwareentwicklung. In Teil 2 tauchen wir in die konkreten Architektur-Patterns ein, die Level 4 und 5 möglich machen — von Spec-Driven Development über Digital Twins bis zur Frage, wie StrongDM mit drei Markdown-Dateien ein Multi-Language-Projekt steuert.

Ressourcen

• Dan Shapiro — The Five Levels: from Spicy Autocomplete to the Software Factory
• METR 2025 RCT — Measuring the Impact of AI Tools on Developer Productivity (arXiv:2507.09089)
• Peng et al. — The Impact of AI on Developer Productivity (arXiv:2302.06590)
• Erik Brynjolfsson — The Productivity J-Curve (American Economic Journal: Macroeconomics, 2021)
• Brynjolfsson/Li/Raymond — Generative AI at Work (NBER Working Paper 31161, 2023)
• Dell'Acqua et al. — Navigating the Jagged Technological Frontier (HBS Working Paper 24-013, 2023)
• McKinsey Nov 2025 — AI in Software Development Survey
• Ethan Mollick — One Useful Thing (qualitative Einordnung, Wharton)
• Stack Overflow Developer Survey 2025
• Sonar 2026 — AI Code Quality Report
• StrongDM Attractor — Open Source Spec-Driven Agent
• NHTSA Automated Vehicles Policy (2013)
• SAE J3016 — Levels of Driving Automation (Taxonomie)
• Simon Willison on StrongDM Attractor
• Infralovers AI Coding Essentials Training
• Infralovers AI Essentials for Engineers Training