Six months ago, we experimented with AI coding agents that looked like this: open a chat, type a paragraph describing what we wanted, watch code appear, and then spend the next hour discovering everything the model assumed that we never said. Rinse, repeat, argue with the diff.
That's raw prompting. It works for small, disposable tasks. It completely falls apart the moment you need a feature that must survive contact with a real enterprise codebase, a rigorous engineering team, and a production incident three weeks later.
What changed for us wasn't a smarter model; it was a different unit of work. Instead of prompting the agent, we started specifying for it. This is the core idea behind Spec-Driven Development (SDD), and it's why the industry is moving away from chat-based chaos toward strict, reviewable contracts.
The Problem with Raw Prompting
Raw prompting fails in three entirely predictable ways:
- Intent lives only in your head: The model has to guess at edge cases, error handling, and "obviously implied" business rules because you never wrote them down, you just knew them.
- Context erodes over a session: As a conversation grows, earlier decisions get reinterpreted or silently dropped. The code five turns later rarely agrees with the structural decisions made in turn two.
- There is nothing to review before the expensive part happens: By the time you can evaluate whether the agent understood you, it has already written 400 lines of complex framework code. Catching a misunderstanding at that point requires a rewrite, not a simple edit.
Spec-driven development flips this order entirely. You and the AI agree on what is being built, how it is architected, and why in a reviewable artifact before a single line of implementation code exists.
The SDD Core Philosophy: The spec becomes the contract. The code becomes a derived, disposable output that can be regenerated if the spec is right, and thrown away if it isn’t.
Four Tools, Four Philosophies
"Spec-driven" isn't a single rigid workflow; it’s a family of methodologies designed to enforce discipline on LLMs. Depending on the scale and shape of the application problem, the toolchain shifts.
1. GitHub Spec Kit
This works better for greenfield features. It structures development into explicit, linear phases (/specify -> /plan -> /tasks -> /implementation) and introduces the concept of a project "constitution."
This constitution acts as a standing set of architectural constraints, testing disciplines, and codebase rules that every AI-generated spec must respect.
2. The BMad Method
BMad earns its keep on large, highly ambiguous initiatives that would typically require an entire agile team. It simulates this structure using distinct, specialized agent personas that hand off to one another: an analyst clarifies the problem, a PM writes the PRD, an architect produces a design doc, and a scrum master shards the work into context-sized stories. This forces planning and execution into entirely separate context windows, ensuring the dev agent isn't polluted by the architectural debate.
3. OpenSpec
The tool of choice for brownfield engineering - making changes to massive systems that already possess accumulated code and complex dependencies. Instead of heavyweight upfront planning, OpenSpec centers on change proposals. It treats specifications as a versioned, living state of the entire system, allowing developers to review spec deltas exactly like a lightweight RFC(Request for Comments) before deployment.
4. WaveMaker AI (The Two-Pass Compiler Model)
Where text-based markdown specs work well for individual microservices, enterprise full-stack applications require a compiler-grade safety net. WaveMaker elevates SDD from a human writing discipline into an automated architecture through its Two-Pass Coding System.
Instead of asking an LLM to generate raw UI components and backend logic in a single, chaotic step, WaveMaker splits the workflow cleanly:
- Pass 1 (Stochastic Intent): The AI processes user prompts, requirements, or Figma layouts to generate an intermediate, tech-stack-agnostic meta-model (WaveMaker Markup Language, or WML). This visual/structured model acts as the ultimate, reviewable spec.
- Pass 2 (Deterministic Execution): A platform-level compiler reads that WML spec and automatically spits out clean, production-grade Angular, React, and Java code. Because Pass 2 is governed by strict engineering rules rather than probabilistic LLM guessing, the generated codebase contains zero AI hallucinations.
Mapping the Spec-Driven Landscape
The Ultimate Reality Check
None of these frameworks replace human engineering judgment. A poorly designed spec will still produce poorly written code. However, a spec-driven model fails faster, cheaper, and far more visibly than a bad prompt ever could. You can read a specification or review a visual meta-model in two minutes and immediately spot a logical gap. Catching that same gap after an AI has buried it inside hundreds of lines of raw code is an engineering nightmare.
The teams gaining the highest velocity from AI aren't those writing the most clever, essay-length chat prompts. They are the teams treating code as a downstream consequence of a well-defined model.
Raw prompting optimizes heavily for the first draft. Spec-driven development and architectures built on a two-pass compiler model optimized for the tenth revision.
If you are building software designed to run real enterprises, that tenth revision is the only one that actually matters.