Dear CIO,

For the last decade, we have scienced the heck out of software delivery with Lean, DevOps, Continuous Delivery, DORA metrics, and Value Stream Management. Through this and automation, we have gained an unprecedented capacity to measure variables like deployment frequency, flow rate, recovery time, lead time, and any other metric we could dream of. Through this, it has turned what used to take weeks, or even months, and compressed it down to hours and minutes. That is an incredible accomplishment, but now the chickens are coming home to roost. AI is making code faster and cheaper, but it’s not eliminating the bottleneck. Instead, it’s pushing it upstream, to the idea phase. The new bottleneck is becoming ideation.

Best Regards,
John, Your Enterprise AI Advisor

The next revolution in software delivery isn't about writing code faster. It's about learning what is worth building.

The 12-Inch Ruler

About six years ago, I had a conversation with Mik Kersten on his Mik + One podcast that I keep coming back to about measurement and value streams. At the time, much of the DevOps conversation centered on measuring from code commit to production, and it made sense, as we had terrible delivery systems and we desperately needed to improve them. In this discussion, though, I used an analogy that still feels useful today: The 12-Inch Ruler. 

Imagine the entire journey from an idea to value as a 12-inch ruler. For years, we obsessed over the last two inches, figuring out how to commit, build, test, deploy, and operate. While that work mattered immensely in organizations, the problem is that we often ignored the first ten inches of the ruler. We asked, “How to Deploy?” instead of thinking about where the idea came from, how many meetings occurred before anyone could act, and how long requirements took or how many times the idea bounced between business, architecture, security, finance, product, and engineering before somebody finally made the first commit. When we focus so much effort on optimizing the final two inches, we potentially are wasting the first 5 or 10 by filling out a form that no one has ever used. I think AI is going to expose this as a real issue.

The Fuzzy Front End Isn't Necessarily Fuzzy

There used to be an argument that ideation was simply too difficult to measure, with people calling it the "fuzzy front end." In our discussion, Mik challenged that idea. In most cases, requirements, planning, and ideation are often already being tracked somewhere like Jira, Azure DevOps, or maybe even a product management system. Regardless of its location, in many cases, we actually know when the clock starts.

As Mik pointed out, once requirements or planning activity begins, much of that activity is already structured enough to observe. The problem is that organizations often do not include it in the value stream they measure, and I think that distinction matters. If your delivery metric starts at commit, everything that happened before commit becomes invisible. You can report spectacular engineering performance while the overall organization still takes six months to turn an idea into something a customer can touch. You know exactly how fast software gets deployed, but not how long it takes the system to create something worth deploying. Congratulations!

AI Changes the Equation

Now add AI. Coding assistants are getting better, testing can increasingly be generated, and infrastructure can be created programmatically. That’s not to mention the development of vibe coding, and all of these change things in an interesting way. Historically, the complaint was that ideation took too long. By the time a team started building, months might already have passed. AI gives us a seductive answer: Skip all that. Just build something.

You can describe what you want and generate the application. To be clear, I believe there is enormous value in that. Vibe coding can collapse the distance between an idea and something tangible, but I worry that we are setting up a false choice. Option one is the old world: Long, drawn-out ideation → requirements → approvals → build.

Option two is the new world: Vibe ideation → vibe coding → hope we learned something.

There should be a third option: Science the heck out of ideation.

Aha to KaChing

I have started thinking about this as two very different value streams. There is the journey from Aha → Commit. And then there is Commit → KaChing.

For roughly 15 years, DevOps has made extraordinary progress on Commit → KaChing. We learned how to make software reliably flow through engineering systems into production, but I am not convinced we have anything approaching the same scientific discipline for Aha → Commit.

That is where ideas are explored, assumptions are formed, and customer problems are interpreted. Essentially, it's the part where evidence is gathered, and somebody ultimately decides: This is the experiment worth running.

That process is frequently still meetings, documents, PowerPoints, opinions, organizational politics, handoffs, and HiPPO decisions, yet AI introduces a new difficulty: instead of fixing that process, we may simply bypass it. The old failure mode was analysis paralysis, but the new mode might be generation without understanding.

Vibe Coding May Not Be the Same as Learning

The speed of AI-generated software is impressive, but speed alone does not create knowledge. You can build the wrong thing faster, and you can generate five prototypes without being clear what question any of them are answering. That is why I think the opportunity is bigger than vibe coding.

What if AI helped us accelerate not only software creation, but the quality of reasoning before software is created? What if it helped us determine:

That is a very different use of AI.

It is not prompt → code. It is idea → value hypothesis → experiment → evidence → decision. That is where I think the real opportunity lies.

Stop Complaining About the Forms. Measure Them.

One thing I emphasized in that conversation with Mik was that people inside organizations often already know where the pain is. "The risk review takes forever." "Architecture slows everything down." "Security makes us fill out all these forms." "Product never gives us clear requirements." "The business keeps changing its mind." The problem is that those are complaints, and complaints are easy to dismiss. Data, however, is much harder to dismiss.

We should use value-stream thinking to distinguish value from waste across the entire 12-inch ruler with the goal not simply to ask how much time we can eliminate, but rather where the value is actually being created. If five inches are consumed by governance, show me what value those five inches create. If a one-week delay comes from one document, show me what that document protects, prevents, or enables. If an architectural review adds two weeks, show me what better decision or avoided failure came from it. If product teams spend a month refining requirements before customers see anything, show me what they learned during that month and whether they could have learned it faster through an experiment.

A shorter process is not automatically a better process. Going from six months to two weeks may actually be far more valuable than going from six months to two days if those two weeks preserve the thinking, learning, risk reduction, and experimentation that make the eventual decision better. The point is to understand which activities create value, which merely consume time, and where the real learning in the system actually happens. Then, if we cannot explain the value, then we should be willing to call it what Lean has always called it: waste.

Once you can see the delay, you can ask the much more useful question: Why does this activity exist? Maybe it is important. Maybe it needs to be automated. Maybe it needs to happen earlier. Maybe it needs to happen differently. Or maybe nobody remembers why it exists at all. The goal is to remove the waste while preserving the thinking.

The Real Cost Is Learning

There is another reason this matters. The greatest cost of slow ideation is slow learning, and Mik made this point beautifully in our conversation. If those early stages take three or four months, the organization is delaying its feedback loop. Teams can spend months building something before discovering whether customers wanted it at all. Worse, market conditions can change while the work is underway, and developers can finish entire release cycles only to have the work discarded because priorities changed. Think about the implications that means in an AI world.

If AI lets me build an experiment in two days, but my organization's decision-making process takes twelve weeks before I am allowed to run it, my bottleneck is not technology. On the flip side, though, if AI lets me generate something in two hours and I never stop to ask what I am trying to learn, what value I am trying to validate, or what evidence would tell me whether that value is real, I have not improved the feedback loop either. I have only made building faster. The goal should not be faster ideation for its own sake. The goal should be faster, systemic, end-to-end learning, starting with ideation and continuing through experimentation, delivery, and customer feedback.

From Projects to Experiments

Software operates inside complex adaptive systems with market changes, unexpected customer behaviors, and technological and regulatory changes. You cannot fully specify your way through that uncertainty. You have to experiment. That means ideation shouldn't always aim to produce the perfect requirements document, nor should it be to skip directly to code. It should be to formulate the cheapest credible experiment that can reduce uncertainty.

What do we believe? What evidence would prove us wrong? What could we build quickly? What should we measure? What would cause us to continue? What would cause us to stop? What would cause us to pivot? That begins to sound much more like science than traditional project planning, and that is exactly where I think AI can become transformational. Not simply because AI can write code faster, but because AI can potentially help us make the entire Aha → Commit process more observable, testable, and scientific.

The Third Path

Maybe we should stop thinking about the future as a choice between heavy process and no process. 

The first model is:

Think forever, then build.

The second is:

Build immediately, then figure out what it means.

The third is more interesting:

Think just enough to create a falsifiable experiment, build it quickly, learn, and repeat.

That is where AI, lean, DevOps, product thinking, and scientific thinking start to converge. AI can help us shorten ideation without eliminating it. It can help us challenge assumptions before they become requirements and help us capture discussions, extract hypotheses, identify contradictions, generate alternatives, and turn uncertain ideas into testable experiments. Then vibe coding becomes incredibly powerful, because it becomes part of an intentional learning loop.

The Next Value-Stream Revolution

Imagine recording an ideation workshop and automatically extracting assumptions. Imagine converting those assumptions into candidate experiments. Imagine generating a proof of concept whose purpose is not to demonstrate how clever the technology is, but to answer a clearly defined business question. Most importantly, imagine measuring that entire process from time from problem identification to first experiment to the number of handoffs, percentage of proposed ideas that reach experimentation, and learning velocity. Those may eventually become as normal to CIOs as deployment frequency and lead time are today.

The Constraint Has Moved

None of this means DevOps is finished, though. DevOps's success is precisely why we can have this conversation. We spent a decade improving the machinery of software delivery. Now AI is putting a turbocharger on that machinery, and suddenly, we can see the next constraint. Six years ago, Mik and I were asking why we were studying the final two inches of the ruler while ignoring the other ten. Today we have a new temptation: skip those ten inches altogether, but I do not think either extreme is the answer. We do not need six months of committees before writing code, but we also should not confuse the ability to generate code instantly with the ability to generate good ideas. The opportunity is to create a new discipline between those extremes.

When AI can turn an idea into working software almost instantly, the scarce resource is no longer typing code. It is knowing what questions are worth asking and designing experiments that teach us something. For the last decade we scienced the heck out of software delivery.

Now we need to science the heck out of ideation. The “third path” is now the core thesis: not heavyweight ideation and not pure vibe ideation, but scientific ideation feeding extremely fast AI-enabled experimentation.