Is AI coding on average 17.3x faster or 1.3x faster? Both. — LinkedIn post by Fabrice Bernhard

Fabrice Bernhard · article · 2026-06-06 Reader 🖥️

Code Was Never the Bottleneck Coding Agents Lean & Toyota Way Legacy & Organizational Forgetting Measuring AI Impact Trunk-Based & Continuous Delivery Value Streams & Verticals

The headline 17.3x speedup that AI async agents produce at the start of the software value stream collapses to a 1.3x increase in release frequency at the end of the stream — because human and organisational bottlenecks (unclear business needs, organisational dependencies) dominate end-to-end throughput; therefore AI creates real value only when it is targeted at the actual bottleneck, and identifying that bottleneck is what Lean Tech is for.

practical · argumentative — Short LinkedIn post (~250 words) arguing for a specific way of selecting AI-coding R&D targets: pick use cases where AI addresses an actual bottleneck. Uses an empirical paper (Demirer/Musolff/Yang, MIT & UPenn) as the wedge, then layers in Theodo's own measured result (legacy modernisation 3x faster) and Lean framing. The aim is prescriptive: change how leaders evaluate AI investment.

Structure

Part	Role
Provocation: 17.3x or 1.3x? Both.	hook / framing
Statement of which number matters: only 1.3x	thesis statement
Reference to Demirer/Musolff/Yang (MIT & UPenn) value-stream study	evidence / authority
Theodo's 14 years of Lean-to-tech experience as confirmation	practitioner endorsement
Diagnosis: human bottlenecks AI cannot address (unclear business needs, organisational dependencies)	mechanism
Theodo's R&D focus: legacy software modernisation — a real bottleneck	prescriptive example
Result claim: 3x faster legacy modernisation	evidence / proof of concept
Meta-claim: experimenting where value can be measured generates better learnings	second-order argument
Closing: AI creates real value only when it accelerates the bottleneck — that's Lean Tech	restatement / call to action

Key terms

Value stream Value Streams & Verticals
The end-to-end sequence of steps from a customer need to a released product/service — Bernhard uses it to distinguish between speeding up an early step (writing lines of code) and speeding up the whole stream (releases per unit time)
Bottleneck Code Was Never the Bottleneck
The step in the value stream that constrains end-to-end throughput; Bernhard's claim is that the bottleneck in most software projects is NOT code production but upstream/downstream human and organisational activities
Async agents Coding Agents
AI agents that 'operate autonomously until a task is completed' (e.g. GitHub Agent / Copilot-style background coding agents) — distinguished from sync agents (Claude Code-style local-pair) and autocomplete
Lean Tech Lean & Toyota Way
Theodo's house framework — applying Lean principles (value, flow, bottleneck identification, learning loops) to software engineering; the title of Bernhard's 2022 book co-authored with Benoît Hardy-Vallée
Release frequency Trunk-Based & Continuous Delivery
How often shipped value reaches the customer — DORA metric Bernhard treats as the canonical end-of-stream measure of AI's actual impact
Legacy modernisation Legacy & Organizational Forgetting
Updating older codebases to modern stacks/architectures — Theodo's chosen R&D target because here AI addresses a genuine bottleneck (human comprehension of unfamiliar code, translation cost)
Lines of code (as throughput proxy) Code Was Never the Bottleneck
What AI accelerates at the input end — explicitly NOT the same as customer value; Bernhard treats this as a misleading metric when used alone

Propositions

explicitAsync AI agents write lines of code 17.3x faster than baseline.conf: high
explicitRelease frequency is only up by 1.3x when teams adopt the same tools.conf: high
supportsThe Organization Is the Bottleneck · p1 — The MIT/UPenn 17.3x lines-of-code vs 1.3x release-frequency gap is direct empirical evidence that faster code writing does not translate to faster organizational value delivery.
explicitcontestedThe only number that matters is 1.3x — because customer value lives at the end of the value stream, not the beginning.conf: high
contradictsSkill Issue: Andrej Karpathy on Code Agents, AutoResearch, and the Loopy Era of AI · p3 — The binding constraint is not token throughput but downstream value-stream bottlenecks: 17.3x faster code yields only 1.3x more releases.
explicitThere are human bottlenecks AI cannot address — specifically unclear business needs and organisational dependencies.conf: high
explicitWhere AI does not address the bottleneck, faster code writing will not have a significant impact on delivered value.conf: high
explicitTheodo successfully modernises legacy software 3x faster using AI.conf: medium
explicitChoosing to experiment in contexts where real value can be measured produces better learnings — including productive failures.conf: high
explicitAI creates real value only when it accelerates the bottleneck.conf: high
explicitUnderstanding where the bottlenecks are is what Lean Tech is about.conf: high
implicitcorroboratedLegacy modernisation IS a real bottleneck for many software organisations.conf: medium
supports ←Case Study: Refactoring at Scale with Agents · p2 — Empirically demonstrates, at real scale with real numbers, that legacy modernization is a tractable, worthwhile target — corroborating that it's a genuine bottleneck-aligned use case rather than an aspirational one.
extends ←How AI will change software engineering – with Martin Fowler · p5 — Bernhard's claim that legacy modernization is a real bottleneck is nuanced here: understanding legacy code with LLMs is a mature success (ThoughtWorks Radar 'Adopt' ring), but safely modifying it remains unresolved — splitting the bottleneck into a solved and an unsolved half.
implicitcorroboratedMost current AI coding adoption is targeted at the wrong place in the value stream — at code production, not at the actual bottleneck.conf: high
supports ←State Of AI-Assisted Software Development · p11 — DORA's Theory-of-Constraints argument (downstream capacity absorbs upstream AI gains) gives the empirical/theoretical mechanism behind Bernhard's claim that AI coding adoption targets the wrong point in the value stream.
explicitTheodo's 14 years of Lean-to-tech practice gave them a pre-existing frame that made the MIT/UPenn finding unsurprising.conf: high
explicitAsync agents can fully replace human developers on certain (well-bounded) tasks.conf: high
refinesPresentation: Leadership in AI-Assisted Engineering · p5 — Bernhard narrows the replacement question: agents already fully replace developers on well-bounded tasks, even if wholesale engineer replacement may never come.

Arguments

The 17.3x productivity number for AI coding is real but misleading; the 1.3x release-frequency number is the one leaders should plan against. strength: high

Explicit premises:

Demirer/Musolff/Yang measured 17.3x faster lines-of-code at the start of the value stream.
The same study measured only 1.3x release frequency at the end of the value stream.
Customer value is denominated in shipped products/services, not lines of code.

Implicit premises:

Release frequency is a valid proxy for delivered customer value (or at least more valid than lines of code).
The 17.3x / 1.3x gap is general, not an artefact of the specific dataset or tooling generation studied.
The MIT/UPenn methodology is sound enough to take as a planning input.

Inferences:

Productivity dashboards denominated in code-generation speed will systematically overstate AI's delivered impact.
AI investment decisions should be made against end-of-stream metrics.

AI creates real value only when targeted at the actual bottleneck of the value stream. strength: medium

Explicit premises:

The 17.3x → 1.3x collapse shows non-bottleneck acceleration doesn't propagate.
Human bottlenecks (unclear business needs, organisational dependencies) dominate end-to-end throughput in many software projects.
Theodo's bottleneck-targeted bet (legacy modernisation) delivered measurable 3x end-to-end speedup.

Implicit premises:

Theory of Constraints applies to software value streams (every system has a single dominant bottleneck and accelerating non-bottlenecks is wasted work).
Bottlenecks can be reliably identified in advance — Lean Tech provides the diagnostic capability.
Theodo's success with legacy modernisation generalises from consultancy practice to enterprise in-house engineering.

Inferences:

Leaders should run a value-stream diagnosis BEFORE selecting AI-coding pilots.
Generic 'roll out Copilot to all developers' programs are likely to land on the 1.3x side rather than the 3x side.
Concentrated R&D in bottleneck-aligned AI use cases beats broad-spectrum adoption.

Experimenting where you can measure real value produces compounding organisational learning, including from failures. strength: medium

Explicit premises:

Theodo's R&D is run in a context where value can be measured (legacy modernisation has clear before/after performance and cost data).
Some experiments improve outcomes and some don't — but all of them generate transferable learnings.
These learnings are shared across the organisation.

Implicit premises:

Measurable-value contexts produce learnings of higher quality than measurable-output contexts.
Theodo has organisational mechanisms (internal communities, write-ups) that actually transfer the learnings — this is asserted not shown.

Inferences:

Organisations whose AI experiments are run in poorly-measurable contexts will accumulate weaker learning over time, compounding the gap.
The choice of where to experiment is itself a strategic decision, not a tactical one.

Narratives

Theodo's 14-year Lean-Tech journey — the firm has been applying Lean principles to software for over a decade, so the MIT/UPenn finding was 'no surprise'.
→ Establishes authority and a long-running practice tradition; positions Bernhard as a practitioner-interpreter of an academic finding rather than a hot-take poster.
Theodo's bottleneck-targeted R&D on legacy modernisation — they consciously chose this domain because it is a real bottleneck, and now ship modernisations 3x faster.
→ Acts as the proof-of-concept demonstration; turns an abstract Lean prescription into a concrete operational bet with a measured payoff.
The Demirer/Musolff/Yang study (MIT & UPenn) — academic researchers measured AI's impact across the value stream and found 17.3x at the start, 1.3x at the end.
→ External empirical authority that grounds Bernhard's argument in something other than Theodo's own self-report; the figure caption distinguishes autocomplete / sync / async agents which lets Bernhard pin the 17.3x to async specifically.

Questions addressed

✅ Are headline AI productivity numbers (multiples of speedup) real?
Yes — async agents really do write code 17.3x faster. But the number is real and irrelevant if the customer-side metric (release frequency) only moves 1.3x.
✅ Where should leaders target AI investment in the value stream?
At the actual bottleneck. For Theodo that meant legacy modernisation; for other organisations the diagnosis must be run locally.
✅ What kinds of bottlenecks can AI NOT address?
Unclear business needs and organisational dependencies — the human/organisational side of the value stream.
⭕ Is release frequency the right end-of-stream measure?
Bernhard treats it as the proxy for 'end value' but doesn't engage with the obvious alternatives (cycle time, quality, defect rate, customer outcomes, business impact). For a Lean Tech argument this is conspicuous.
⭕ How do you actually diagnose where the bottleneck is?
Asserted as 'what Lean Tech is about' but no method, heuristic, or worked example is provided in the post. Presumably handled in the book.
⭕ Does Theodo's consultancy experience generalise to in-house enterprise teams?
Not addressed. The 3x legacy modernisation claim is from Theodo's own client engagements — whether the same gains accrue to in-house teams modernising their own systems is unargued.
⭕ What about quality, defect rate, and downstream cost of AI-accelerated code?
Entirely absent. The argument is denominated in throughput (release frequency). The whole 'AI may speed up writing while degrading what gets written' debate is not engaged.

Gaps

incompleteThe post claims release frequency is 'the only number that matters' but doesn't argue why — and Lean's own toolkit would suggest cycle time, quality, and customer outcomes belong alongside release frequency. The reduction of 'real value' to a single metric is rhetorically clean but theoretically thin.
Read next: DORA's four-key-metrics literature; Reinertsen on cost of delay; Steve Yegge / Gene Kim on quality-vs-speed under AI; Beck's recent newsletters on what to measure when AI changes throughput.
incompleteTheodo's consultancy context is a selection bias engine that Bernhard doesn't address. Consultants typically work on greenfield engagements or on well-bounded modernisation projects where business needs are pre-scoped by a client brief. The very bottlenecks Bernhard names (unclear business needs, organisational dependencies) are precisely the bottlenecks consultancy contracts pre-filter for. Whether the 3x result transfers to in-house teams operating in the muck is the load-bearing open question.
Read next: Compare to Anthropic enterprise PDF findings on in-house deployments; Cutler on internal-team organisational drag; case studies of in-house legacy modernisation at scale (e.g. NAV, Entur reports already in corpus).
incompleteLegacy modernisation is presented as 'a' bottleneck-aligned use case but Bernhard doesn't enumerate what makes it bottleneck-aligned and what other use cases would qualify. A more complete argument would name the properties (translation-heavy, human-comprehension-bound, well-specified target, measurable acceptance criteria) that make AI bottleneck-effective.
Read next: Mary Poppendieck on Lean software value-stream mapping; Theory-of-Constraints applied software literature; specific case studies of AI-driven greenfield vs migration projects.
incompleteThe post takes the MIT/UPenn paper as authoritative but doesn't disclose the dataset, sample, or timeframe. Async agents in 2024-25 (the likely study window) are not the same product category as 2026 long-running harnesses — the 1.3x number may understate what later-generation tooling can do at the release-frequency end, OR may be optimistic if the study captured the early enthusiasm phase.
Read next: The Demirer/Musolff/Yang paper itself; recent METR / RCT-style AI productivity studies; Pocock workshop on what changes with harness-level tooling.
incompleteNo engagement with the second-order Lean question: if AI accelerates non-bottleneck steps, does it just inflate WIP upstream of the bottleneck (and make things worse), or does it free human capacity to attack the bottleneck (improving things even when not bottleneck-targeted)? Classical Lean would predict the former; Bernhard's framing implies the former but doesn't say so.
Read next: Reinertsen Principles of Product Development Flow; Donald Wheeler on understanding variation; recent Cutler pieces on AI-induced overload and WIP inflation in AI-augmented teams.
closed byWriting Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools — Gives a direct empirical/causal answer to this exact Lean question for software specifically: AI's upstream code-writing gains are real and large (up to 741% more lines), but they are largely absorbed as additional work passing through the fixed-capacity review/integration bottleneck rather than converted into proportional shipped output (only 20% more releases) — closer to classical Lean's 'inflates WIP upstream' prediction than to 'frees capacity to attack the bottleneck,' with an estimated elasticity of substitution of just 0.25 indicating strong complementarity and weak pass-through.
incompleteThe 'we generate better learnings' claim is asserted without describing Theodo's actual learning mechanisms — internal write-ups, retros, replication across client engagements, etc. For an audience interested in adopting the approach, the learning infrastructure is the load-bearing part.
Read next: Theodo's engineering blog (theodo.com / padok.fr); Mike Rother's Toyota Kata on learning routines; A3 thinking literature.
uninformedThe post predates / doesn't engage with the harness-engineering thread that this corpus has been tracking (Anthropic harness paper, Pocock workshop, Cloudflare Mythos). Harness-level tooling specifically aims at the integration between code generation and release — exactly the gap Bernhard names. Whether harness engineering is a third path (between 'roll out Copilot' and 'consultancy-led bottleneck targeting') is an obvious adjacency.
Read next: Pocock workshop extraction; Anthropic harness design paper; Cloudflare Mythos extraction; the Anthropic enterprise PDF extraction.

Closes gaps elsewhere

With Android CLI, Google is Making the Android Toolchain Agent-Friendly · g4 — Confirms the theory-of-constraints worry with data: code generation is 17.3x faster but releases only 1.3x more frequent, so optimizing generation speed targets a non-bottleneck step.
Measuring AI impact, assessing readiness, and new data trends · g5 — The 17.3x lines-written vs 1.3x releases divergence is direct evidence that code/PR throughput is a poor proxy for delivered value; Bernhard argues the outcome metric must sit at the end of the value stream (p3).
Elizabeth Ayer on Mastodon — "The fact that we are *not* seeing wildly improving software all around us tells us everything we need to know" · g1 — Names the actual bottlenecks Ayer leaves unidentified: unclear business needs and organisational dependencies, which AI-accelerated code production cannot address (p4, p8).

Is AI coding on average 17.3x faster or 1.3x faster? Both. — LinkedIn post by Fabrice Bernhard

Structure

Key terms

Propositions

Arguments

Narratives

Questions addressed

Gaps

Closes gaps elsewhere

Related documents