Lean × AI · reading path
AI can make one step faster while the request waits somewhere else. Map the full path before calling that a productivity gain.
The operating question
A draft, a pull request and a support reply are intermediate outputs. The user sees a working feature or a resolved problem. When AI increases the flow into review, testing or approval, the queue at that stage may grow even if creation time falls.
The queue shift is a possibility, not a law. Measure both the local cycle and what happens after it; the field study and team accounts below show why one number cannot settle the question.
Lean gives us a way to trace that request. Toyota’s principles offer a useful analogy: make what is needed, when it is needed, and stop defects before they travel downstream. They do not supply a software-team performance forecast.
A five-stage map
Choose a real request type. Record when it enters and leaves each stage, including revisions and rejected work. Compare equivalent requests over equivalent windows.
Swipe sideways to explore the diagram, or use the enlarge button.
The same request, in software
Which user problem is worth solving?
Requests clarified or declined before work startsWhat does AI make faster?
Active work time and items submittedCan someone establish that the result is sound?
Waiting time, reviewer effort and correctionsDid the work reach its intended user?
Time to release or response; failuresDid it solve the original problem?
Adoption or resolution for eligible usersThe next constraint
The queue between creation and acceptance is the part to inspect next. Count items waiting, how long they wait, and the effort spent checking and correcting them. The drawing shows one possible failure mode, not a forecast.
Swipe sideways to explore the diagram, or use the enlarge button.
Read the Lean signals. The shelf is work in progress (WIP), not automatically waste. If measured flow shows unused output, uneven arrivals or reviewer overload, investigate muda, mura and muri. The blank cards show no measured volumes. Enlarge queue diagram ↗
Example, not field data. This count assumes no cancellations or other exits. A correction remains part of the same item. Also track the oldest wait, review effort and defects; counts alone cannot establish user value. Define the queue measures.
If creation gets faster but verification, correction or waiting gets worse, adjust the amount of work admitted or the verification path before scaling generation.
Lean software development
Mary and Tom Poppendieck’s software adaptation calls for building quality in and optimizing the whole value stream. Here, time to delivery and the later user outcome remain separate measures. These terms name possible controls to examine in a real workflow.
Practice, with its limits
Lean can shape how teams build and verify AI-assisted work. AI can also help people practise Lean problem solving. These sources document implementations and practitioner experience, but they do not establish a transferable end-to-end productivity gain.
The study reports a task-cycle comparison. Qonto and Theodo describe changes to their own work. Read each finding with its limit.
Software field study
In a six-week study, Jira tasks tagged as using GenAI had an average development cycle time 23% below the company’s historical figure.
Evidence limit: Participation and task tagging were voluntary. A historical comparison does not establish that AI caused the difference or improved release quality and user outcomes.
Read the ICSE-SEIP study ↗Practitioner account · software migration
A small team iterated from a chatbot to an AI-assisted CLI with a codemod and human review. One engineer, with limited help, migrated 8,632 lines in a two-week evaluation.
Evidence limit: The manual baseline was estimated. Lines migrated do not measure review cost, defects or customer value.
Read Qonto’s engineering account ↗Practitioner account · agent workflow
On the AP-HP ComPaRe EMA project, a CTO reports shipping 15 features in three weeks while reviewing strategy, tests and code, and changing agent instructions after failures.
Evidence limit: The two-month comparison was an internal estimate. User adoption and later defect rates were not published.
Read the Theodo account ↗These examples illuminate an alert, a quality decision and a coaching method. They do not measure the end-to-end software flow shown above.
Lean applied to AI work
Toyota’s enterprise AI team describes LangSmith as an andon board for failed tools, broken pipelines and agent adoption across its internal platform.
Evidence limit: The case is published by LangChain, a supplier. Monitoring an anomaly does not itself prove that work stops or the cause is removed.
Read the Toyota case from LangChain ↗Lean quality management study
A five-year practitioner study at Electronics Works Amberg examines tensions between human and AI decisions, transparent and opaque reasoning, and specification-led and data-led processes.
Evidence limit: The paper analyses adoption in one manufacturing setting. It does not measure an AI-driven speed or quality gain.
Read the Siemens study ↗AI supporting Lean practice
Art Smalley describes RootCoach as feedback on root-cause reasoning. The proposed benefit is coaching available when a human coach cannot respond.
Evidence limit: His quality comparison is personal judgment, not a blind study. LEI also warns that an AI coach can displace human authority.
Read the RootCoach account ↗There are inspectable open-source implementations too. Andon records recurring agent defects and countermeasures; its completion hook has stated limits when the agent writes its own verification entry. RaiSE describes a Lean-inspired software workflow. These repositories show design choices, not measured improvements in user outcomes.
Evidence, with its limits
Principle
The primary source for Just-in-Time and jidoka. Its manufacturing outcomes do not transfer automatically to software.
Research
Qualitative responses from Google engineers describe time moving toward auditing and verification. Check the scope before generalizing.
Field studies
The Microsoft rollout measured an output proxy. A separate company study also observed much higher reviewer load. Neither establishes customer value.
The Microsoft rollout study measured about 24% more merged PRs among adopters over four months. Merged PRs remain an output proxy. Use DORA’s delivery metrics for the release portion and define a separate user outcome for the complete service.
Choose your next step
Before adding more agents
Marek Kalnik's Lean talk describes shared standards and project readiness as conditions for AI work. Eno Reyes argues for reliable checks on a single task before parallel agents. Use Factory's repository criteria to find a concrete gap, then test whether fixing it changes the work.
A source-line check can prove that a citation exists while the agent still misreads the behavior. Before migration, have a reviewer follow the relevant call path and run characterization checks on the existing application. Move one usable unit through review and release before opening several agent lanes. If the format is fragile, exercise the real edit path and check the resulting bytes, including alternate writes.
These are proposed controls, not results from a deployed migration. Record false blocks, rework and reviewer time alongside accepted changes.
Evidence limit: A readiness score describes conditions in the repository. It does not measure agent productivity, shorter delivery or value to the user. Factory's five-level model is its own rubric; scores from another radar are not directly comparable.
From my open-source work
These tools expose parts of AI-assisted work, but none connects a request to acceptance, release and the user outcome. Use their signals in a local value-stream trace, not as a productivity score.
For the measurement evidence, read my AI productivity review. For a human check at the quality gate, the UVAL protocol tests whether an engineer can explain the code they accept; it does not replace team-level review or a user outcome.
