Lean & Toyota Way

Lean thinking applied to software — value, flow, bottleneck identification and the scientific method as the engine of structured learning.

Also known as: Toyota Way / Lean, Toyota Way, Lean, Lean Tech, vitenskapelig metode (i systemutvikling), vitenskapelig metode, You Burn, I'll Scrape, Quality-enabled speed

How authors use it

Oldest first (extraction date when no publication date is known).

Documents (6)

• Is AI coding on average 17.3x faster or 1.3x faster? Both. — LinkedIn post by Fabrice Bernhard Fabrice Bernhard · 2026-06-06 Reader 🖥️
  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.
• From Async Code Reviews to Co-Creation Patterns Dragan Stepanović (published via Ben Linders / InfoQ) · 2026-06-01 source ↗ Reader 🖥️
  Pull-Request-based async code review forces teams to trade off quality against throughput — small PRs incur exponentially worse wait-time-per-size and large PRs degrade reviewer engagement — and the only way out of the trade-off is to make code review continuous and synchronous via co-creation patterns (Pair and Mob Programming), which drive the transaction cost toward zero and let teams have both throughput and quality.
• 5) Vidar Moe: Det eneste Vidar vil er å ha det lett Truls Jørgensen og Audun Fauchald Strand — Heis Podcast · 2025-11-17 source ↗ Reader 🖥️
  Vidar Moe's core engineering-leadership philosophy is 'gjøre det lett og rett' (make it easy and right) — a Toyota-Way-inflected craft and leadership stance in which you lead an organization most powerfully not by exhortation but by patiently building the tooling, frameworks, fagtid, hiring filters, fixed-term leadership rotation, and shared decision arenas that make the right thing the path of least resistance; the episode's ironic title ('the only thing Vidar wants is to have it easy') inverts this — Moe wants the work to be easy precisely because he is willing to do the very hard, decade-long, mostly invisible work of removing friction from doing the right thing, and his current concern with AI agents is the natural next chapter of the same project.
• Pair Programming Fixed Our Pull Request Bottlenecks Modern Software Engineering (Dave Farley) — clip from The Engineering Room podcast · 2025-07-11 source ↗ Reader 🖥️
  Pair programming did not just make pull-request review faster for this team — it made the pull-request gate itself unnecessary, because the review, the four-eyes compliance requirement, and the knowledge-sharing that PRs exist to provide were already satisfied continuously by working together, which let the team drop branches entirely and move to minutes-long commit-to-production cycles.
• Software Teaming: A Mob Programming, Whole-Team Approach Woody Zuill and Kevin Meadows · 2022-11-04 Reader 🖥️
  A whole team working together, all day, at one computer, on one thing at a time — using a Driver-Navigator discipline and a self-chosen agreement to treat each other with Kindness, Consideration, and Respect — is more effective than the conventional practice of separating specialists, because nearly all of software development's hidden costs (queueing, context-switching, faulty communication, indecision, defects, politics) are side effects of separation that fade away once the whole team works in one continuous flow, rather than problems that must be solved individually.
• Mob Programming – key issues it can solve, benefits, and learnings futurice.com · 2022-08-08 source ↗ Reader 🖥️
  Asynchronous, feature-branch-and-pull-request software development ('soloing') generates Lean process waste — delays, queues, defects, big batches, overproduction, and rework — because it structurally separates writing code from reviewing it; mob programming (the whole team working synchronously on one task at a time) eliminates this waste by collapsing the hand-off entirely, and on one real six-month engagement its benefits (faster flow, continuous review, shared knowledge, trunk-based delivery, psychological safety) outweighed the new problems it introduced (remote-tooling friction, flow-state overwork, loose-specification discomfort).

Propositions touching this concept (21)

By publication month, oldest first (extraction month when no publication date is known).

2022-11

• explicitThe team also achieves 'Lean Flow': work moves from idea to production use with minimal queueing or invisible inventory, because the lean-manufacturing insight that unmanaged queues are product development's hidden, dominant waste (Reinertsen) applies directly to software and is reduced by keeping every needed skill in the room.
  Software Teaming: A Mob Programming, Whole-Team Approach · p8

2025-11

• explicitToyota Way / Lean and the DORA / Accelerate / Team Topologies tradition are the same intellectual lineage — Lean's practices map directly onto modern continuous-delivery metrics.
  5) Vidar Moe: Det eneste Vidar vil er å ha det lett · p15

2026-04

• explicitAnthropic explicitly hires for people who lean into chaos and face every challenge with a smile, because getting too stressed about incidents leads to burnout -- illustrated by weeks where a Sunday P0 escalates to a P00 by Monday and a P000 by Monday afternoon, and the team looks for people who respond with 'I'm excited to tackle it' rather than panic.
  Lenny Rachitsky's Post · p7
• explicitFormal verification in Lean is the most promising path to resolving the ABC conjecture proof controversy.
  The secret project to settle controversial maths proof with a computer · p1
• explicitMochizuki's 70 lines of Lean code represent a negligible fraction of what would be needed to formalise the full proof.
  The secret project to settle controversial maths proof with a computer · p5

2026-05

• explicitFounders can and should treat lean headcount as a permanent operating model, not a bootstrapping constraint.
  The Founder's Playbook: Building An AI-Native Startup · p14
• explicitLLMs have mastered Induction (statistical pattern matching from data) and are rapidly mastering Deduction (formal derivation/proof, e.g. AlphaProof, Lean-based theorem proving), but are structurally incapable of Abduction — the generation of novel explanatory hypotheses or axioms.
  LLMs Can't Jump · p1

2026-06

• explicitTokenization is a hard physical constraint on specification writing: every character, newline, and indentation space in a spec consumes an agent's processing budget and latency, so a specs folder should be treated as a lean, compiled instruction set rather than verbose documentation.
  Spec-Driven Production Grade Development In The Age Of Vibe Coding · p6
• explicitUnderstanding where the bottlenecks are is what Lean Tech is about.
  Is AI coding on average 17.3x faster or 1.3x faster? Both. — LinkedIn post by Fabrice Bernhard · p9
• explicitTheodo's 14 years of Lean-to-tech practice gave them a pre-existing frame that made the MIT/UPenn finding unsurprising.
  Is AI coding on average 17.3x faster or 1.3x faster? Both. — LinkedIn post by Fabrice Bernhard · p12
• explicitStatic context (rules and guardrails loaded into every agent session) buys reliability because the agent doesn't have to seek the information out, but costs context-window space upfront, so it should be kept lean; dynamic context (skills, conventions loaded on demand) is more scalable but risks the agent failing to retrieve it exactly when needed.
  Google Just Dropped a Masterclass on Agentic Engineering (It's SO Good) · p7

2026-07

• explicitThe enthusiasts are not wrong: teams that lean hard into AI are producing real, non-imaginary, discontinuous leaps in capability, and this is not a normal cycle you can wait out — teams that sit it out could be out of business before the dust settles.
  AI Enthusiasts Are in a Race Against Time, AI Skeptics Are in a Race Against Entropy · p2
• explicitFrom a lean perspective, each prompt is a depletion of a scarce human-attention resource, so the goal is not smaller prompts but the largest prompt that produces zero rework — developed through deliberate 'agentic katas' that practice expanding prompt scope while refactoring a bloated instructions file into small, individually-retrievable skills files.
  Software Teaming in the Age of AI with James Herr and Woody Zuill · p6

2026-08

• explicitcorroboratedHours, flow/lean metrics (including story points), and tokens recur as measurement proxies because they share three failure modes: overweighting the input ('I') side of ROI over the return side, favoring shorter-term easier-to-attribute use cases, and gravitating toward whatever is easiest to measure.
  TBM 437: Tokens, Hours, Points, and Other Curious Proxies · p2
• explicitcorroboratedFlow/lean metrics are genuinely valuable, but only for continuous improvement -- understanding bottlenecks and system health -- and should not be used as a proxy for investment or value itself.
  TBM 437: Tokens, Hours, Points, and Other Curious Proxies · p8

2026-09

• explicitThe lean startup methodology (Ries, Blank, Toyota lean manufacturing) was fitted to a resource-scarce environment: capital, an MVP, extensive customer discussion, and iterative pivoting by small teams.
  AI Is Changing the Rules of Entrepreneurship · p2
• explicit'Abundance entrepreneurship' differs from the lean startup across six dimensions: constraints, typical actors, experimentation logic, speed, organization, and key skills.
  AI Is Changing the Rules of Entrepreneurship · p3
• explicitEstablished organizations must also adopt abundance-entrepreneurship practices -- managing a portfolio of options and accelerating internal innovation -- beyond what they already gained from adopting lean-startup principles, in order to keep pace with AI-native competitors.
  AI Is Changing the Rules of Entrepreneurship · p13
• implicitThe authors treat 'abundance entrepreneurship' as a durable, structural successor paradigm to the lean startup rather than a speculative or hype-driven phase, despite documenting significant, unresolved failure modes (illusion of progress, sycophancy, MEDVi's regulatory failure, unreliable autonomous agents) within the same piece.
  AI Is Changing the Rules of Entrepreneurship · p14
• explicitcorroboratedTeams should explicitly and deliberately define, as a written team norm, when AI use should be single-player versus multi-player, and when it should be lean-forward versus lean-back, rather than letting these defaults emerge implicitly from habit.
  AI + Teams = ? · p6
• explicitcontestedBecause today's environment contains substantially more disorder than order, managers should lean toward preferring coherence even though they are more comfortable dealing with order.
  Beyond Autonomous Teams in Software Product Development · p9

Tensions

Open gaps (21)

• incompleteThe article treats human co-presence as the only lever on review transaction cost. It does not consider AI-assisted in-IDE review or AI pair-programmers as potential substitutes for some of the human availability cost. Given the explicit framing ('inventory expands to match transaction cost'), AI review tools that provide immediate, in-context feedback are a direct theoretical implication the author doesn't draw.
  From Async Code Reviews to Co-Creation Patterns — read next: Cursor / Copilot / Claude Code workflow studies; AI-as-pair-partner literature; any post-2024 work on continuous AI review folded into authoring.
• incompleteReviewer-as-knowledge-distributor function is largely unaddressed. PRs serve as a passive knowledge-sharing mechanism for team members not involved in authoring. Mob covers this for participants but raises the question of those NOT in the session.
  From Async Code Reviews to Co-Creation Patterns — read next: Codebase ownership patterns; bus factor / knowledge silos; mob rotation strategies for cross-team knowledge.
• incompleteThe article assumes review is primarily about correctness/quality of code-as-written. It doesn't address review's role in architectural drift, dependency hygiene, security review, or other concerns where a fresh reviewer's distance from the work might be a feature, not a bug.
  From Async Code Reviews to Co-Creation Patterns — read next: Threat modeling literature; architecture decision records; literature on outside-in review for security and design coherence.
• 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.
  Is AI coding on average 17.3x faster or 1.3x faster? Both. — LinkedIn post by Fabrice Bernhard — 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.
  Is AI coding on average 17.3x faster or 1.3x faster? Both. — LinkedIn post by Fabrice Bernhard — 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.
  Is AI coding on average 17.3x faster or 1.3x faster? Both. — LinkedIn post by Fabrice Bernhard — 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.
  Is AI coding on average 17.3x faster or 1.3x faster? Both. — LinkedIn post by Fabrice Bernhard — read next: The Demirer/Musolff/Yang paper itself; recent METR / RCT-style AI productivity studies; Pocock workshop on what changes with harness-level tooling.
• 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.
  Is AI coding on average 17.3x faster or 1.3x faster? Both. — LinkedIn post by Fabrice Bernhard — 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.
  Is AI coding on average 17.3x faster or 1.3x faster? Both. — LinkedIn post by Fabrice Bernhard — read next: Pocock workshop extraction; Anthropic harness design paper; Cloudflare Mythos extraction; the Anthropic enterprise PDF extraction.
• incompleteThe episode gives no end-to-end example of a "sibling rivalry" incident being handled — what was actually said, what changed, or whether the person stayed or was removed. The "you got to lean in" prescription remains abstract, in contrast to the vivid, specific detail given for the hiring and site-visit anecdotes.
  A Leading Restaurateur on What It Takes to Scale a Winning Culture — read next: Look for a documented conflict-resolution or performance-management case study from Meyer or a similar hospitality/service leader that walks through an actual incident end-to-end.
• incompleteThe episode systematically tells the success-side of the story. Crisis → response → improvement is the recurring arc, but failed experiments, dead-end framework choices, or instances where 'gjøre det lett og rett' produced unintended organisational uniformity are absent. Moe's stated regret is only directional (could have done more, faster, in more places), not structural (e.g. 'this particular default we engineered was wrong'). The hosts twice surface the hierarchy-is-inevitable point but do not press on whether the framework-team's 'easy and right' becomes a hidden orthodoxy.
  5) Vidar Moe: Det eneste Vidar vil er å ha det lett — read next: Pair with Allen Holub's #NoAccountability strand (already in the user's persona) and with anything on the costs of platform-engineering paved roads (e.g. Charity Majors / Honeycomb on the limits of golden paths). The user's existing extraction on Cutler's institutionalised overload is a strong complement here — Cutler's frame would ask what the second-order costs of the SpareBank 1 system look like.
• incompleteMoe's persistent 'vi' is itself a load-bearing rhetorical pattern that the hosts notice in closing but do not unpack. The episode is a portrait of a person who declines to be individuated — he says 'vi' even when narrating decisions whose intellectual origin clearly lies with him personally. This is consistent with the leadership-through-defaults thesis (the work is the structure, not the speaker) but it also obscures the part of the story that does depend on a specific senior practitioner persistently present in the system for 14 years. The question 'how transferrable is this without Moe (and Stian)?' is not engaged.
  5) Vidar Moe: Det eneste Vidar vil er å ha det lett — read next: Read in tension with the previous Heis episode on hierarchy (Eikeland, ep 4, alluded to: 'forrige podcast-episoden snakket om... det er sjelden helt flat struktur') and with the leadership-presence strand in the user's library (Cutler on power and space, TBM 413). Beck's writing on senior individuals' role in evolutionary design is a direct anglophone parallel.
• incompleteThe 'organisatorisk gjeld' coinage at the close is the most pregnant unfinished idea in the episode. Moe gestures at the next direction of 'lett og rett' — engineering golden paths for product development itself, with good practices baked into roadmap tooling — but does not work it out. This is exactly the territory where the AI question reconnects: an agentic product-development assistant that encoded the right defaults could be the next instance of 'lett og rett', and would be a Moe-shaped answer to the alienation worry from his essay.
  5) Vidar Moe: Det eneste Vidar vil er å ha det lett — read next: Pair with the user's existing extractions on harness engineering for AI coding agents and on 'Agents Don't Know What Good Looks Like'. The Backstage / Internal Developer Platforms tradition (Spotify) is the obvious anglophone analogue. Team Topologies (Skelton & Pais) and DORA's recent platform engineering findings are the natural canon. Truls's closing observation that Toyota → DORA → Team Topologies is one lineage is exactly the bridge.
• incompletePair programming is named as the most effective form of knowledge sharing and as the substrate that the rest of the infrastructure exists to support, but the cost question (developer preference, time investment, neurodiversity, hybrid/remote context) is not engaged. Moe acknowledges that change in this direction is 'ordentlig seig' — really tough/slow — but does not ask why even at SpareBank 1, with all the structure in place, pair programming is not yet universal. The same gap exists in his essay's TDD-with-the-agent prescription.
  5) Vidar Moe: Det eneste Vidar vil er å ha det lett — read next: Read Birgitta Böckeler's recent work on remote pair programming, and the user's already-extracted Beck material on TCR (which functions as a half-step toward pair-discipline). The 'AI Joy Gap Developers' extraction the user already has — which treats reconnection-of-developers as needing organisational structure — is a direct complement.
• incompleteThe Norwegian / Lean-Norwegian context is implicit but not theorised. The åremål concept comes from Norwegian political and academic life and is being repurposed for engineering leadership. The fagtid concept has roots in Norwegian work-culture autonomy ideas. The DORA / Lean / Toyota convergence Truls names at the end is itself partially a Nordic management-culture convergence. There is a comparative essay latent here that the episode does not write.
  5) Vidar Moe: Det eneste Vidar vil er å ha det lett — read next: Read in parallel with NAV's 'optimizing for fast flow' piece (already in the user's queue), with Norwegian Self-Determination Theory–inflected management writing (autonomi, mestring, mening), and with the wider tradition of Nordic engineering culture vs. anglophone agile-at-scale. The user's coding-agents corpus already includes Nils Brede Moe (no relation? — but a Nordic empirical-software-engineering voice in the same neighbourhood, including the upcoming Heis episode 9).
• illogicalThe 'critical feature that turned out unused' anecdote is used to justify 'just build it and move on,' but the same evidence equally supports the opposite lesson — instrument usage or validate demand before building — which he never considers as an alternative.
  Presentation: Maximizing Success with Limited Time, Resources, and Energy: Lessons from Startup Engineering — read next: Lean/validate-before-build literature (e.g. Lean Startup) as a counter-framework to his 'ship fast, don't argue' heuristic.
• incompleteThe three-whys protocol is offered as a sufficient diagnostic test, but iterated 'why' questioning is famously unreliable as a root-cause method when the real cause is multi-causal, political, or tacit. It tends to converge on whatever cause the asker is already disposed to find. The piece does not engage with the limits of the technique it prescribes.
  Most of what lawyers do is folklore — read next: Critiques of the Toyota '5 whys' in lean literature; Sidney Dekker on the field guide to understanding human error (against single-root-cause framings); Charles Perrow on normal accidents (multi-cause systemic failure)
• perspectivalNo voice from a mathematician who believes formalisation will fail or is the wrong approach. The article presents only optimistic assessments.
  The secret project to settle controversial maths proof with a computer — read next: Seek critical perspectives on whether IUT's novel category-theoretic constructions can even be expressed in Lean's type theory.
• temporalNo timeline or estimate is given for how long full formalisation might take. Major formalisation projects (e.g., Liquid Tensor Experiment) have taken years for far shorter proofs.
  The secret project to settle controversial maths proof with a computer — read next: Compare with timelines of completed Lean formalisation projects (Liquid Tensor Experiment, Sphere Eversion, FLT-regular).
• uninformedThe book devotes a dedicated chapter to Remote Software Teaming, which this extraction did not analyze in depth — it is the one place the book directly engages with distribution, the default condition for many of the AI-era, geographically dispersed teams this corpus otherwise tracks.
  Software Teaming: A Mob Programming, Whole-Team Approach — read next: Re-read the 'Remote Software Teaming' chapter directly against current distributed/async-first team norms and tooling.
• illogicalThe endorsement of 'gut over head' (SahilBloom tweet) sits uneasily next to the endorsement of 'shared design concept before you code' (Pocock). The first valorizes unjustified judgment; the second valorizes explicit-and-shared rationalization before action. The newsletter treats both as obviously correct without noting that they pull in opposite directions for a leader deciding which to lean on in a given situation.
  SWLW #701: Gazing at the misty AI Frontier, From Vibe Coding to Agentic Engineering, and more. — read next: Daniel Kahneman on when intuition is trustworthy (closed environments with rapid feedback — i.e., precisely the closed loops AI is eating); Gary Klein's recognition-primed decision research for the conditions under which gut beats analysis