Lean Tech & AI Journal

Lean in the Age of AI: Optimizing the Stream, Not the Coder

Written by Tom Peperkamp | Feb 19, 2026 12:30:00 AM

In IT, we don't talk much about lean anymore.

And for a long time, that made perfect sense. We didn't need to talk about it because we had successfully baked it into our systems. We adopted agile to tackle the waste of large batch sizes. We built DevOps pipelines to eliminate the waste of waiting and handoffs. We structured stream-aligned teams (team topologies) to minimize cognitive overload and dependencies.

We effectively engineered "waste" out of the system by design. The abstraction layers worked so well that we forgot the underlying physics -- lean thinking and the theory of constraints -- that made them work in the first place.

And then came AI.

Generative AI hasn't just sped up our processes; it has fundamentally altered the economics of production. It has blown the cover off our abstraction layers, and to fix the new problems it creates, we need to look at the engine again.

The AI Efficiency Trap (and the Return of Herbie)

There is a dangerous confusion right now between resource efficiency (keeping the coder busy) and flow efficiency (keeping the value moving). 

AI optimizes resource efficiency to an extreme degree. It allows a developer to produce code, documentation, and unit tests at lightning speeds. But as Clarke Ching (the ‘bottleneck guy’) recently warned, “AI is about to break your software teams.”

Why? To answer that, we have to look back to Eli Goldratt’s classic book, The Goal,i and the character of Herbie.

Herbie was the slowest scout in the troop (the bottleneck). The troop could only arrive at camp as fast as Herbie walked. If the kids at the front of the line (the “fast walkers”) started running, they didn’t get the troop to camp any faster; they just created a massive gap and lost contact with the rear. 

Let’s be honest: writing code was never the actual bottleneck. 

In the pre-AI world, the real constraint was often upstream — the messy, human time spent wrestling a vague idea into concrete requirements. Or it was downstream, waiting on feedback. The “typing” part in the middle was rarely the problem.

In the pre-AI world, the real constraint was often upstream — the messy, human time spent wrestling a vague idea into concrete requirements. Or it was downstream, waiting on feedback. The “typing” part in the middle was rarely the problem. 

But AI creates a seductive illusion. By hyperinflating the speed of this middle step (“the build”), we feel productive. But in the theory of constraints, any improvement made at a non-bottleneck is a mirage.

We are recreating a bottleneck where we had previously eliminated it. Before we broke down the silos, QA and validation were often the major constraints. DevOps and cross-functional teams largely solved that. But now, AI is flooding the gates again, creating a new variant of that old bottleneck: cognitive load. 

This is the human capacity to review, understand, verify, and secure the massive volume of code the machine just spit out.

If you use AI to speed up the non-bottleneck by 10X, you don’t get 10X value. You get a pileup. You get 10X the pull requests waiting in the queue, 10X the confusion, and a massive drop in flow efficiency.

The Danger of “Idle Hands”

Here lies the behavioral risk. Developers are problem solvers; they do not like to sit idle. 

If AI helps a developer finish a task in 10 minutes that used to take an hour, they rarely say, “I will now pause to let the QA bottleneck clear.” Instead, Parkinson’s Law kicks in: work expands to fill the time available. 

Without strong strategic direction, that freed-up capacity turns into the worst of the seven lean wastes: overproduction.

  • We see “gold-plating”: over-engineering solutions because it was easy to add complexity.

  • We see “inventory”: features built “just in case”" the AI suggested them.

  • We see “churn”: refactoring working legacy code just to try a new pattern

We are at risk of flooding our stream-aligned teams with more “digital inventory” than they can mentally process. We are moving from a pull system (building what is needed) to a push system (building what the AI makes easy).

A Lean Renaissance: Peeling Back the Layers

So, how do we fix this? We need a lean renaissance. 

It is time to peel back the abstraction layers of standard agile ceremonies and look at our value streams with fresh eyes. We need to stop asking “How can we code faster?” and start asking “Where is the constraint?” 

This is where the evolution of enterprise architecture comes into play. As I’ve written before, EA isn’t dead — it’s just changing roles. We can use the EA Capability Model, which defines what an organization does, not just for governance, but to map these new value streams. We need architecture to help us spot where local optimization (AI coding speed or agentic AI in our value streams) is actually hurting global optimization (time to market).

We need to strengthen the focus on lean so that AI becomes a tool for autonomation (automation with a human touch) — helping us spot defects and reduce cognitive load — rather than a tool for mindless volume.

The Bottom Line: Flow Over Speed

In this new era, we need to change our metrics.

Stop celebrating how fast your team can build. AI makes “time to hello world” (the time for a developer to install a tool, set up an environment, and run the first program) instant. That metric is now irrelevant. We need to focus on different measures of health:

  1. Good old mean time to recovery (MTTR): If AI helps you write 1,000 lines of code in a minute, but it takes you three days to debug a hallucination hidden within it, you haven’t moved faster. You’ve just moved backward. 

  2. Mean Time to Scale (MTTS): AI coding agents follow the geometry of the “shortest distance between two points.” They generate the most direct code possible to solve the immediate prompt. While efficient, this code often lacks architectural foundation — ignoring abstraction layers, security patterns, or database normalization required for growth, resulting in:

  • The trap: You ship the feature instantly because the code “works.”

  • The reality: You spend the next month rewriting that “flat” code because it collapses under load.

  • The metric: How long does it take to turn that AI prototype into an enterprise-ready solution? That delta is your real cost.

Don’t let AI be the thing that breaks your flow. Use the new tools, but govern them with old wisdom. It’s time to dust off your lean manuals — you’re going to need them more than ever.