Matt Wynne

As 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:

1. Lean: Seeing and managing the whole production system using continuous improvement, systems thinking, pull-based flow approaches.

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

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

It combines what Birgitta Böckeler calls harness engineering with the cultural values and practices of lean.

Why Lean?

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 and 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.

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.
• 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.

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. By adopting the mindset of kaizen (continuous improvement) and practicing defect prevention, we can learn from the system’s mistakes and improve it. As Annie Vella describes, this middle loop is where we can have the most leverage as engineers now.

Why XP?

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
• Continuous integration
• Relentless refactoring and a commitment to high-quality code
• Tight human-human collaboration on decision-making

If you’re fearful of LLMs producing low-quality code, 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. The only difference now is that making these changes to your development workflow is cheaper and easier than ever, for example:

• Ask a robot to introduce mutation tests into your CI pipeline.
• Build a review/fix loop that takes on Sandi Metz or Martin Fowler’s persona, identifies flaws in your code and fixes them, autonomously
• Leave an agent in a loop reviewing your test suite for slow tests and optimizing them

Instead of cramming in more features, spend the extra time you’re gifted by these LLMs to improve your working environment, to improve the flow of your software factory.

Towards the Lean Software Factory

Much like TDD, once you’ve experienced “hands off” software development, where you neither write nor read the code, there’s no going back. The pace that you can solve real problems for people is exhilarating.

As the models get better and better, the question increasingly becomes: **what can’t the agents do? **By asking ourselves this continuously, and using their power to automate away tasks that are mundane and error-prone, we elevate our own work to something I consider to be much more interesting: deciding what problems to solve, and how to judge that they were solved to our satisfaction.

The product is still working software, but now the work is engineering the system that produces it.

—

If this sounds interesting to you, I am teaching a public course starting July 16th: Build a Software Factory: Hands-off agentic coding for experienced engineers.