What is a spec?
A specification is definitely more than just a product requirements document (PRD). Even simply applying a more structured prompt and more explicit technical constraints can produce better code than a plain PRD.
Technically, a specification should explicitly define the external behavior of the target software — things like input/output mappings, preconditions/postconditions, invariants, constraints, interface types, integration contracts and sequential logic/state machines.
In the past, specifications were often written in highly formalized, machine-readable formats. Today, with the help of LLMs, we can describe them using natural language. Essentially, though, a specification still defines the behavior of the target software; it doesn’t just describe business …
What is a spec?
A specification is definitely more than just a product requirements document (PRD). Even simply applying a more structured prompt and more explicit technical constraints can produce better code than a plain PRD.
Technically, a specification should explicitly define the external behavior of the target software — things like input/output mappings, preconditions/postconditions, invariants, constraints, interface types, integration contracts and sequential logic/state machines.
In the past, specifications were often written in highly formalized, machine-readable formats. Today, with the help of LLMs, we can describe them using natural language. Essentially, though, a specification still defines the behavior of the target software; it doesn’t just describe business requirements.
What makes a good spec?
Our experiences from behavior-driven development are still valid. This new technology shouldn’t actually change that much in this area.
For example, specifications should still use domain-oriented ubiquitous language to describe business intent rather than specific tech-bound implementations. They should also have a clear structure, with a common style to define scenarios using Given/When/Then and should strive for completeness yet conciseness, covering the critical path without enumerating all cases. This has an added benefit for AI-assisted software development in that it can help save tokens.
It’s also important that specifications aim for clarity and determinism. While LLMs don’t generate deterministic code like traditional code generation, compiling, or automated test execution, clear specifications can still help reduce model hallucinations and produce more robust code.
However, while LLMs primarily excel at handling natural language we shouldn’t underestimate the role of structured inputs and outputs. Experience shows that providing the model with semi-structured input prompts or forcing it to output in a structured manner can significantly improve reasoning performance and reduce hallucinations. Machine-readable specs, then, remain essential in the LLM era.
Finally, regarding the organization of spec files, many emphasize separating business requirement specs from technical specs. However, in practice, defining the boundary between the two is often unclear.
Spec-driven development remains an emerging practice as 2025 draws to a close; we’re likely to see even more change in 2026. That means staying on top of industry thinking and the experiments being done is critical. At Thoughtworks we’ll continue to experiment and, of course, share our learnings and insights with the rest of the software community.