AI Glossary / Generative AI and language / Beginner
Specificational coding
Definition
Specificational coding is an approach to creating software by writing and maintaining a human-language specification file that describes the required behavior, then asking an AI system or developer to implement it. Revisions focus on improving that persistent description as the software evolves. The term emphasizes a reusable specification as a working artifact. It does not mean that a natural-language document automatically becomes an unambiguous or formally verified program.
What it means
An informal conversation can reveal what a user wants, but important decisions may become scattered across messages. Specificational coding gathers the intended behavior into a maintained description that can be reviewed and used again.
The file may explain users, inputs, outputs, business rules, edge cases, and acceptance examples. Its value comes from clarity and consistency, not from length or elaborate formatting.
The supplied glossary contrasts this approach with conversational coding, where iteration occurs mainly through dialogue. In practice, the two can be combined: conversation clarifies a requirement, and the agreed result is incorporated into the specification. The term does not prescribe one document template.
How it works
Begin by describing the problem and the behavior the software must provide. Include constraints that affect the design and examples that make ambiguous wording concrete. Identify unresolved decisions rather than silently allowing an implementer to guess.
Use the specification to guide implementation, then compare the running result with its stated requirements. When the intended behavior changes, update the description and the relevant checks together. When implementation merely contains a defect, correct the implementation without rewriting the requirement to excuse the defect.
Maintain a clear relationship between the current specification, code, and acceptance evidence. A persistent file helps coordination, but it must be kept current and interpreted carefully. Tests and review remain necessary because natural language can omit details or admit several interpretations.
Three practical examples
1. A small business describes the required behavior of an appointment form, including which fields are mandatory and what happens when a time slot is unavailable.
2. An internal team maintains a specification for a report generator, with examples of input records and expected totals before asking an assistant to implement changes.
3. A website project records accessibility, navigation, and content requirements in one reviewed file so repeated implementation sessions share the same intended outcome.
Think of it this way
Think of specificational coding as maintaining the recipe while developing a dish. The recipe records the intended ingredients, steps, and result so that later attempts do not depend only on remembered conversation.
The analogy has limits. Software has many edge cases and interactions that a short description may not anticipate. A recipe can also be internally inconsistent. Keeping a document is useful only if its meaning is checked against real examples and the actual implementation.
Worked example
Suppose the initial requirement says, “Give frequent customers a discount.” That leaves several decisions unanswered. A concrete revision says: “Apply a 10% discount to the merchandise subtotal when the customer has at least five completed prior orders. Do not discount delivery charges.”
An acceptance example uses a customer with five prior completed orders, a merchandise subtotal of 80 units, and delivery of 5 units. The discount is 8, so the expected total is 80 − 8 + 5 = 77 units. A customer with four completed prior orders pays 85 units under this rule.
The example still leaves other matters to specify, such as refunds, rounding, and order-status definitions. Making one rule concrete improves review without pretending that the entire commercial system is fully described.
Illustrative case study
Fictional case: Willow Forms asks an AI assistant to build a membership application. During demonstrations, the team repeatedly requests changes to eligibility wording and confirmation messages, but the latest decisions are spread across several conversations.
It creates a maintained specification and records the agreed rules with example applications. A later review finds that one implementation still uses an older eligibility condition. The team fixes the code and adds a check based on the current requirement.
The document makes the disagreement visible: the issue is a mismatch with an agreed rule, not a matter of whichever conversation the implementer happened to remember.
Common misconceptions and mistakes
Specificational coding is not simply writing one long prompt. A maintained specification has an ongoing role as requirements change and implementation is reviewed.
It is not formal verification. Ordinary prose can be ambiguous, incomplete, or contradictory, even when organized carefully. Formal specifications and proofs involve additional methods and assumptions.
Another mistake is letting generated code silently redefine the requirement. If behavior is intentionally changed, update the specification explicitly. If the code is wrong, fix the code. Finally, a detailed specification does not eliminate the need for competent engineering judgment about implementation, security, performance, and usability.
Business use
This approach can help business and technical participants agree on observable behavior before and during development. It supports handoffs and reduces dependence on scattered conversational history.
Keep the document focused on requirements that affect decisions. Use realistic examples and state how success will be demonstrated. Assign responsibility for resolving conflicting requirements and maintaining the current version. The benefit should be assessed through clearer reviews and fewer misunderstandings, rather than assuming that specification-driven AI generation necessarily reduces cost or produces production-ready software automatically.
People also ask
Must the specification be written in a programming language?
No. In this usage, it is a maintained description in a human language, though it can include structured examples and technical details.
Can conversations still be used?
Yes. Dialogue can clarify needs, while the resulting decisions are incorporated into the persistent specification.
Does passing the listed examples prove complete correctness?
No. Examples cover selected cases. Additional testing and review are needed for other behavior, interactions, and failure conditions.
Check your understanding
The specification requires a discount after five completed orders, but generated code applies it after four. Should the document be changed simply to match the code?
Answer: No. Unless the business intentionally changes the rule, the implementation should be corrected. The specification records intended behavior rather than retroactively justifying every generated result.
Related terms
- Conversational coding
- Specification
- requirements engineering
- acceptance criteria
- test case
- generated code
- version control
- formal specification
- software validation
- change management
Learn next
Select one small software feature and write its purpose, inputs, outputs, rules, and three acceptance examples. Include one boundary case and one invalid input. Have another person explain the expected behavior from the document alone, then resolve any differing interpretations before using it to guide implementation.
More in Generative AI and language
- Sequence-to-sequence (seq2seq) - Sequence-to-sequence, often shortened to seq2seq, describes a model or task that transforms an input sequence into an output sequence.
- Sequential importance sampling - Sequential importance sampling, or SIS, is a probabilistic inference method that builds candidate sequences incrementally and updates a weight for each...
- Skip-gram negative sampling - Skip-gram negative sampling, commonly abbreviated SGNS, is a method for learning word vectors by distinguishing observed word-context pairs from randomly...
- Speculative decoding - Speculative decoding is an inference technique that accelerates autoregressive generation by proposing several tokens with a cheaper draft process and...
- Stratified sampling - Stratified sampling divides a population or dataset into distinct groups, called strata, and selects samples separately within those groups.
- Subword token - A subword token is a unit of text used by a tokenizer that can represent part of a word, a whole word, or another learned text fragment.
Sources
Sources: Google Machine Learning Glossary, https://developers.google.com/machine-learning/glossary — primary definition of specificational coding and its contrast with conversational coding; both entries were read. The specification workflow, discount calculation, and fictional membership-form case are original practical illustrations. The term is used in the glossary's descriptive sense, without asserting a universal industry standard, mandatory template, or automatic correctness guarantee.
Previous: Specification limits Next: Spectral Analysis