Deep read · July 6, 2026 · source published July 3, 2026

Spec-Driven Development was always BS

Source: “Spec-Driven Development was always BS” by @PawelHuryn · July 3, 2026

One argument doing the rounds is that writing a full spec up front never really worked — waterfall lost to agile because teams discover what they actually need while building, not in a document written before the first line of code — and that it fails the same way for AI agents, because the unknowns surface during the work, not before it. The proposed fix is intent engineering: instead of chasing every unknown, you hand over the context around the goal (the why, the strategy, the constraints, and the conditions to stop) so the agent can navigate the gaps you never listed. That matters to anyone whose build runs on specs or goal-prompts, because the claim is either a real warning or a strawman worth pinning down. The strongest evidence is the pattern itself: a bare goal tells an agent the target but not when to walk away, which is exactly where long autonomous loops go sideways.

The claim: 'always BS' is aimed at the frozen upfront spec

The opening is deliberately provocative — spec-driven development was always BS, for humans first and now for agents. The evidence is the history every builder half-remembers: waterfall (write the full spec, then build to it) lost to agile because teams discover what they actually need while building, not in a document written before the first line of code.

The same failure is said to repeat with AI. The unknowns show up during the work and after it, so a spec written before the work can't contain them. This is spec-driven development: deciding the full behaviour in a document before building, then treating the build as transcription.

Read carefully, the target is narrow. The argument isn't against planning; it's against the idea that the plan is finished before you've learned anything.

The fix proposed: intent, not a longer task list

The move is to stop hunting for every unknown unknown, because you can't, and instead hand over the context around the goal so the agent can handle gaps you never listed. The name for this is intent engineering — communicating the why, the strategy, and the constraints, not just the target.

The one-line version: agents don't fail because the model is weak, they fail because the intent is incomplete. That line is doing a lot of work and it's worth holding at arm's length (more below), but the underlying craft is real, and it's the same idea that context engineering already files under 'give the model the why, not only the what'.

Stated from the intent side, a good brief explains the purpose and the boundaries so the worker can make the hundred small calls you didn't foresee — the way you'd brief a capable junior rather than script their keystrokes.

The concrete template: 8 parts, and the one a bare goal misses

The useful, testable part is the checklist — the '8 parts that unlock autonomy': Strategy, Objective, Desired Outcomes, Health Metrics, Org Context, Constraints, Autonomy Boundaries, and Stop Rules. Most of these are unsurprising. The load-bearing pair is the last two.

Autonomy boundaries name what the agent may decide alone versus what needs approval. Stop rules are the explicit conditions to halt, escalate, or hand off. The sharpest observation: a bare goal 'covers the target, not when to walk away.'

That maps onto where autonomous loops actually break — not on knowing the destination, but on not knowing when to stop digging, when they're stuck, or when the situation has changed enough to come back to a human. A goal says 'get here'; stop rules say 'and abandon the attempt if X.' Most specs, and most goal prompts, write the first and skip the second.

The same idea in three worlds

Strip the AI framing and this is an old management principle. In finance and operations, it's the difference between a procedure that lists thirteen keystrokes and a delegation brief that states the objective, the approval thresholds, and 'come to me if the counterparty changes the terms'. The four-eyes check and the escalation limit are stop rules by another name.

In software, agile never actually killed the spec; it shrank it into acceptance criteria and a Definition of Done that travel with each small piece of work. The honest reading is 'smaller, intent-carrying specs beat one big upfront one', not 'no specs'.

In AI, this is the goal-as-contract idea: specify the end state, the evidence of success, the constraints, and the budget, then pair it with an evaluator, because the agent's own claim that it's done is not evidence. Three vocabularies, one mechanism: state the why and the guardrails, then let the doer navigate the middle.

The counter-take: the title oversells the substance

Where the sources agree: communicate intent and constraints, don't pre-specify every step. Where the piece overreaches: 'always BS' is a strawman.

Spec-first demonstrably works where discovery-while-building is unacceptable — avionics, medical devices, payments rails, a fund's NAV calculation. And the stronger adversarial point is self-inflicted: the '8 parts' framework is itself a spec you write up front. It hasn't killed the upfront document, it's changed what goes in it (intent and stop-rules instead of implementation detail).

So the real, defensible claim is narrower and more useful than the headline: spec the intent, not the keystrokes. The comforting one-liner, 'agents fail because intent is incomplete, not because the model is weak', is close to unfalsifiable and lets a genuinely weak model off the hook. Sometimes the model really is the bottleneck.

Vocabulary

spec-driven development — deciding a build's full behaviour in a document, then building to match
intent engineering — giving an agent the why, strategy and limits, not just the goal
stop rules — explicit conditions telling an agent to halt, escalate, or hand back
goal-as-contract — a goal stating the end-state plus proof of success, so done can't be faked
out-of-distribution — inputs unlike anything the model saw in training, where it reliably struggles

If you're building — what to watch for

Check whether your agent goals actually encode stop rules ('halt or escalate when X'), or only a target and a pass/fail gate. The halt condition is the half most prompts skip.
Write autonomy boundaries into the brief: what the agent may decide alone versus what comes back for approval. Undeclared boundaries get discovered the expensive way.
Restating the goal, scope and assumptions before executing is intent engineering in miniature. It catches the misread before it becomes work.
A spec that freezes the what and leaves the doer nothing to navigate with is the failure mode here. Specs carrying intent plus limits survive the critique; task-transcription specs don't.
Pair any goal-contract with an independent evaluator. An agent's own claim that it finished is not evidence that it finished.

Reading it critically

'Always BS' is a strawman. Spec-first is correct and standard in high-assurance work (avionics, medical, payments, NAV calculation) where discovering requirements mid-build is unacceptable; the honest claim is 'for exploratory software and agent work'.
The 8-part framework is itself an upfront spec. It replaced implementation-detail specs with intent specs, it didn't abolish specs. The real lesson is 'spec the intent, not the keystrokes'.
The waterfall-to-agile analogy proves the opposite of the headline: agile didn't kill specs, it shrank them into user stories plus acceptance criteria. Smaller, iterative specs, not none.
'Agents fail because intent is incomplete, not the model' is near-unfalsifiable and excuses weak models. Models still struggle badly on out-of-distribution verification, and no brief fixes that.
Practitioner assertion, not evidence: one PM citing another, with no benchmark or A/B. Treat the checklist as a useful prompt, not a proven result.

Read the original → ← Back to the Reading Desk