Spec-driven development:agents build to the spec.
A change is done when every acceptance criterion is met.
Steer by Pento turns a request into a spec before any code exists, as goals with numbered acceptance criteria. AI coding agents build against them in isolated sandboxes, an engineer steers any session that drifts, and review checks every criterion before a pull request merges.
How a spec gets written
- 01Someone asksA message in Slack or the Ask Steer dock
- 02Steer interviewsThe person who knows, in about 12 minutes
- 03Answers become contextVersioned and linked to the goal
- 04You mark goals ReadyEach with criteria, a priority and dependencies
What is spec-driven development?
Spec-driven development is a way of building software where the spec is written before the code: a set of goals, each with numbered acceptance criteria. AI coding agents build against those goals, and reviewers check the result against the same criteria, so a change is done when every criterion is met. At Pento the spec stays lightweight and changes as you learn: a goal can be revised or added at any point, and the next session builds from the new version.
01Request
02Interview
03Spec
04Build
05Review
You
Say what you need in Slack or the dock
Talk it through in about 12 minutes
Review each proposed goal and mark it Ready
Answer Steer's questions when a goal is unclear
Forward deployed engineers
Write the spec with your team
Steer a session that drifts
Mark each criterion confirmed or to fix
Steer + AI agents
Drafts a goal and lists what it doesn't know
Asks the open questions, saves the answers
Proposes goals with acceptance criteria
Agents build from the goal's brief, in sandboxes
Review + checks
A different model checks every criterion
- 01Request
- YouSay what you need in Slack or the dock
- Steer + AI agentsDrafts a goal and lists what it doesn't know
- 02Interview
- YouTalk it through in about 12 minutes
- Steer + AI agentsAsks the open questions, saves the answers
- 03Spec
- YouReview each proposed goal and mark it Ready
- Forward deployed engineersWrite the spec with your team
- Steer + AI agentsProposes goals with acceptance criteria
- 04Build
- YouAnswer Steer's questions when a goal is unclear
- Forward deployed engineersSteer a session that drifts
- Steer + AI agentsAgents build from the goal's brief, in sandboxes
- 05Review
- Forward deployed engineersMark each criterion confirmed or to fix
- Review + checksA different model checks every criterion
A goal can be revised at any point, and the next session builds from the new version.
Compared
Spec-driven vs vibe coding vs waterfall PRDs.
Each one has a place. The difference is what gets written before the code, and what the code is checked against once it exists.
| Compared on | Vibe coding | Waterfall PRD | Spec-driven, on Steer |
|---|---|---|---|
| Written before code | Vibe codingA prompt, rewritten as you go | Waterfall PRDA long requirements document, signed off up front | Spec-driven, on SteerGoals with numbered acceptance criteria, short enough to read in a minute |
| Code is checked against | Vibe codingWhether it looks right when you try it | Waterfall PRDThe PRD, if someone rereads it | Spec-driven, on SteerEach criterion, by a review model and a forward deployed engineer, with evidence on the pull request |
| When you learn something | Vibe codingThe next prompt changes, and nothing records why | Waterfall PRDA change request, or the document quietly goes stale | Spec-driven, on SteerThe goal is revised or a new one is added, and the next session builds from it |
| Works well for | Vibe codingPrototypes, demos and throwaway experiments | Waterfall PRDContracts where the scope can't move | Spec-driven, on SteerProduction work, with several agents building at once |
| Where it breaks | Vibe codingProduction code nobody can review against an intent | Waterfall PRDWeeks of writing before anything ships | Spec-driven, on SteerWork nobody can describe yet, which starts with an interview or a discovery session |
Heavy PRDs slowed us down on our own projects. A spec on Steer holds what an agent needs to build and a reviewer needs to check, and it changes as soon as you learn something.
From conversation to spec
How Steer turns a conversation into a spec.
Most specs start as one sentence in Slack. Steer does the follow-up a good engineer would: it finds the open questions, asks the person who knows, and writes the answers down before anyone writes code.
- 01
Someone says what they need
A message in Slack or the Ask Steer dock is enough: “we need a billing page with Stripe before the demo on the 20th.” Steer drafts a goal from it and lists what it doesn't know yet.
- 02
Steer interviews the person who knows
When a goal needs a conversation, Steer writes the interview: who to ask, what it already knows and the open questions. The person talks it through with Steer in the browser, in about 12 minutes, while Steer draws the options beside the call.
- 03
The answers become context
The interview is saved as a versioned context item linked to the goal, and it answers the goal's open questions. The next session reads it the same way a person would.
- 04
Steer proposes goals, and you mark them Ready
Each proposed goal arrives with acceptance criteria, a priority and its dependencies. A person reviews it, edits what's off and marks it Ready.
Anatomy of a goal
What a goal on Steer carries.
A spec on Steer is a set of goals. Each one is feature-sized and holds what a session needs to build it and what a reviewer needs to check it.
- Title
- One feature-sized outcome, named the way your team talks about it.
- Acceptance criteria
- Numbered, testable statements. Review checks each one by number, and the evidence shows which are confirmed.
- Priority
- P0 to P3. Steer orders the work by priority and by what depends on what.
- Dependencies
- Which goals it needs first and which goals need it. Independent goals build at the same time, in separate sandboxes.
- Checklist
- The steps toward the criteria, kept by the orchestrator as sessions report back, so progress is visible at a glance.
- Linked context
- Interviews, docs, the repo map and its conventions, versioned, so a session reads the same facts a person would.
- Budget
- A cap on what a session may spend. The cost bar turns gold at 75%, and a session that spends it all stops.
- State
- From Proposed to Ready, In progress, In review, Approved and Merged. A merged goal is Verified only when CI is green on the default branch.
During the build
How the spec stays in charge.
Writing the spec first only helps if the build keeps reading it. On Steer every session starts from the goal, a person can correct a session while it runs, and review checks the result against the same criteria.
Every session starts from the goal
A coding session gets a brief built from the goal: its criteria, the linked context and the budget. The brief is a file in the session's sandbox, brief.md, so the agent reads the spec before it touches code.
A person can steer mid-run
Our engineers watch the sessions they run. When one drifts, a steer message lands at the next five-minute slice, so the fix happens inside the session instead of in a rejected pull request.
Review checks every criterion
An independent review, on a different model than the one that wrote the code, plus a forward deployed engineer, marks each criterion confirmed or to fix, with the file and line of every finding.
Unclear specs become questions
When the orchestrator is less than 0.70 sure of its next decision, it asks a person instead of acting, with a deadline and a default so the project never stalls.
FAQ
Questions about spec-driven development
Not covered here? Bring the question to a discovery call. An engineer reads every request.
Book a discovery callSpec-driven development is a way of building software where the spec is written before the code: a set of goals, each with numbered acceptance criteria. AI coding agents build against those goals, and reviewers check the result against the same criteria, so a change is done when every criterion is met. At Pento the spec stays lightweight and changes as you learn: a goal can be revised or added at any point, and the next session builds from the new version.
Vibe coding means prompting an AI agent and judging the result by eye. It is fast, and it is fine for prototypes. Spec-driven development writes the goals and their acceptance criteria first, so the agent builds against an agreed intent and a reviewer can check every change against it. Once the code goes to production and several agents work at once, that agreed intent is what makes review possible.
No. A waterfall PRD tries to settle everything before work starts, and it goes stale as soon as you learn something. A spec on Steer is a set of short goals with acceptance criteria that you revise as you go. We tried heavier documents on our own projects and they slowed us down, so we keep the spec to what an agent needs to build and a reviewer needs to check.
A clear title, numbered acceptance criteria that can be tested, a priority, the goals it depends on, the context it needs (docs, interview notes, the repository's conventions) and a budget. On Steer every goal carries all of these, and each coding session's brief is built from them.
Our forward deployed engineers, with your team. Steer drafts proposed goals from a message in Slack or a voice interview with the person who knows the answers, and a person reviews each one and marks it Ready. Your team sees every goal, and every change to it, from its seat in the same workspace.
It gets fixed where it is. When Steer is unsure what a goal means, it asks a person instead of guessing, with a question that has a deadline and a default, or a short voice interview. When a running session drifts, an engineer steers it with a message the session reads at its next five-minute slice. The goal is revised, and the next session builds from the new version.
No, but they work well together. Test-driven development writes a failing test before each small piece of code. Spec-driven development writes the acceptance criteria before the work starts, at the level of a feature. On Steer the tests an agent writes and runs are part of the evidence on the pull request, and the review checks that each criterion is actually covered.
No. You can practice it with any coding agent: write the goals and acceptance criteria before you prompt, and review the result against them. Steer is how Pento runs it across many agents at once, with the brief, the review and the evidence built in. Every Pento team and every fixed-price project runs on it.
Contact us
Start your next project from a spec
Start with the free audit. It turns the work into goals with acceptance criteria, and that scope sets the quote: a fixed price when the scope is clear, or a monthly fee for a team. An engineer reads every request.