The spec-driven crowd has the order backwards

The spec-driven crowd is right about one thing. If you point an agent at a vague intention and tell it to ship production code, you get expensive garbage at machine speed. Apoorv Gupta at Microsoft puts the equation cleanly: "Spec quality = output quality." The agents got fast enough that the spec became the bottleneck, and the cost of miscoordination has surpassed the cost of writing and maintaining specs. That is a real shift. AWS Kiro built a feature in two days that used to take three or four weeks of engineering work. I am not going to pretend the spec doesn't matter.

But watch where everyone puts the spec in the sequence. Microsoft's framing is "teams align first and let AI accelerate execution from a clear spec." Align first. The whole 2026 SDD movement front-loads alignment into a document written before anyone has touched a working version of the thing.

That is the causality I want to argue with.

Apply the lens. Distance to first proof is the number of days until a real person uses a real version and forms an opinion. The three-week spec argument is not optimizing that number. It is a group of smart people trying to write a crystal-clear specification from imagination, then defending each line to a committee. They are not stuck because they lack discipline. They are stuck at the wrong distance to proof. Every hour in that room is an hour the artifact could have been answering the question instead.

Here is the move the SDD camp gets backwards. The crisp spec is downstream of the prototype. The prototype comes first. Ravi Mehta, who ran product at Tinder and now writes the most honest version of the spec-driven case, says the quiet part: rapid prototyping generates customer feedback first, which then informs a "crystal-clear spec" before AI-assisted implementation begins. Read that order again. Prototype, feedback, spec, build. The spec the agents need is the output of a prototype loop. You produce it by building, then writing down what you learned. Mehta also says the best prototypes are the ones you throw away on purpose, and that a working prototype is often more descriptive than a written spec while taking less effort to create.

So both things are true at once. You do need a sharp spec before you let an agent write production code. And the fastest way to get a sharp spec is to build a thin version first and let a real person react to it. The three-week teams are trying to skip the step that would have made their spec good.

I have run this. Fleetwise existed because I wrote the first line of code myself and got it in front of a paying customer before there was anything resembling a spec to defend. The spec, such as it was, got written by the prototype and the customer's reaction to it. The thing told me what it wanted to be. Then I handed it to an engineering team to scale, and at that point a crisp spec was exactly right, because by then we knew which decision the spec was settling. Mehta's first question is the right one: not "what should we prototype," but "what decision are we trying to make." A prototype aimed at a decision collapses the distance to proof to ninety minutes. A spec written to avoid making the decision yet extends it to three weeks and calls the delay rigor.

The agentic tools sharpen this. When building the thin version costs an afternoon, the spec-first ritual gets more expensive by comparison every month. You can have the working artifact and the feedback before the alignment meeting would have even been scheduled. Then you write the spec, and it is clear, because it is describing something that already exists and already has an opinion attached to it.

The SDD movement is right that the spec is the source code now. The open question it skips is where a good spec comes from. Specs are not authored in a room. They are harvested from a prototype that already touched a user.

So the next time your team books three weeks to align on a spec, ask the question that settles it: how many days until a real person can use a real version of this and tell you you're wrong? If the prototype is faster than the meeting, why are you in the meeting?

You've got the order right. The spec is harvested, not authored. I lived that with Fleetwise and I won't relitigate my own story.

But watch what happens when the audience can't opt out.

The prototype-first loop assumes you can put a thin version in front of a real person, let them form an opinion, and harvest the spec from the wreckage. That works when the blast radius is one paying customer who can walk away. It breaks when the blast radius is national.

I ran brand and systems work on Akun Belajar.id, the single sign-on for tens of millions of teachers and students in Indonesia, and Merdeka Mengajar, reaching teachers across 17,000+ islands. You cannot ship a half-built SSO to forty million people "to see what it wants to be." If the thin version fails, a teacher in a school with one hour of connectivity a day loses their only window. The user can't route around you. There's no second tab.

So the prototype audience becomes a tiny proxy. A few hundred teachers in a pilot district, who are not the edge cases that actually break you. The opinion you harvest is real but partial. And the spec has to carry weight the prototype never earned, because it's covering the constituencies the prototype couldn't reach: the regulator who moves slowly, the infrastructure that drops, the school that can't afford to be your test.

That's not the spec-first ritual you're arguing against. It's the spec doing load-bearing work the proof loop physically can't do yet.

So I'd add one line to your question. "How many days until a real person can use a real version and tell you you're wrong" is the right question. The follow-up is: and what is the cost to that person of being your proof? If the answer is "nothing, they close the tab," prototype first, always. If the answer is "they can't opt out and they can't come back," the spec earns its keep before the prototype, not after.

The order isn't wrong. The floor is just higher than an afternoon when people can't leave.