AI changed how fast you build. Less discussed: it also changed when you should build.

I figured this out recently in a way that was equal parts clarifying and annoying. I'd been heads-down on a new context — ingesting documentation, running intake sessions, building a picture of the problem space before designing anything. Classic approach. The kind of upfront rigor that has kept me from building the wrong thing more times than I can count.

When I finally shifted to execution, I put together three working prototypes in a matter of days. Stakeholders were thrilled.

And then I caught myself thinking: I could have done this sooner. The ramp-up was still necessary — but it didn't all need to happen up front. That style of intake solves for a world that doesn't exist anymore.

When Build Became the Discovery

The old logic was sound: building is expensive, so understand deeply before you design. Front-load the thinking to protect the work. Every hour in discovery saves three in rework.

That math only works when building is slow.

AI collapsed the cost of execution. I can prototype something real in hours, put it in front of a stakeholder the same day, and adjust based on what I actually see — instead of what I imagined.

Here's the part I genuinely hate writing, because it contradicts something I've believed for 20 years: you don't need to fully understand the problem before you start solving it.

You can build your way to understanding faster than you can read your way there.

I want to be honest about what it costs me to say that. My whole professional instinct is built around the opposite — understand the problem deeply before you touch the tools, every single time. I have been that person in every kickoff, every discovery session, every meeting where someone wanted to jump to solutions before they'd done the thinking. And I'm telling you: for execution-level work, in an AI-assisted cycle, that sequence is now sometimes the slower path. The prototype gets you to clarity faster than the intake does.

That sentence would have been wrong a year ago. It's not wrong now.

This is the same dynamic that shows up in product funnels — the navigation you strip out in the name of "frictionless design" that turns out to be quietly managing user anxiety the whole time. The hidden work friction does only becomes visible once it's gone. Here, the friction was the execution ramp-up. It was protecting against expensive builds. The builds stopped being expensive. The friction stayed.

Let's Be Direct About "Move Fast and Break Things"

This is not that.

"Move fast and break things" was never a philosophy. It was a rationalization for skipping thinking, for mistaking velocity for direction, for building whatever was technically interesting and dressing it up as strategy. It produced exactly the teams you'd expect — ones that could ship anything except the right thing. The wreckage it left behind isn't a cautionary tale anymore, it's a genre.

What I'm describing is a recalibration of when to think and what to think about.

Strategic clarity is non-negotiable — knowing what problem you're solving, for whom, and what the cost of getting it wrong looks like. If you don't have that, speed makes everything worse. I've written about what happens when AI makes exploration too cheap: you ingest everything, strategize nothing, and end up with a pile of ideas that doesn't connect to a single decision. That failure mode is real and it's expensive.

But execution ramp-up is not the same as strategic clarity. One requires a sharp thesis before you move. The other used to require an expensive runway before you built. One of those things changed.

Letting Go Is Hard to Do

Look at the parts of your process you dropped quickly when AI came along. The slow research, the manual synthesis, the week-long documentation slog. You cut those without much grief — they were visibly painful and the better path was obvious.

Now look at what you're still holding onto. That's the stuff that worked. The process with a real track record. The instinct that's been right too many times to question. And that's exactly why you haven't questioned it.

Sometimes they still are. That's what makes this hard.

Here's the one thing worth doing today: write down the top three things you do before you start building anything — your pre-execution checklist, whether it's formal or just habit. For each one, ask a single question: am I doing this because the problem requires it, or because building used to be expensive?

You don't need to overhaul your whole process. One honest answer is enough to know where to start.