Lean Software Production — Matt Wynne

Lean Software Production<br>May 16, 2026As AI accelerates software development, I see something emerging that I think needs a name. Excuse me for getting fancy, but I propose we call it Lean Software Production .

Or maybe Lean Software Manufacturing? 🤷🏼

Lean Software Production acknowledges that software is no longer a craft, and that mass production is too rigid, inflexible, and inhumane. It combines:

Lean: Industry-standard in modern manufacturing, lean thinking means managing the production system using human-centric continuous improvement, systems thinking, pull-based flow approaches.

Software: The robust software engineering disciplines of Extreme Programming (XP) that keep the software malleable.

Production: Agentic orchestration or dark factory patterns, where LLMs generate large amounts of code unattended.

Let’s dig into these three elements to understand why they matter and how they fit together.

Why Lean?

When comparing the way the Americans approached manufacturing in the 1960s compared to the Japanese lean pioneers, W. Edwards Demming said:

Let’s make toast: I’ll burn it, you scrape it

Many people are working with LLMs like this today: letting the generate code and then trying to inspect the quality in through code review. By adopting the mindset of kaizen (continuous improvement) and practicing defect prevention, we can learn from the system’s mistakes and improve it.

Lean thinking revolutionized the manufacturing of physical goods in the 1960s and 70s, and was fundamental in inspiring the Agile Software development movement in the early 2000s. The Toyota Production System views the production line as a socio-technical system, an elaborate dance between humans and machines.

As machines begin to play an ever-increasing role in the production of software, the pace of delivery accelerates, and the role of humans in this process changes rapidly, I think these ideas are crucial for us to re-visit.

Some ideas and tools from lean, such as Kanban boards, have become a ubiquitous part of the software industry culture. Kanban is rooted in the idea of just-in-time (JIT) production or pull-based flow, popularized as The Theory of Constraints in Eli Goldratt’s The Goal. This idea is also the basis of a Minimum Viable Product (MVP) from Eric Ries’ The Lean Startup.

But there’s so much more in lean that we’ve yet to really embrace. I believe it can really help us in this moment.

In Lean Software Production, instead of spending time crafting every line of code, we focus our attention on crafting the system we use to produce reliable, well-engineered software at scale. By working with the system, continuously improving it, we’re following the lean discipline of Jidoka: building quality in.

What does this look like in practice? For example:

if you notice your agent is making mistakes and generating code that you have to correct, don’t blame the model: Instead, look to how you could have improved the context you gave the model so it would make a better decision next time. Try capturing architectural decision records (ADRs) or design heuristics in your git repo where the agents can study them before writing code.

if you’re confounded by walls of text or code coming out of these models, try asking them to build you a slide deck, or write an HTML file summarizing the key points that you need to understand and consider. Have the agent present or receive the information in a medium that works for you.

This culture of continuous improvement and just-in-time work has created great manufacturing systems, and I believe it’s key to creating great software production systems too.

Why Extreme Programming?

When a single engineer can generate the volume of output that once required a team, the costs of problem ambiguity, architectural weakness, slow or unreliable tests and defects don’t just cause friction, they set things on fire.

In this light, the robust software engineering practices of XP finally start to look like standard industrial safety equipment:

Pervasive automated testing , like double-entry bookkeeping for your code

Continuous integration , so you get fast feedback about whether your changes integrate with everyone else’s

Relentless refactoring and a commitment to high-quality code, keeping the software soft and malleable.

Pairing on decision-making, so that the team keeps a shared mental model of where the system is going and why, through conversations.

If you’re fearful of LLMs producing slop, or building a system that nobody understands, these are the techniques that the best software engineering teams have used for decades to mitigate that risk with humans.

Now, two things have changed: you need these techniques more than ever, and it’s cheaper than it’s ever been to implement them. There’s really no excuse.

For example:

Ask a robot to introduce mutation tests into your CI pipeline.

Build a review/fix loop that takes on Sandi Metz or...