A sufficiently detailed spec is code

Nature of specs vs. code

• Many see a spec as defining a set of acceptable behaviors (“envelope”), while code is one concrete point inside that set.
• Several distinguish standards from specs: language standards deliberately leave implementation- and undefined behavior, whereas specs aim at conformance.
• Common distinction: spec describes what should happen, code describes how it happens. Good specs avoid implementation detail; code often contains framework- and infrastructure-specific choices.
• Others argue code itself is just an executable spec for the compiler/abstract machine; additional prose specs are a second, fallible spec.

Is a sufficiently detailed spec just code?

• One side: if you remove all ambiguity from natural language, what remains is effectively formal language, i.e., code. Formal specs (e.g., for safety-critical systems) approach this.
• Counterpoint: you can still have high-level formal specs (e.g., properties of a compiler) that are not programs; they omit algorithmic and performance details.
• Some note that crafting a spec that covers all valid implementations is often harder than writing a single implementation.

LLMs, under-specification, and “vibe coding”

• Enthusiastic view: real leverage comes from under-specifying and letting AI pick reasonable designs where many options are “good enough” (e.g., UI layout, data plumbing, boilerplate CRUD, small apps).
• Skeptical view: two users with the same vague spec may expect different outcomes; “meets requirements” depends on how detailed those requirements are. Under-specification often yields surprises and weird bugs.
• Several highlight that LLMs can produce impressive small systems (e.g., analytics server, toy apps) from short prompts, but break down on complex, math-heavy, or domain-unique problems.

Reliability, maintenance, and existing systems

• Major concern: organizations may ship large volumes of AI-written code they don’t really understand, worsening already common problems (haunted codebases, brittle tests, accidental complexity).
• Brownfield work is seen as especially hard: specs are partial, behavior accreted over time, and “regenerate from spec” is not acceptable.
• Tests and formal checks help but don’t solve mis-specified requirements; both specs and code can share the same bug.

Language, dialects, and tooling

• Some predict technical dialects of English (or DSLs) optimized for LLMs: compressed, less ambiguous, more like specification languages or Gherkin/EARS.
• Others argue we already have such unambiguous languages: programming languages, type systems, and formal spec languages; trying to “validate English” just reintroduces complexity away from the real code.

Practical workflows with agents

• Effective patterns described: humans define data models, interfaces, test skeletons, and error-handling strategy; agents fill in implementations and boilerplate, then humans review and refactor.
• Several treat spec docs as evolving design artifacts used to keep behavior stable over iterations, rather than as one-shot blueprints intended to replace coding.