Die Lernkurve

Unsere Position. Wir planen das Tal ein, statt zu hoffen, es zu überspringen (öffnet in einem neuen Tab). Die Einführung folgt einer J-Kurve. Die ersten Sprints sind hart, dann kommt der Breakeven, danach die Geschwindigkeit. Ein Team, das im Tal aufgibt, trägt die Kosten und verpasst den Ertrag.

Das Tal entsteht, weil neue Arbeit früher ankommt als der Workflow, der sie auffängt. Prompting, Verifikation und Review müssen alle erst gelernt werden. Der Nutzen zeigt sich erst, wenn das geschafft ist.

Warum sind Entwickler:innen mit KI-Tools anfangs langsamer?

METR hat erfahrene Open-Source-Entwickler:innen in einer randomisierten Studie auf Repositories getestet, die sie gut kannten. Mit KI-Tools von Anfang 2025 waren sie etwa 19 % langsamer. METR versteht das Ergebnis als Momentaufnahme eines Settings, nicht als allgemeines Gesetz der Produktivität (METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (öffnet in einem neuen Tab)).

DORA modelliert die Einführung als J-Kurve. Die Leistung kann sinken, solange Teams lernen, Pipelines anpassen und zusätzliche Verifikationsarbeit auffangen. Erst danach zeigt sich ein Nutzen (The ROI of AI-Assisted Software Development). Breitere Forschung zu Skills meldet ein ähnliches Timing-Problem. Laut World Economic Forum zeigt etwa ein Viertel der Lernenden innerhalb von Wochen Fortschritte. Die meisten brauchen aber mehrere Monate kontinuierlicher Übung, bis sie eine neue Fähigkeit sicher beherrschen (WEF, New Economy Skills: Unlocking the Human Advantage (öffnet in einem neuen Tab), Dezember 2025).

Die große Entwickler:innen-Studie aus Stanford fand nur eine schwache Korrelation zwischen Token-Verbrauch und Produktivität. Stärker hing die Produktivität mit der Sauberkeit der Codebasis zusammen (Talk zur Stanford-Forschung über Produktivität (öffnet in einem neuen Tab)). DORA 2025 beschreibt dieselbe Abhängigkeit auf Ebene der Organisation: KI verstärkt vorhandene Stärken und Schwächen (DORA, State of AI-assisted Software Development 2025 (öffnet in einem neuen Tab)).

McKinseys Analyse von fast 300 börsennotierten Unternehmen kommt aus Sicht der Konzerne zum selben Schluss. Entwickler:innen einfach KI-Tools in die Hand zu geben, bewegt nichts. Die Top Performer, rund ein Fünftel der Unternehmen, erzielen Gewinne. Sie erreichen 16 bis 30 Prozent bei Produktivität und Time to Market und 31 bis 45 Prozent bei der Softwarequalität. Diese Unternehmen haben umgebaut, wie sie Software bauen. Sie verankern KI im gesamten Lebenszyklus, statt sie nur ans Coding anzuschrauben (McKinsey, The AI Revolution in Software Development (öffnet in einem neuen Tab)).

Auch wer den Gewinn bewertet, tappt leicht in eine Falle. Ein Bericht über die Erfahrungen bei Zalando beobachtet, dass sich KI-Tools oben im Entwicklungstrichter ballen, beim Schreiben von Code. Review, Testing, Betrieb und Wartung weiter unten bleiben ein menschlicher Bottleneck. Ein Team, das misst, wie produktiv sich Einzelne beim Coden fühlen, statt was die ganze Organisation ausliefert, deutet den eigenen Fortschritt falsch (The State of GenAI and Machine Learning in 2025 (öffnet in einem neuen Tab), 3. Juni 2025). Anthropics eigene Forschung zeigt in dieselbe Richtung. Der Gewinn erscheint weniger als gesparte Zeit pro Aufgabe, eher als größerer Anstieg der Output-Menge. Es werden mehr Features ausgeliefert, mehr Bugs behoben und mehr Experimente gefahren. Etwa 27 % der KI-gestützten Arbeit sind Aufgaben, die sonst gar nicht erledigt worden wären (2026 Agentic Coding Trends Report).

Eine große MIT-Studie beziffert dieselbe Asymmetrie. Bei mehr als 100.000 Entwickler:innen steigerten die untersuchten Coding-Agents die Menge geschriebenen Codes um rund 180 %. Die Menge tatsächlich ausgelieferten Codes stieg nur um etwa 30 %. Das Schreiben wurde billig, der Rest läuft weiter über einen Menschen (The Untrainable (öffnet in einem neuen Tab), 10. Juni 2026).

Dieselbe Verzerrung zeigt sich in den Kennzahlen großer Unternehmen. Bei Bloomberg verantwortet der Head of Technology Infrastructure rund 9.000 Engineers. Laut diesem Bericht sanken die gemessenen Gewinne “actually pretty quickly”, sobald Teams von Greenfield-Arbeit in große bestehende Codebasen wechselten (Bloomberg-Talk, AI adoption at Bloomberg (öffnet in einem neuen Tab), 16. Dezember 2025). Ein Erfahrungsbericht aus einem echten INNOQ-Projekt mit Coding-Agents beschreibt die Kurve für Einzelne. Ganz am Anfang seid ihr von Hand schneller, der Nutzen kommt erst, wenn der Workflow steht (Vom Coder zum Dirigenten (öffnet in einem neuen Tab), 2. Dezember 2025). Aus demselben Grund überzeichnet die Schlagzeile zum Code-Anteil die gesparte Zeit. Ein Engineering-Panel hat es so formuliert: Schreibt ihr über neunzig Prozent eures Codes mit KI, spart ihr nicht neunzig Prozent eurer Zeit. Verstehen müsst ihr den ganzen Code trotzdem (The AI-ready stack panel (öffnet in einem neuen Tab), 26. Juni 2025).

Wer als Einsteiger:in beweisen soll, dass sich die Tools lohnen, sollte wissen, woran solche Belege meist scheitern. Ein Post katalogisiert zwölf Fehler, und die meisten handeln gar nicht von KI. Sie handeln von Methode (Twelve Ways to Be Wrong About AI-Assisted Coding (öffnet in einem neuen Tab), 20. Mai 2026).

• Lines of Code messen Ausführlichkeit, keine Produktivität. Wer zweitausend verknotete Zeilen durch zweihundert saubere ersetzt, steht in dieser Kennzahl mit einem Verlust da.
• Die Selbstauskunft “I feel more productive” verzerrt der Hawthorne-Effekt, dazu der Neuheitseffekt, der nach Wochen verblasst. Hinzu kommt soziale Erwünschtheit zugunsten des Tools, das das Management gewählt hat.
• Zahlen zu Commits und Pull Requests kippen, sobald sie zum Ziel werden, weil dann auf die Kennzahl hin optimiert wird.
• Die Adoptionsrate ist ein Ergebnis des Einkaufs, kein Ergebnis der Produktivität.
• Wer Freiwillige mit Nicht-Freiwilligen vergleicht, misst die Person und nicht das Tool.
• Wer Einzelne statt des Systems misst, übersieht einen Effekt. Schnellere Codegenerierung kann die Cycle Time verschlechtern, wenn die Review-Kapazität nicht mithält.

Derselbe Post stellt die METR-Studie dem Fehler gegenüber, eine künstliche Aufgabe mit der Stoppuhr zu messen. Die viel zitierten 55 % Beschleunigung stammen von Entwickler:innen, die in neunzig Minuten einen HTTP-Server von Grund auf bauten. METRs Studie mit echter Arbeit fand sie dagegen 19 % langsamer. Außerdem zitiert er Studien zu echten Projekten über längere Zeit. Eine Difference-in-Differences-Studie verglich 806 Open-Source-Repositories, die Cursor eingeführt hatten, mit einer passenden Kontrollgruppe. Sie fand einen großen, aber vorübergehenden Zuwachs an Velocity. Gleichzeitig stiegen Code-Komplexität und Warnungen der statischen Analyse dauerhaft (Speed at the Cost of Quality: How Cursor AI Increases Short-Term Velocity and Long-Term Complexity in Open-Source Projects (öffnet in einem neuen Tab), MSR 2026). Eine Studie zu Open-Source-Projekten nach der Einführung von GitHub Copilot fand, dass die Core-Entwickler:innen 6,5 % mehr Code reviewten und ihre eigene originäre Code-Produktivität um 19 % sank (AI-Assisted Programming Decreases the Productivity of Experienced Developers by Increasing the Technical Debt and Maintenance Burden (öffnet in einem neuen Tab), 2025). Für das Enablement heißt das: über Monate messen, gegen eine Kontrollgruppe und auf Ebene des Systems. Sonst lieber gar keine Zahl behaupten.

Ist die Kurve erklommen, zeigt sich der Nutzen in den Adoptionsdaten. Der DX-Benchmark für Q1 2026 umfasst über 400 Unternehmen. Darin überholten Junior Engineers erstmals Staff-plus Engineers bei der täglichen Zeitersparnis, getrieben von konstant häufiger Nutzung. Bei neuen Mitarbeitenden sank die Zeit bis zum zehnten PR auf 33 Tage, weniger als die Hälfte des früheren Werts (DX AI Impact Report). Anthropics Trend-Report beschreibt denselben Effekt auf Ebene der Codebasis. Das Onboarding in eine unbekannte Codebasis schrumpft von Wochen auf Stunden, weil Agents Code bei Bedarf im Kontext erklären (2026 Agentic Coding Trends Report).

Anthropics Bericht über die eigenen Teams zeigt den Mechanismus konkret. Neue Mitarbeitende geben Claude Code die ganze Codebasis. Es liest die CLAUDE.md-Dateien und erklärt die Abhängigkeiten der Pipeline. So wird es zum “first stop”, der zeigt, welche Dateien ein Bug oder ein Feature berührt. Dasselbe Tool, das Erfahrene schneller macht, hilft Neuen beim Aufbau ihres mentalen Modells. Auch die Grenze zwischen technischer und nicht technischer Arbeit löst sich auf. Jurist:innen und Marketer:innen bauen eigene Tools, indem sie das Problem beschreiben (How Anthropic teams use Claude Code (öffnet in einem neuen Tab), 24. Juli 2025, Anbieterquelle). Laut Anthropic holen die Teams am meisten heraus, die den Agent als Denkpartner behandeln statt als Codegenerator.

Woran bleibt jede Stufe der Lernkurve hängen?

Die Continuous-Delivery-Community beschreibt den Aufstieg in sechs Stufen, jede mit eigenem Bottleneck (MinimumCD.org und DojoConsortium.org - The Agentic Development Learning Curve (öffnet in einem neuen Tab), Stand März 2026).

1. Inline-Autocomplete stockt, weil das Modell die Absicht aus dem umgebenden Code erraten muss.
2. Einzelne Prompts für eine Funktion stocken an der manuellen Integration. Hier geben viele Entwickler:innen auf.
3. Multi-Turn-Chat stockt, sobald das Gespräch lang wird und der Kontext nachlässt.
4. Ein Agent, der viele Dateien bearbeitet, stockt an vagen Anforderungen. Wer reviewt, muss die Absicht dann aus dem Diff rekonstruieren.
5. Wer zuerst eine Spec schreibt und Tests vor dem Code, verschiebt den Bottleneck zum Durchsatz menschlicher Reviews.
6. Erst auf der letzten Stufe übernehmen Agents auch das Review. Dort arbeiten spezialisierte Agents für Coding, Testing und Review unter einem Orchestrator.

Derselbe Leitfaden sieht im häufigen Plateau auf den ersten beiden Stufen eine Lücke in der Erfahrung, nicht in der Fähigkeit. Die meisten Entwickler:innen haben die späteren Stufen nie arbeiten sehen. Deshalb halten sie die Obergrenze der Tools für niedrig. Eine Stufe zu überspringen, rächt sich. Ein Agent, der Änderungen schneller produziert, als jemand Specs schreibt, macht die Lage schlimmer als Handarbeit. Die Ratschläge pro Stufe sind konkret (MinimumCD.org und DojoConsortium.org - The Agentic Development Learning Curve (öffnet in einem neuen Tab), Stand März 2026).

• Wer bei Autocomplete oder einzelnen Prompts steht, sollte praktische Zeit mit einem Agent verbringen, der durch viele Dateien navigiert.
• Wer bei Chat oder Agent-Aufgaben steht, sollte vor jeder Anfrage eine kurze, informelle Spec schreiben. Sie hält die Absicht fest, ein Verhaltensszenario und die Constraints.
• Wer schon Spec-first arbeitet, sollte die Review-Queue beobachten. Stauen sich Änderungen schneller, als Menschen sie reviewen können, kommen Reviewer-Agents dazu.

Die nötigen Skills steigen parallel dazu auf einer Leiter aus vier Disziplinen. So beschreibt es eine Begleitseite desselben Leitfadens (MinimumCD.org und DojoConsortium.org - The Four Prompting Disciplines (öffnet in einem neuen Tab), Stand September 2026).

• Prompt Craft, also klare Instruktionen mit explizitem Ausgabeformat, ist die Basis für die ersten beiden Stufen.
• Context Engineering trägt die mittleren Stufen. Es wählt aus, mit welchen Informationen der Agent arbeitet.
• Intent Engineering kodiert die Ziele, die Prioritäten bei Trade-offs und die Eskalationspunkte, nach denen der Agent handeln soll. Es markiert den Schritt zur Spec-first-Arbeit.
• Specification Engineering schreibt in sich geschlossene Problembeschreibungen mit messbaren Akzeptanzkriterien. Damit kann ein Agent lange Strecken laufen, ohne dass ein Mensch den Kurs korrigiert.

Die Seite bietet einen schnellen Test für jede Anfrage. Schreibt sie für jemanden ohne Vorwissen um. Kann diese Person danach handeln, kann es ein Agent auch.

Verwandte Seiten

• Einstieg und Lernen: wie ihr das Lernen organisiert, das ein Team durch das Tal bringt.
• Effektive Praktiken für Einsteiger:innen: die Gewohnheiten, die den Aufstieg für eine Person verkürzen.
• KI-Produktivität: Evidenz und Qualität: was die Studien messen, wenn die Kurve erklommen ist.
• Impact messen: wie ihr messt, ohne Aktivität mit Ergebnis zu verwechseln.
• KI-Produktivitätsstudien: METR, Stanford, DORA, Multitudes: die Ergebnisse von METR, Stanford, DORA und Multitudes im Detail.

Quellen

Lernpfade

• The Agentic Development Learning Curve (öffnet in einem neuen Tab) - Community-Leitfaden zu sechs Stufen agentischer Entwicklung, mit dem Bottleneck jeder Stufe und dem Schritt zur nächsten, CC BY 4.0.
• The Four Prompting Disciplines (öffnet in einem neuen Tab) - Community-Leitfaden, der Prompt, Context, Intent und Specification Engineering als aufeinander folgende Skills einordnet und mit den Stufen der Lernkurve verknüpft, CC BY 4.0.