Spec-Driven Coding: The Case Against Prompt-First Development
By Karl Lehnert, Director, DevProStudio
AI coding agents are faster. The expensive part is discovering that they built the wrong thing.
That failure often starts with prompt-first development: describe a feature in chat, let the agent inspect the repository, then keep steering until the output looks plausible. It feels fast because code appears immediately. For an Australian SME, it can also bury missing requirements inside a long conversation that nobody can properly review later.
AWS's Kiro has put formal spec-driven development at the centre of an agentic IDE, using requirements, design and task documents. Not every team needs Kiro, but the unit of AI-assisted delivery is shifting from a clever prompt to a testable plan.
Prompt-first coding creates invisible decisions
A coding agent must fill gaps. If a request says “add customer document upload”, the agent still needs to decide file types, size limits, malware handling, storage location, permissions, retention, error behaviour and what counts as done.
With prompt-first development, those decisions may emerge across messages and live only in model context. A reviewer sees the diff, but not necessarily the reasoning.
Adoption is already ahead of confidence. For its question about “AI tools in the development process”, the 2025 Stack Overflow Developer Survey found 84% of respondents were using or planning to use them. On its separate accuracy question, 46% actively distrusted AI output while 33% trusted it. More generated code does not remove the need to decide what correct means.
Our view at DevProStudio is direct: a prompt is a conversation turn; a specification is a project artefact. It can be versioned, challenged, approved and connected to tests. The specification is not bureaucracy around the work. For any meaningful change, it is part of the work.
What a useful coding specification contains
Do not begin with a 40-page template. A useful spec can be one or two pages if it answers five questions:
- What problem are we solving? Name the user, the current failure and the desired outcome.
- What is in and out? Set boundaries so the agent does not “helpfully” refactor unrelated code.
- What constraints cannot move? Include supported platforms, data locations, permissions, interfaces and compatibility requirements.
- How will we prove it works? Write acceptance examples, failure cases and observable results.
- How will we ship safely? Define review, migration, feature-flag and rollback expectations where relevant.
Kiro separates requirements, design and implementation tasks, with structured patterns such as EARS notation. The principle works with Claude Code, OpenAI Codex or another agent too. Store the artefacts in the repository and require the agent to use them. A future developer should understand why the change exists without exporting a private chat transcript.
The Risk-Weighted Spec Loop
At DevProStudio, we call this the Risk-Weighted Spec Loop. It is a practical implementation pattern, not a claimed client case study.
1. Write acceptance examples before architecture
Start with three to seven concrete examples: the happy path, a permissions failure, invalid input, a dependency outage and any sensitive edge case. Examples expose ambiguity faster than broad prose.
2. Ask the agent to inspect, not edit
Have the agent map affected modules, tests, data flows and unknowns. Require file references. At this stage its job is to identify conflicts between the requested behaviour and the existing system.
3. Approve a small implementation plan
Break the change into reviewable slices. Each slice should leave the repository testable. Keep database migrations, permission changes and external integrations visible rather than hiding them inside a generic “implement feature” task.
4. Execute one slice at a time
Let the agent change code and tests for one approved task, then run the relevant checks. Human review should focus on behaviour, security boundaries and maintainability—not merely whether the code compiles.
5. Reconcile the spec and the result
If implementation reveals a requirement change, update the spec explicitly. Do not let the chat silently become the new source of truth.
This complements our AI-assisted delivery checklist. The spec defines the outcome; delivery controls determine whether the change is safe to release.
Scale the paperwork to the risk
Spec-driven coding becomes theatre if every typo needs a design document. Scale it to risk:
- Tiny, reversible change: a failing test and clear constraint may be enough.
- Normal feature: short requirements, acceptance examples, a system map and tasks.
- High-risk change: add threat modelling, data classification, permissions, rollback plans and named approvals.
Track accepted outcomes, rework and escaped defects. Generated lines and prompt count are poor business measures. Our guide to AI coding tool unit cost explains why seat price misses the cost of correction.
For a current pricing reference, Kiro lists a Free tier with 50 credits and Pro at US$20 per user per month with 1,000 credits; additional paid credits are listed at US$0.04 each. Those figures were checked on 16 August 2026, exclude applicable taxes and can change, so confirm the official Kiro pricing page. For an SME, the better comparison is total cost per accepted feature: subscription, review time, rework and operating risk.
How DevProStudio scopes this work
DevProStudio has no verified public rate card for this work, so a “from” price here would be guesswork. A quote should separate repository discovery, specification, implementation slices, release and optional support. It should state who pays tool licences and how discovery can change scope. Compare accepted deliverables, not an open-ended bucket of agent hours. Contact DevProStudio for a repository-specific quote.
Australian privacy and security belong in the spec
If a feature touches customer, employee or supplier information, data handling cannot be an afterthought. The OAIC's APP 11 guidance says organisations must take reasonable steps to protect personal information and treats security as a lifecycle obligation.
Put those obligations inside the Risk-Weighted Spec Loop, before the agent writes code:
- Identify which data classes may enter the agent context and which must not.
- Specify approved repositories, model endpoints, logging and retention behaviour.
- Use least-privilege credentials; never give a coding agent broad production access for convenience.
- Scan generated changes for secrets and unsafe dependencies.
- Require human approval for identity, payment, deletion and data-export paths.
- Record disposal and rollback expectations, not just the successful path.
The Australian Signals Directorate's secure-by-design guidance reinforces the same posture. If a breach is likely to cause serious harm, the Notifiable Data Breaches scheme may also trigger assessment and notification duties. Regulated firms need to add their sector rules; APRA-regulated entities, for example, should map the spec to their applicable operational-risk and information-security obligations rather than treating this article as compliance advice.
The case against prompt-first development
Chat is useful for exploring a problem and interrogating a codebase. It is a poor place to hide the final contract for production work. Make the few decisions that matter visible before generation accelerates the change.
If you want to introduce spec-driven coding without building a heavyweight process, talk to DevProStudio. We can help shape a risk-weighted workflow around your repository, team and business systems.
About the author: Karl Lehnert is Director of DevProStudio.
Frequently asked questions
What is spec-driven coding?
Spec-driven coding gives an AI coding agent a reviewable set of requirements, constraints, acceptance examples and implementation tasks before it changes production code. The specification stays with the project and can be checked against tests and the final diff.
Is a specification just a longer prompt?
No. A useful specification is a versioned project artefact that people can review and tests can verify. A prompt is usually a transient instruction inside a conversation. The distinction is reviewability and persistence, not word count.
Does every code change need a full specification?
No. Match the artefact to the risk. A small bug may need one failing test and a constraint. A data-handling feature needs explicit permissions, privacy rules, failure behaviour and acceptance criteria.
Which AI coding tools support spec-driven work?
Kiro has a formal specs workflow. Claude Code and OpenAI Codex can also follow repository-based requirements, plans and tests when a team supplies those artefacts. The method matters more than the product label.