28 July 2026

Spec First, Code Second: How Spec-Driven Development Changes Agentic Coding

Vibe-coding feels fast, but it stalls often. Spec-driven development fixes that: you and the AI agree on what gets built before the code shows up.

This is part 1 of AI Tooling & Fundamentals, a new mini-blog series in which OpenValue engineers share what actually works when you build software with AI. No hype, no doom. Just tools, workflows, and the fundamentals behind them, written by developers who use this stuff on real projects every day. This first part comes from Tom Wigleven, Principal Engineer and AI specialist at OpenValue.

Cover image

The AI guesses at your intent

You ask an AI agent for something. It builds something else. You refactor until you’d rather start over. Sound familiar?

Here’s what happens under the hood. An agent reads your prompt and fills the gaps itself. Usually wrong. You get code that looks reasonable but misses the point. The bigger the change, the further the agent drifts. And the next session it builds something new again, because yesterday’s context is gone.

The core issue: there’s no shared document you both agree on and we can fall back on.

Spec first, code second

Spec-driven development puts a spec layer in front of the implementation. You lock down what you’re building, why, and how you know it’s done. Only when the spec is right does the agent get to code.

What you gain:

  • The AI works toward a fixed target, not a guess.
  • Every change is reviewable as text before a single line of code moves.
  • Future sessions pick up the spec and don’t lose context.
  • The spec grows into living documentation of your project.
  • Being able to verify the implementation against the spec.

A growing set of frameworks supports this way of working, from lightweight spec kits to fuller design-and-tasks pipelines. OpenSpec is one example, GitHub’s spec-kit is another, and a homegrown markdown workflow can work too. The frameworks differ in shape, but they share the same core loop: explore, propose, review, apply, archive. The idea matters more than the tool.

How to get started

Pick a framework that fits your stack. Look for a clear command flow, an artifact set you can actually read (proposal, design, specs, tasks), and hooks into the coding agent you already use.

A typical first flow looks like this:

  1. Kick off a design session with a short brief of your idea.
  2. Let the framework generate the artifacts: proposal, design, specs, and tasks.
  3. Read the documents. Edit them, or have the AI edit them, until the spec is truly what you want.
  4. Run the tasks and let the agent implement against the spec.
  5. Archive the change so the spec deltas merge into your permanent project specs.

The upfront cost is one design session. The payoff is code that lands closer to intent, and a spec that stays useful long after the change ships.

An example with OpenSpec

To make it concrete, here’s what the flow looks like with OpenSpec, which drops into any project with a single install.

Install it globally:

npm install -g @fission-ai/openspec@latest

Init it in your project:

cd <project>
openspec init

Pick your coding agent as the provider. OpenSpec creates an openspec/ folder, drops a config.yaml in it, and registers its commands (/opsx:*) with the agent.

From there, the five steps map to five commands:

  1. /opsx:explore "your idea": start the design session.
  2. /opsx:ff: generate the artifacts (proposal, design, specs, and tasks.md).
  3. Read the documents. Edit them, or have the AI edit them.
  4. /opsx:apply: run the tasks.
  5. /opsx:archive: move the change to changes/archive/ and merge the spec deltas into your permanent specs.

Other frameworks wire it up differently, but the shape is the same.

Tom’s Tips

Stack supporting skills. Combine your spec framework with skills that walk decision branches, stress-test assumptions, or explore alternative designs in parallel. The spec sessions get sharper, and weak ideas fall out before they reach the artifacts.

Be explicit. The clearer you are about what you want and how the agent should approach it, the better the output. Vague briefs produce vague specs, and vague specs produce the same drifting code you were trying to escape.

Review the spec, steer the code. If the spec is right, the code is an execution detail. If the spec is wrong, the code will never land.

Our take: AI raises the bar for fundamentals

At OpenValue we build software with AI every day, at clients like banks, insurers, and logistics companies. What we see in practice matches what Tom describes here. AI makes writing code cheap. It does not make knowing what to build cheap. That skill just became more valuable.

Spec-driven development is really an old lesson in new tooling: agree on intent before you build. Good engineers have always worked this way. The difference is that with AI agents, skipping that step no longer costs you days of rework somewhere down the line. It costs you within the hour.

For clients this matters too. AI-assisted development done well means faster delivery and code your team can still maintain a year from now. Done badly, it means a mountain of plausible-looking code nobody understands. The difference is not the tool. It’s the engineering discipline of the people using it.

Questions about AI in your development teams?

We help organisations get real value out of AI-assisted development: hands-on in projects, and through OpenValue Training courses on AI for developers and business professionals. Curious what spec-driven development or agentic coding could mean for your teams? Get in touch, we’re happy to share what we’ve learned.

Keep an eye on openvalue.blog for part 2 in this blog series on AI Tooling & Fundamentals.