Don't just write the spec. Run it.

Everyone in AI-assisted development has converged on the same conclusion: the prompt is not the unit of work. The spec is. If the model doesn't know what "done" means, it will happily produce something that compiles and misses the point.

But "spec-driven development" now means three very different things depending on who says it. Roughly, the industry has three layers of answers — and most tools stop at the first or second.

Layer 1: better prompts

The first wave of answers were prompt frameworks — the acronym recipes that tell you to give the model a role, some context, a clear ask, a tone, and to iterate. They work. A well-structured prompt beats a lazy one every time.

But a prompt, however well-crafted, dies with the chat. It's read once, by one model, in one session. If you forgot a constraint, nothing tells you. Next week, next feature, next teammate — you start from zero. A prompt framework describes how to ask. It never defines what done means.

Layer 2: better spec files

The second wave — the one getting all the attention right now — is spec scaffolding toolkits. You've seen them: a CLI, a handful of slash commands, and out come tidy markdown files — a spec, a plan, a task list — that your coding agent then reads before it writes code.

This is real progress. Writing the spec down before generating code is the right instinct, and these kits make it easy to do.

But look closely at what happens after the markdown exists:

• Nothing validates it. The spec is complete when you feel it's complete. No scoring, no gate, no diff.
• Nothing enforces it. The agent reads the file. Following it is optional. There's no checkpoint that fails when the implementation quietly disagrees with the spec.
• Nothing maintains it. Code moves on; the markdown stays where you left it. Within weeks the spec is a historical document, not a source of truth.
• It's session-scale. These kits shine for one feature in one sitting. A product with months of history, multiple contributors, and evolving requirements is a different problem.

A template system makes it easy to write good spec files. It does nothing when the spec and the code start lying to each other.

Layer 3: a spec runtime — how nTra does it

nTra's bet is that the spec shouldn't be a file you write. It should be a structured, validated, living object that the platform builds with you and then enforces on every agent that touches your project.

Here's the lifecycle:

Discovery, not dictation. You don't start by writing a spec. You start by talking. nTra's discovery engine interviews you — a question engine that knows which parts of your requirements are still empty, ambiguous, or contradictory, and asks only about those. Facts you stated and assumptions the AI made are kept separate and visible, so you correct the assumptions before they become code.

A real schema underneath. Everything captured lands in a canonical, versioned requirements schema — machine-validated, not vibes-validated. A completeness scorer shows what's missing. A verify gate blocks progression until the spec actually holds together. You can diff two versions of your requirements the way you diff code.

The spec generates the work. From approved requirements, nTra synthesizes the delivery plan: epics, stories, and tasks with estimates — each traceable back to the requirement that justified it. A task that can't be traced to a requirement is a signal: either a requirement is missing, or the task shouldn't exist.

The spec gates the execution. This is the part the file-based toolkits skip entirely. Work flows through explicit gates — plan, refine, approve, implement, review — and agents can't skip them. The spec isn't advice the AI might follow; it's the acceptance criteria the review gate checks before anything is called done.

The spec stays alive. Generation is grounded in your project's knowledge base — your docs, your decisions, your designs. The spec evolves with the project, changes are diffed and reconciled, and a provider-neutral mirror can live in your own repo, so you're never locked in.

The one-line version: in nTra, the spec is the source code of the project, and the agents are its compiler — with type checking.

The takeaway

Prompt frameworks make one answer better. Spec files make one session better. A spec runtime makes the whole project converge — because the definition of done is written down, machine-checked, and enforced at every gate.

That's the bet nTra makes: don't just write the spec. Run it.

_______________________________________________________

Building with AI agents? nTra turns your requirements into a validated spec, your spec into a traceable backlog, and your backlog into gated, reviewable agent work.