I've watched a lot of features go sideways, and almost none of them failed because of a coding error. They failed because of a design flaw — the kind that makes you cringe, the kind you end up patching with band-aids just to stop the bleeding.
And by design flaw, I don't mean architecture. I mean something one step earlier: requirements that leave just enough room for interpretation that every sprint becomes a series of design decisions nobody realized they were making.
Here's how that usually plays out. The feature ships on time. Clients start adopting it. For a while, everything looks fine — until the warning signs show up. Then the issues start piling up, right as adoption is accelerating, which is the worst possible timing. Every new client surfaces a new variation of the same underlying problem: a weak premise at the core of the solution. Heroics get thrown at it, but the gap between the fix and the actual problem keeps widening with every client that comes on board.
I've also seen the opposite. A genuinely thoughtful, well-specified design goes out, and the client reviews are glowing from day one. That contrast is what got me interested in design thinking in the first place.

Why This Is an Executive Problem Now, Not Just an Engineering One
For years, we optimized for developer productivity because writing code was the expensive part. Every process, every tool, every methodology was built around that assumption.
AI is changing that equation. Code is becoming cheap. Understanding the problem well enough to specify it correctly is becoming the valuable, scarce skill. When implementation is fast and nearly free, the cost of a design flaw doesn't shrink — it moves. It shows up later, at scale, in front of clients, instead of in a code review.
That shift is what pulled me toward the idea of "executable specs": what if the spec became the source of truth — something teams align onbefore they build, and something that keeps paying off long after launch as a living context layer for future work? I define an executable spec by what it has to do. Every executable specification has four jobs: clarify intent, separate user journeys, expose hidden assumptions, and define implementation boundaries. Get all four right, and a tool can build precisely. Miss even one, and no tool can save you.
Testing That Framework: Spec-Kit, and Where It Broke
Microsoft's spec-kit looked like a natural fit for putting that framework into practice, so my team and I ran an experiment: we took what we assumed was a simple search feature and put it through spec-kit's workflow — specify, clarify, plan.
In theory, that workflow breaks a spec into implementable slices. In practice, our results didn't match the promise, and it took us a while to understand why: our spec was failing the second job on the list — it hadn't separated the user journeys.
Here's the concrete example. Our "simple" search feature actually involved three coordinated services — one for the UI, one talking to the LLM, and one talking to the application layer, which needed context about the object being retrieved and had to enforce a set of business validation rules. The real system flow looked like this: a user enters a prompt, the LLM interprets it and calls the appropriate skill, that skill calls the application's MCP server to retrieve results, and the results come back as a chat summary alongside full detail in the application UI.
None of that was laid out clearly in our original spec. Spec-kit's clarify step asked good questions — some relevant, some not — but it never went deep enough to separate these three flows cleanly. Without that separation spelled out up front, there was no way for spec-kit to generate a plan that matched what we actually needed to build.

Building the Missing Layer
That gap is what led us to build something upstream of spec-kit: an agentic workflow that takes raw inputs — requirements docs, meeting notes, architecture diagrams, existing OpenAPI specs — and forces all four jobs before anything gets planned. It produces a detailed concept design first, then we refine it through a round of clarifying questions, including deliberately counterintuitive "why" questions designed to expose the assumptions the first draft didn't know it was making. Only after that refinement do we slice the spec to match individual API operations and hand it to spec-kit.
That refinement is iterative — it usually takes several passes — but it's worth every cycle. With that level of clarity going in, spec-kit generated a genuinely targeted implementation. The code and tests it produced matched what stakeholders actually expected, on the first pass.

Why This Matters Beyond This One Project
As AI gets better at implementation, competitive advantage shifts further upstream. Organizations that invest in better design won't simply build software faster — they'll build the right software more consistently, which compounds in a way that speed alone never does.
Every generation of software engineering has improved implementation. AI may be the first generation that forces us to rethink design itself.