A Hacker News thread from a practitioner asking whether others are using spec-driven or spec-anchored development in production struck a nerve. The question is simple: when building real services with LLMs, should you feed the model a formal specification rather than just a prompt? The underlying concern is whether prompt-based coding can survive the demands of complicated features, legacy codebases, and the kind of guardrails that production systems require.
What Spec-Driven Development Actually Means
Spec-driven development treats the specification as the source of truth, not the code. You write a structured document -- API contracts, type definitions, behavioral expectations, edge cases -- and feed that to the LLM as the primary context for generating code. The spec constrains what the model can produce. It is not a prompt. It is a contract.
In practice this looks like giving an LLM a YAML schema, a TypeScript interface, or an OpenAPI definition and asking it to generate implementations that conform to it. The model does not have creative freedom to invent fields or invent behavior. It fills in a structure that already exists.
This is distinct from prompt-based coding where you describe what you want in natural language and hope the model understands your intent. Specs remove ambiguity by definition.
Why Pure Prompting Breaks Down at Scale
Prompt-based coding works for small scripts and prototypes. The moment you need to coordinate multiple services, maintain backward compatibility, or hand code off to another engineer, the cracks show. Natural language is lossy. A prompt that says "build a user authentication service" leaves hundreds of decisions unspecified. The LLM makes them for you, silently, and you discover the choices at 2 AM when something breaks.
Spec-driven development addresses this by making the decisions explicit before code generation starts. If you define that a login endpoint returns a specific JSON shape with exact field names and types, the model cannot deviate. The spec is the test oracle. If the generated code does not match the spec, you know immediately, not after a code review cycle.
For legacy services, this matters even more. Existing systems have implicit contracts -- other services depend on specific response formats, error codes, and timing behaviors. A spec captures those dependencies. An LLM working from a spec respects them. An LLM working from a prompt guesses.
How Teams Are Implementing This in Practice
The most common approach starts with an existing schema or contract. Teams define their data models in TypeScript interfaces, Protobuf definitions, or JSON Schema, then use those as the context window for LLM-assisted code generation. The model receives the spec, the current codebase, and a task description. Its job is to write code that satisfies all three.
Some teams go further. They generate test cases from the spec first, then ask the LLM to produce code that passes those tests. This turns the spec into a verification tool, not just a generation guide. The workflow becomes: define spec, generate tests from spec, generate code from spec plus tests, run tests. The LLM is one step in a pipeline, not the entire pipeline.
Others maintain a running spec alongside their codebase. Every time a new feature is added, the spec is updated first. The LLM then generates implementation code against the updated spec. This keeps the specification and implementation in sync, something that rarely happens with documentation-first approaches because documentation drifts. Specs, when enforced by tooling, do not.
The Guardrails Problem That Prompting Cannot Solve
The original poster framed this as needing "stronger guardrails than prompt-based coding." This is the crux of the issue. Prompts are suggestions. Specs are constraints. When you are building production services -- especially ones that handle money, user data, or safety-critical operations -- suggestions are not enough.
Spec-driven development provides guardrails at the architectural level. If your spec says all database writes go through a specific repository pattern, an LLM working from that spec will follow the pattern. Without the spec, it might write direct SQL queries, inline business logic in controllers, or introduce patterns that conflict with your existing architecture.
For teams onboarding new engineers or distributing work across AI assistants and humans, specs create a shared vocabulary. Everyone -- human or model -- works from the same document. The spec becomes the contract that all parties sign.
Whether It Is Battle-Tested
Honest answer: spec-driven development with LLMs is early but gaining traction. The Hacker News thread itself reflected this. Some practitioners report success with structured approaches for greenfield services. Others note that maintaining specs adds overhead that only pays off when the codebase or team is large enough to justify it.
The pattern works best in environments where formal specifications already exist -- API-first organizations, teams using contract testing, shops with strict type systems. If you already write Protobuf definitions or OpenAPI specs, adding an LLM to the workflow is a natural extension. If you do not, adopting spec-driven development means building the spec infrastructure first, which is a separate project.
There are also tooling gaps. Most LLM coding assistants accept plain text context. Feeding a structured spec into them requires manual preparation or custom pipelines. Tools that automatically parse and inject specs into the model context are emerging but not yet standard.
What Practitioners Should Watch For
The question is not whether spec-driven development works in theory. It clearly does. The question is whether the overhead of writing and maintaining specs is worth the gain in code quality and reliability for a given team. For a solo developer building a side project, probably not. For a team maintaining a production service with multiple consumers, the investment usually pays for itself.
The LLM angle adds a new dimension. Specs were always useful for human developers. Now they are also useful as machine-readable constraints. A spec that would have been documentation becomes an enforcement mechanism. This is a genuine shift in how specifications deliver value, and it is worth paying attention to even if the tooling is still catching up.