The learning curve

Our position. We plan for the trough instead of expecting to skip it (opens in a new tab). Adoption follows a J-curve: the first sprints are hard, breakeven follows, then speed, and a team that quits in the dip pays the cost without earning the return.

The dip comes from new work arriving before the workflow that absorbs it. Prompting, verification and review all have to be learned, and the payoff shows up only once they are.

Why are developers slower with AI tools at first?

METR found that experienced open-source developers were about 19% slower with early-2025 AI tools in a randomized trial on repositories they knew well. METR presents the result as a snapshot of one setting rather than a universal productivity law (METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (opens in a new tab)). DORA models adoption as a J-curve: performance can dip while teams learn, adapt pipelines, and absorb additional verification work before any benefit appears (The ROI of AI-Assisted Software Development). Broader skills research reports a similar timing problem. The World Economic Forum finds that while about a quarter of learners show progress within weeks, most need several months of sustained practice to reach proficiency in a new skill (WEF – New Economy Skills: Unlocking the Human Advantage (opens in a new tab), December 2025).

Stanford’s large developer study found only a weak correlation between token usage and productivity, and a stronger one with codebase cleanliness (Stanford software engineering productivity research talk (opens in a new tab)). DORA 2025 describes the same dependency at the organizational level: AI amplifies existing strengths and weaknesses (DORA, State of AI-assisted Software Development 2025 (opens in a new tab)). McKinsey’s analysis of nearly 300 public companies lands in the same place from the enterprise side: simply giving developers AI tools does not move the needle, and the roughly one-in-five top performers who do see gains, 16 to 30 percent on productivity and time to market and 31 to 45 percent on software quality, are the ones who rearchitected how they build and embedded AI across the whole lifecycle rather than bolting it onto coding (McKinsey – The AI Revolution in Software Development (opens in a new tab)).

Reading the gain correctly is its own trap. An account of Zalando’s experience notes that AI tools cluster at the top of the development funnel, writing code, while the downstream work of review, testing, operations, and maintenance stays a human bottleneck, so a team that measures how productive a coder feels rather than what the whole organization ships will misread its own progress (The State of GenAI and Machine Learning in 2025 (opens in a new tab), 3 June 2025). Anthropic’s own research points the same way: the gain shows up less as time saved per task than as a larger rise in output volume, more features shipped, more bugs fixed, more experiments run, with about 27% of AI-assisted work being tasks that would not have been done at all otherwise (2026 Agentic Coding Trends Report).

A large MIT study puts the same asymmetry in numbers: across more than 100,000 developers the coding agents it studied raised how much code got written by roughly 180% but how much actually shipped by only about 30%, because writing got cheap while the rest still runs through a person (The Untrainable (opens in a new tab), 10 June 2026).

The same distortion shows up in enterprise metrics. Bloomberg’s head of technology infrastructure, responsible for roughly 9,000 engineers, reports that measured gains dropped “actually pretty quickly” once teams moved beyond greenfield work into large existing codebases (Bloomberg talk – AI adoption at Bloomberg (opens in a new tab), 16 December 2025). A practitioner account of adopting coding agents on a real INNOQ project describes the individual version of the curve: at the very start you are faster doing it by hand, and the payoff arrives only after the workflow is built (Vom Coder zum Dirigenten (opens in a new tab), 2 December 2025). The headline code-share number oversells the time saved for the same reason: as one engineering panel put it, writing ninety-plus percent of your code with AI does not save ninety percent of your time, because you still have to understand all of it (The AI-ready stack panel (opens in a new tab), 26 June 2025).

A beginner asked to prove the tools are worth it should know the ways that proof usually goes wrong. One post catalogues twelve, and most are not about AI at all but about method: lines of code measures verbosity, not productivity, and deleting two thousand tangled lines for two hundred clean ones looks like a loss on it; self-reported “I feel more productive” is warped by the Hawthorne effect, the novelty effect that fades in weeks, and social-desirability bias toward the tool management chose; commit and pull-request counts fall to the metric-targeting failure the moment they become targets; adoption rate is a procurement outcome, not a productivity one; comparing volunteers to non-volunteers measures the person, not the tool; and measuring the individual instead of the system misses that faster code generation can worsen cycle time when review capacity does not keep up (Twelve Ways to Be Wrong About AI-Assisted Coding (opens in a new tab), 20 May 2026).

The same post sets the METR trial against the error of timing an artificial task: the widely cited 55% speed-up came from developers building an HTTP server from scratch in ninety minutes, while METR’s trial on real work found developers 19% slower. It also cites studies of real projects over time. A difference-in-differences study of 806 open-source repositories adopting Cursor, against a matched control group, found a large but transient velocity gain alongside a persistent rise in code complexity and static-analysis warnings (Speed at the Cost of Quality: How Cursor AI Increases Short-Term Velocity and Long-Term Complexity in Open-Source Projects (opens in a new tab), MSR 2026). A study of open-source projects after GitHub Copilot’s introduction found that core developers reviewed 6.5% more code and their own original code productivity dropped 19% (AI-Assisted Programming Decreases the Productivity of Experienced Developers by Increasing the Technical Debt and Maintenance Burden (opens in a new tab), 2025). The lesson for enablement is to measure over months, against a control, at the level of the system, or not to bother claiming a number at all.

Once the curve is climbed, the payoff shows up in adoption data. DX’s Q1 2026 benchmark across 400+ companies found junior engineers overtaking staff-plus engineers in daily time savings for the first time, driven by consistent high-frequency usage, and time-to-tenth-PR for new hires down to 33 days, more than halved (DX Q1 2026 AI-Assisted Engineering Impact Report). Anthropic’s trends report frames the same effect at the codebase level: onboarding to an unfamiliar codebase is collapsing from weeks to hours, because agents provide contextual code understanding on demand (2026 Agentic Coding Trends Report).

Anthropic’s account of its own teams shows the mechanism concretely: new hires feed Claude Code the whole codebase, it reads the CLAUDE.md files and explains the pipeline dependencies, and it becomes the “first stop” that identifies which files a bug or feature touches, so the same tool that speeds a veteran is what a newcomer uses to build the mental model, and the boundary between technical and non-technical work dissolves as lawyers and marketers build their own tools by describing the problem (How Anthropic teams use Claude Code (opens in a new tab), 24 July 2025, vendor). The teams that get the most from it treat the agent as a thought partner rather than a code generator, Anthropic reports.

Where does each stage of the learning curve stall?

The continuous delivery community describes the climb as six stages, each with its own bottleneck. Inline autocomplete stalls because the model guesses intent from the surrounding code. Single prompts for one function stall on manual integration, and many developers quit there. Multi-turn chat stalls when the conversation grows long and the context degrades. An agent that edits many files stalls on vague requirements, so the reviewer has to reconstruct intent from the diff. Writing a specification first, with tests before code, moves the bottleneck to human review throughput. Only the last stage, specialized agents for coding, testing and review under an orchestrator, takes review off the human path (MinimumCD.org and DojoConsortium.org - The Agentic Development Learning Curve (opens in a new tab), as of March 2026).

The same guide reads the common plateau at the first two stages as a gap in exposure rather than in capability. Most developers have never watched the later stages work, so they conclude the tools have a low ceiling. Skipping a stage backfires: an agent that produces changes faster than anyone writes specifications makes things worse than working by hand. Its advice per stage is concrete. Someone at autocomplete or single prompts should get hands-on time with an agent that navigates many files. Someone at chat or agent tasks should write a short informal specification of intent, one behavior scenario and the constraints before each request. Someone already working spec-first should watch the review queue and add reviewer agents once changes pile up faster than people can review them (MinimumCD.org and DojoConsortium.org - The Agentic Development Learning Curve (opens in a new tab), as of March 2026).

The skills a developer needs climb a parallel ladder of four disciplines, according to a companion page of the same guide. Prompt craft, clear instructions with an explicit output format, is the baseline for the first two stages. Context engineering, choosing what information the agent works inside, carries the middle stages. Intent engineering encodes the goals, trade-off priorities and escalation points the agent should act on, and marks the step into spec-first work. Specification engineering writes self-contained problem statements with measurable acceptance criteria, so an agent can run for long stretches without a human correcting its course. The page offers a quick check for any request: rewrite it for a reader with no prior context. If that reader could act on it, an agent can too (MinimumCD.org and DojoConsortium.org - The Four Prompting Disciplines (opens in a new tab), as of September 2026).

Related

• Getting Started and Learning: how to organize the learning that gets a team through the dip.
• Effective beginner practices: the habits that shorten the climb for one person.
• Productivity evidence and quality: what the studies measure once the curve is climbed.
• Measuring impact: how to measure without mistaking activity for outcome.
• AI productivity studies: the METR, Stanford, DORA and Multitudes results in detail.

Resources

Learning paths

• The Agentic Development Learning Curve (opens in a new tab) - Community guide mapping six stages of agentic development, the bottleneck at each and the move to the next, CC BY 4.0.
• The Four Prompting Disciplines (opens in a new tab) - Community guide ranking prompt, context, intent and specification engineering as successive skills tied to the learning-curve stages, CC BY 4.0.