Your AI Adoption Isn't Stalled. Your Decisions Are.

Your team bought Cursor. Your engineers are happy. Your cycle time hasn’t moved. Everyone’s quietly wondering what went wrong.

Nothing went wrong with the tool. You just discovered that typing was never the bottleneck. Ambiguity was — and AI doesn’t absorb ambiguity the way engineers did for the last twenty years. Spec-Driven Development is the forcing function that moves the decisions upstream, where they were supposed to live the whole time.

That’s the post.

The comfortable lie

The story every founder has been sold in the last eighteen months is simple: buy seats, train the team, watch output 10x. When it doesn’t happen — and at the org level, it almost never does — the blame lands on engineers (not leaning in) or tools (not good enough yet).

Both are wrong. The handoff into engineering is broken, and it has been broken for a long time. AI didn’t cause that failure mode. It just made it impossible to hide.

Engineering has always been downstream of bad requirements

Here is the thing nobody likes to say out loud: for most of the last twenty years, engineering has quietly absorbed vague requirements as part of the job.

Product hands over a ticket with half the decisions deferred. Design iterates during the build. The engineer “figures it out,” which is a euphemism for making the decisions product and design didn’t get around to. That absorption was invisible work, and it was expensive. It just didn’t look expensive, because engineering owned it on the ledger.

This was survivable when the build cycle was three weeks. The engineer had time to churn, push back, renegotiate, build, throw it away, and build again. The slowness lived inside the engineering phase, so that’s where everyone pointed when the roadmap slipped.

AI collapsed the build cycle from weeks to hours. I watched the shift happen in my own workflow. At the org level, that collapse doesn’t give you a faster org. It gives you an org where the ambiguity has nowhere to hide.

What this actually looks like

Here’s the pattern I see in almost every engagement right now.

An engineering leader tells me: “Our timelines explode every single feature. Product and design keep renegotiating in flight. The engineers absorb it as iteration. We call it agile.”

Then they roll out AI. Suddenly a feature that used to take three weeks can be built in an afternoon. Great news, except the team still has three weeks of product-and-design churn queued up for that feature. The churn has nowhere to go. It can’t compress into the three-hour build window. It spills out onto Slack, onto tickets, onto PR review threads, onto the engineering manager’s calendar.

AIs don’t do vague. They require precision. A feature done in three hours cannot survive three product-and-design rewrites. There is no build cycle left to absorb them. This is the same insight that shows up one layer down, in the codebase itself: AI works when the boundaries are explicit. The org-level version of explicit boundaries is a spec.

The slowness didn’t disappear. It moved upstream, into the open, where the whole org can finally see it.

You might read this as “the author wants us to go back to waterfall.” That isn’t the claim. Spec-Driven Development is decision-forcing, not phase-gating. Engineers still build iteratively. What changes is that the product decisions get made once, upfront, instead of being re-litigated in every PR review. The iteration happens inside the spec, not against it.

”But our PMs won’t write specs”

This is the first objection every time I raise it. And I take it seriously, because historically it’s been true. Most PMs don’t write specs. Most designers don’t write specs. Most companies don’t ship specs. That’s the history.

It’s also a 2022 objection.

Writing a structured spec used to take days, which is where the “PMs won’t” reputation came from. In 2026, a PM can produce a passable spec in under an hour from a voice memo, using the same AI tools you bought for engineering. The tooling objection has melted. What’s left is a choice, not a constraint.

The real question isn’t “will our PMs write specs.” It’s this: does your org want to make each product decision once, upfront, or re-make it every time an engineer pings the PM in Slack about edge case 47? Those are the two options. Pick one.

What changes on Monday

Stop measuring AI adoption by seat counts. Stop measuring it by satisfaction surveys. Measure it by time from decision to ship, and notice how much of that time happens before engineering writes a single line.

Throughput is an org property, not a team property — a point I’ve made from a different angle, and it applies with more force now, not less. The AI seat on the engineer’s desk is one-seventh of the pipeline. The other six-sevenths live upstream: product, design, legal, exec alignment, the decisions nobody wanted to make because they were inconvenient.

You don’t need a six-month SDD rollout. You need the next feature to ship with a spec your engineers can hand to an AI agent without a single follow-up question. Do that once. Notice what it tells you about your org. Do it again.

That’s what AI adoption actually looks like. Not better tools. Better decisions, made earlier, by the people who were supposed to make them.

The diagnosis

If that reads like a diagnosis of your current rollout, it probably is. Most AI adoption programs I see are organized around the wrong layer — the IDE, not the decision pipeline.

If you want help building the forcing function across product, design, and engineering at the same time, not just handing your engineers better autocomplete, book a call.