Why the enterprise case for specs has nothing to do with process ceremony 

Spec-Driven Development entered 2026 as the serious developer’s answer to vibe coding drift. The claim is simple: AI agents produce better, more consistent output when they implement against a reviewed specification instead of an ad-hoc prompt. 

Marmelab called it “Waterfall Strikes Back.” 

Both sides are right, and both are arguing about the wrong thing. The interesting question is not whether specs slow developers down. It’s what happens inside a regulated organisation when an autonomous agent writes code and nobody can reconstruct why. 

We think about this constantly at Jeen, because it is the same problem our customers hit one layer up. Banks, hospitals, defence organisations, and government agencies deploying agents on our platform do not ask “can the agent do this?” They ask “who approved it, what was it allowed to see, and can we show that to an auditor?” Spec-Driven Development is that question, scoped to code. 

What vibe coding is actually good at 

It’s worth being precise before dismissing it. Vibe coding, write a loose prompt, iterate on whatever the agent produces, is the correct tool for a real set of problems. 

Exploratory prototypes. If you don’t yet know what you want, the fastest path is to build something rough and react to it. You can’t specify what you haven’t discovered. 

UI experiments. Interaction feel is hard to describe in advance. Seeing three bad layouts beats writing one requirements doc. 

Throwaway automation. A fifty-line script that renames files does not need a design document. The cost of a slow, ceremonial process is real; the cost of getting it slightly wrong is not. 

Fast feedback. Does this API behave the way I think it does? Vibe coding answers that in minutes. 

The mistake is exporting these success patterns to production features with real constraints, real users, and real regulatory exposure. 

Where it breaks, and why it breaks worse in the enterprise 

Vibe coding degrades predictably as scope and stakes increase. 

Once a feature touches five or more files, the agent starts losing track of invariants, and every prompt re-establishes context that was set and forgotten two sessions ago. Architectural drift follows: absent explicit non-goals, agents implement things. The agent adds a caching layer because it seems reasonable, and three sessions later that assumption is baked into the data model. 

Constraints are the sharper problem. “Only authenticated users can trigger this” is one sentence in a requirements document. In a vibe coding session, it’s something you said once, in session one, that the agent no longer has in context when it writes a new endpoint in session four. Authorisation rules, validation boundaries, secrets handling, precisely the implicit requirements that vanish when an agent optimises for plausible working code rather than correct, constrained code. 

For a solo developer, that’s a bug. For a bank, a hospital, or a defence contractor, it’s an audit finding. And when someone asks six months later why the system behaves this way, the artifact recording what was decided is… the git log. 

This is the failure mode we designed against. Jeen carries SOC 2 Type 2 and ISO 27001, and both audits ask the same class of question a good spec answers: what was the intended behaviour, who reviewed it, and what evidence exists that the system does what was approved. Undocumented intent is not a documentation problem in a regulated environment. It is a control gap. 

What SDD actually changes 

Good SDD does not eliminate iteration. It relocates it. Instead of iterating on code and inferring intent from diffs, you iterate on the spec, then implement against it. 

A typical workflow runs five phases: 

  • Specify — problem statement, users, goals, non-goals, acceptance criteria, open questions. 
  • Plan — architecture decisions, affected modules, data model, API contracts, security concerns, test strategy. 
  • Break down — small implementation slices with explicit validation criteria and review checkpoints. 
  • Implement — one task at a time, context reset between tasks, updating the plan when reality diverges from design. 
  • Validate — tests, lint, type checks, acceptance criteria, spec-to-code diff. 

The agent participates in nearly all of it: drafting the spec, generating the design, proposing tasks. But a human reviews the artifacts before implementation begins. That checkpoint is the entire difference between SDD and vibe coding, and it’s also what makes the output auditable. 

The waterfall critique is aimed at bad SDD 

The criticism isn’t wrong; it’s misdirected. Waterfall’s defining characteristic is a feedback loop stretched to weeks: requirements, design, build, test, ship. Feedback arrives late, after you’ve already built on a wrong assumption. 

When a developer generates a 200-line task list before writing a single line of code, then spends two days polishing requirements before the agent touches anything, that is waterfall. Waterfall with markdown instead of UML, but the failure mode is identical. One commenter described using a spec toolkit for a small CLI and finding it “too slow, too much tweaking before seeing code.” They were right, for that task. 

“Specs are bad” and “long upfront planning before feedback is bad” are different claims. Only the second one holds.

The version that works 

Good SDD stays small and starts implementing early. 

Keep the requirements document for a single feature to one screen. If it runs ten pages, it’s either a platform design or it needs decomposition; oversized specs take too long to review and go stale fast. Size each task to a single agent session: a small diff, reviewable, testable in isolation. 

Spec the first task, implement it, validate it, then move on. Do not spec everything before implementing anything; the first implementation always reveals what the spec got wrong. When it does, update the spec, not just the code. A spec that doesn’t reflect what was built is worse than no spec, because people trust it. 

And map every acceptance criterion to at least one test. The test suite is the machine-readable version of the spec. If the spec says only authenticated users can trigger an endpoint, a test should prove unauthenticated requests are rejected. 

How much spec does this task need? 

The practical question is never “SDD or vibe coding.” It’s a sizing question. 

Vibe coding fits when the task takes under a day, you’re exploring or learning, the artifact is throwaway, you’re the only person who will touch it, and feedback speed matters more than correctness. 

Lightweight SDD fits when the task spans two or more days, touches multiple files, carries explicit security or correctness requirements, will be continued by someone else, or needs tests that map to stated requirements. 

Full SDD fits when the change touches a public interface or data contract, multiple agents or team members are involved, the organisation mandates design review, or compliance and audit trails are required. 

The most common mistake is applying full SDD to tasks needing only the lightweight version, and no spec at all to tasks that needed one. 

The same pattern, one layer up 

All of this scales badly in one specific direction: the more agents you run, the more the spec stops being a developer convenience and becomes infrastructure. 

When several agents implement different parts of one feature, the spec is the only shared source of truth; without it each agent optimises locally, and the pieces don’t fit. When an agent operates against production systems in a regulated industry, the reviewed artifact is what your auditor reads. When work is handed off eighteen months from now, the spec is the handoff. 

That is precisely the premise the Jeen platform is built on: agents need durable, reviewable, access-controlled context, not just good prompts. The mapping is close to one-to-one, and it holds at the infrastructure layer too.  

Once a team wires an application straight to a model API instead of routing it through a governed layer, the same drift that erodes an unspecified codebase erodes the estate around it: token usage, data flow, and prompt content go dark to central IT, a pattern we call the Direct-to-Model Bypass. It is the same absence of a written-down decision, one layer lower in the stack. 

The cost curve tells the same story from the finance side. Jeen’s internal architecture research puts in-house AI platform builds that start at a projected $240K to $590K routinely landing at $1.5M to $4M within the first twelve months, with a further 30 to 50% of that as a recurring annual maintenance tax. Very little of that overrun is model spend. Most of it is the cost of decisions that were never pinned down early enough to prevent rework: what the system was for, what it was not for, and who was allowed to change it. 

A spec declares what the agent is allowed to assume. In Jeen Admin, that becomes knowledge-access policy: SSO, RBAC, and explicit rules about which documents and systems a given agent or user is permitted to retrieve. “Only authenticated users can trigger this” stops being a sentence someone hopes the model remembers and becomes a policy the platform enforces, logged through an immutable audit ledger that serialises every execution state, prompt-context chunk, and tool call to a transaction log that cannot be edited after the fact. 

A spec declares non-goals. In Jeen Agent Factory, that becomes the agent definition itself: a no-code artifact describing which systems the agent orchestrates and which steps it takes, reviewable by a human before it goes anywhere near production. The same review checkpoint that separates SDD from vibe coding, applied to agents instead of pull requests. Maccabi Healthcare Services runs this same checkpoint across 46 agents in a regulated healthcare environment, cutting case handling time from 30 minutes to 3 while holding 90%+ response accuracy, a result that depends on the review checkpoint holding at scale, not just at launch. 

A spec declares cost and blast radius. In Jeen FinOps, that becomes per-user, per-agent, and per-department budgets and consumption reporting, enforced with real-time throttling and deterministic runtime quotas rather than a policy someone hopes an agent respects. An agent without a spending ceiling is the operational cousin of an agent without non-goals: it will do something reasonable-looking, at scale, until someone notices. 

A spec is where the organisation records intent. In Jeen Workspace, that intent lives alongside the organisation’s actual documents, so the assistant employees use every day is grounded in approved internal knowledge rather than a plausible reconstruction of it. And in Jeen Talk, the same principle covers voice interactions: capture, transcription, and analysis under explicit compliance controls, rather than conversations that happened and left no reviewable trace. 

Two architectural choices follow from the same reasoning. Jeen is multi-LLM by design; the customer picks the model, and the governance layer does not change when they switch, which matters given that Jeen’s architecture research finds LLM accuracy in production decays over time regardless of vendor, typically falling to around 85% of baseline at six months and to a failing 60% by eighteen. And Jeen deploys cloud, on-premises, hybrid, or fully air-gapped, because for defence and government customers the reviewable-artifact requirement extends to where the artifact physically lives. A spec you cannot show your regulator, on infrastructure you do not control, is not much of a control. 

Bad SDD is waterfall with markdown. Good SDD is controlled iteration with durable artifacts. The enterprise version of the lesson is the same one, generalised: it is not the model that makes an AI system trustworthy. It is everything you wrote down around it.