Spec-driven development with AI: how to keep code verifiable
Hohen VenturesPublished9 min read
A coding agent may build a feature that lets staff add products to a storefront. Its test may pass even if someone can also add a product to a storefront they do not control.
A spec records both outcomes: allow the authorized write and reject the unauthorized one. As the software changes, tests and reviewers check those decisions again. This guide shows when that extra work is worthwhile and how to make the checks part of development.
What is spec-driven development?
Spec-driven development is a way of building software from written decisions about what should work and what should fail. The team checks the code against those decisions as it changes.
A prompt might ask an agent to "add product creation," leaving it to decide who can add products to which storefront. A spec records both the allowed write and the rejected cross-storefront write, so the agent can choose how to implement each outcome.
As the code changes, reviewers and tests check whether those decisions still hold. The team updates the spec and its checks before asking the agent to continue whenever the intended behavior changes.
Why prompt-only AI coding falls short
A prompt that asks only for an output leaves the rules for success and failure unstated. An agent may fulfill the request while making a choice the team would reject.
For example, "add product creation" could produce a handler that accepts writes to any storefront or one that checks the caller's access. Both create products, but only the second follows the intended boundary.
Unit tests can pass if they exercise only the behavior the agent chose to implement. Without agreed conditions, reviewers have to settle questions like these:
- Access: Should the write be limited to the caller's storefront?
- Failure: What should happen when the access check fails?
- Contract: What rejection should the API return to its callers?
Settling those answers after implementation can mean revising the handler and its tests. A team may accept a passing create test, then discover in review that the handler accepts writes to any storefront because the test never tried a cross-storefront request.
How the spec-driven workflow works
A spec-driven workflow starts by recording what should happen and what must not happen. The team then plans an implementation within those limits, splits the work into tasks, and checks the result against the spec as the code changes.
Check the feature spec before planning, review the plan before splitting work into tasks, and compare each result with its acceptance condition. When intent changes, revise the upstream artifact before continuing.
1. Write the feature spec
The feature spec records the decisions before choosing how to build the feature: who may add a product, which storefront may receive it, and what must happen when someone tries to write to another store.
Start with the operator's job: create a product record in an authorized storefront. Product owners define the intended behavior; engineering and security owners check the access boundary.
A compact feature spec for that job could read:
- Objective: Let a brand operator create a product in an authorized storefront.
- Boundary: Exclude bulk imports and writes to other storefronts.
- Acceptance condition: WHEN a user submits a product to a storefront they cannot access, the system SHALL reject the request without writing a record.
- Verification: Test an authorized write, then confirm that a cross-tenant request leaves storage unchanged.
The team still needs to agree on what the API returns after a rejected request and whether that response reveals anything about the storefront. The plan can then decide where to enforce the access rule.
2. Turn the spec into a technical plan
The technical plan chooses a path through the spec's rules. For the product request, it decides where to check access and where an approved product is saved, without changing which writes are allowed.
For that product request, the plan locates the access check and names the service responsible for persistence. Give the agent the existing API contract and repository conventions so those choices fit the system.
Before generating tasks, trace both paths through the plan: an approved request should save a product, and a rejected request should leave storage unchanged.
3. Break the plan into tasks
Break the plan into small tasks with a check for each relevant outcome. Implement the access rule, save an authorized product, and test that an unauthorized request saves nothing.
Map each task to the test result it must prove:
Related Signals
More notes from the same corner of the AI layer.
AI venture studio: How to assess the scaling partnership
A funding round can close before a company has a path to customers or infrastructure it can scale on. We examine what an AI venture studio supplies beyond the round — and where equity and control enter.
Hohen Ventures8 min read
Agentic Commerce 2026: Mid-Year State of the Market
The primary reader of a commerce storefront is no longer reliably human. Agent-led discovery has outpaced agent-led purchasing — this update tracks where the gap is widest and what separates the businesses absorbing agent-driven demand from those still optimizing for a buyer who stepped back from the purchase loop.
Hohen Ventures12 min read
Two Ways of Thinking About AI
Einstein wanted to understand everything from the inside out. Bohr trusted what he could observe from the outside in. Their unfinished argument now sits at the center of how we govern autonomous AI: whether control comes from comprehending a system completely or from watching it closely and setting the right boundaries. The answer decides how much autonomy we can safely hand over, how wide the gap between intent and behavior grows, and why the future we're building needs both ways of knowing held in balance.
Hohen Ventures7 min read
