For more than two decades, Agile and DevOps have shaped the way modern software is created.
Agile attempted to solve a fundamental problem with traditional software development: requirements changed faster than large development projects could accommodate them. Instead of spending months designing a system before developers began coding, Agile divided development into smaller increments, organized work into backlogs and sprints, and encouraged frequent interaction between developers, product owners, and customers.
DevOps addressed another problem. Development teams could create software faster, but getting that software tested, deployed, monitored, and maintained remained slow and fragmented. DevOps attempted to remove the wall between software development and IT operations through automation, continuous integration, continuous deployment, infrastructure-as-code, monitoring, and shared operational responsibility.
Both were enormous improvements for human software teams.
But software development is undergoing another fundamental change.
The limiting factor in software production is increasingly no longer how quickly humans can type code.
AI can now generate functions, APIs, database schemas, user interfaces, tests, documentation, migrations, configuration files, and sometimes entire applications in minutes.
The new bottleneck is defining precisely what the software should do.
That shift is giving rise to a new methodology:
Spec-Driven AI Development — SDAD.
SDAD changes the fundamental unit of software development.
In Agile, the central unit of work is often the ticket, user story, task, or sprint.
In DevOps, attention expands to the pipeline that moves code from development into production.
In SDAD, the central artifact is the machine-readable software specification.
The specification becomes the contract between human intention and machine implementation.
That seemingly simple change has enormous implications for how companies organize software development.
What Is SDAD?
Spec-Driven AI Development is a software-development operating model in which humans primarily define intent, constraints, architecture, requirements, acceptance criteria, and business rules, while AI systems perform a substantial portion of implementation, testing, analysis, documentation, and maintenance.
An emerging academic formulation calls the approach Spec-Driven Agentic Development, describing a lifecycle consisting of intent capture, machine-readable specification, agentic synthesis, independent verification, and human authorization. The important principle is that AI speed does not remove engineering discipline. It moves much of that discipline upstream into the specification. (arXiv)
Industry implementations are moving in the same direction. Viome, for example, has publicly described an SDAD approach in which specifications are version-controlled, AI generates significant amounts of code from those specifications, and humans remain accountable for the outcome. (LinkedIn)
SDAD therefore does not mean:
Give an AI a vague prompt and let it build whatever it wants.
That is almost the opposite of SDAD.
A mature SDAD organization creates a highly controlled pipeline:
Idea → Business Decision → Product Specification → Development Specification → AI Implementation → Automated Verification → Independent AI Review → Human Approval → Staging → Production → Monitoring → Specification Update
The specification travels through the entire lifecycle.
Why Agile Begins to Break Down in an AI-Native Development Environment
Agile was designed around the economics of human development.
Suppose a feature requires three developers two weeks to implement.
It makes sense to spend relatively little time specifying it initially and allow the development team to discover details during the sprint.
But imagine that an AI system can create the first implementation in 20 minutes.
Suddenly the economics reverse.
A poorly written requirement may result in:
- ten incorrect implementations,
- repeated prompting,
- architectural inconsistency,
- duplicated functionality,
- security vulnerabilities,
- tests validating the wrong behaviour,
- and developers spending hours repairing AI-generated code.
The coding is inexpensive.
Ambiguity becomes expensive.
SDAD therefore shifts engineering effort from:
writing code
toward:
defining systems.
The question becomes less:
How quickly can our development team implement this feature?
and more:
How precisely can we describe what the system must do?
SDAD Does Not Mean Throwing Away Everything DevOps Taught Us
It would be a mistake to interpret SDAD as meaning that CI/CD, containers, automated deployment, infrastructure-as-code, monitoring, logging, security scanning, or rollback systems disappear.
Those technologies become even more important.
What changes is the organizational philosophy around them.
Traditional DevOps might involve:
Developer → Git → Build → Test → DevOps Pipeline → Production
An SDAD environment becomes closer to:
Approved Specification → AI Engineering System → Generated Code + Tests + Documentation → Verification Agents → CI/CD → Staging → Human Release Gate → Production
The DevOps pipeline remains.
But DevOps stops being the overall development methodology.
It becomes infrastructure inside the SDAD system.
A Complete SDAD Workflow
Organizations adopting SDAD need more than an AI coding subscription.
They need an operating system for software development.
The following model illustrates how such a system can be established.
Stage 1: Idea Creation
Every software change begins with an idea.
Ideas may originate from:
- customers,
- customer support,
- sales,
- management,
- developers,
- analytics,
- security reviews,
- competitors,
- AI analysis,
- regulatory requirements,
- production incidents,
- or strategic planning.
The first mistake organizations should avoid is immediately sending the idea to an AI coder.
The idea first enters an Idea Intake System.
Each proposal should answer a small number of questions.
Problem
What problem are we attempting to solve?
User
Who experiences this problem?
Business impact
What happens if we solve it?
Evidence
Why do we believe the problem exists?
Proposed outcome
What should become possible that is not possible today?
Constraints
Are there legal, security, financial, compatibility, performance, or architectural restrictions?
Notice that this document does not need to describe exactly how the feature will be programmed.
At this stage we are defining intent.
Stage 2: AI-Assisted Idea Analysis
The idea can now be analyzed by an AI product-analysis agent.
The AI should examine the proposal against:
- the existing product roadmap,
- current features,
- architecture,
- customer requests,
- known bugs,
- technical debt,
- competitive positioning,
- security implications,
- estimated complexity,
- dependencies,
- and business objectives.
The AI can generate an Idea Assessment Report.
For example:
Strategic value: High
Customer value: High
Technical complexity: Medium
Security exposure: Low
Architecture impact: Medium
Estimated implementation scope: 14 components
Major dependency: Authentication service
Recommendation: Proceed to specification
This dramatically improves the quality of proposals reaching leadership.
Stage 3: Leadership Decision
Leadership should not be reviewing code.
Leadership should be deciding what deserves to exist.
A product council or management team reviews the proposal and chooses one of several states:
- Reject
- Defer
- Research
- Prototype
- Approve for specification
- Emergency implementation
The approved idea receives a unique identifier.
For example:
FEATURE-AUTH-027
From this point forward, everything associated with the feature can reference that identifier.
Stage 4: Create the Product Requirements Document
The next artifact is the PRD — Product Requirements Document.
The PRD describes the feature from the perspective of the business and user.
It should contain:
Purpose
Why does this capability exist?
Personas
Who will use it?
Functional requirements
What must users be able to do?
Business rules
What restrictions apply?
Permissions
Who can perform which operations?
Workflows
What happens step by step?
Failure states
What should happen when something goes wrong?
Acceptance criteria
How do we know the feature works?
Non-functional requirements
Performance, accessibility, reliability, scalability, privacy, compliance, and security expectations.
The PRD should avoid unnecessary implementation decisions.
It defines what.
The next document defines how.
Stage 5: Build the Development Specification
This is the core of SDAD.
The Development Specification — or DevSpec — converts the approved product requirement into instructions precise enough for an AI engineering system to implement reproducibly.
A mature DevSpec might contain:
feature_id: FEATURE-AUTH-027
name: Multi-Factor Authentication
objective:
Allow account owners to enable TOTP-based MFA.
dependencies:
- authentication-service
- user-profile-service
database_changes:
table: users
add_fields:
- mfa_enabled:boolean
- mfa_secret_encrypted:text
api:
- method: POST
endpoint: /api/mfa/setup
authentication: required
- method: POST
endpoint: /api/mfa/verify
authentication: required
security:
encryption:
mfa_secret: AES-256
rate_limit:
verification_attempts: 5
window: 15m
acceptance_tests:
- valid_code_allows_login
- invalid_code_rejected
- expired_code_rejected
- disabled_user_bypasses_mfa
Real specifications can be considerably larger.
The important characteristic is that the document is both:
human understandable
and
machine interpretable.
Formats might include Markdown plus YAML, JSON, XML, structured Markdown, schemas, OpenAPI specifications, database definitions, diagrams, or a combination.
Stage 6: Add the UI Specification
User-interface requirements should not be left to the coding model's imagination.
A UI specification should define:
- pages,
- dialogs,
- navigation,
- fields,
- labels,
- validation,
- responsive behaviour,
- accessibility,
- design-system components,
- empty states,
- loading states,
- success messages,
- error messages,
- confirmation dialogs,
- and role-specific visibility.
The specification may reference screenshots, Figma designs, components, CSS rules, or an existing design system.
For each screen, define states explicitly.
For example:
screen: MFA Setup
states:
disabled:
show:
- explanation
- enable_button
setup:
show:
- qr_code
- manual_secret
- verification_input
enabled:
show:
- status_enabled
- disable_button
- regenerate_backup_codes
AI becomes much more reliable when interface behaviour is specified rather than implied.
Stage 7: Create the Test Specification Before Coding
One of the most important changes in SDAD is that testing should be specified before implementation.
The TestSpec defines what evidence must exist before the feature can be considered complete.
Tests may include:
Unit tests
Does each component behave correctly?
Integration tests
Do components communicate correctly?
API tests
Do endpoints satisfy their contracts?
UI tests
Does the interface behave correctly?
Security tests
Can authorization, validation, or rate controls be bypassed?
Regression tests
Did the feature break existing behaviour?
Performance tests
Does the feature perform adequately under expected load?
Failure tests
What happens when services, databases, or external APIs fail?
Boundary tests
What happens at minimum, maximum, null, empty, malformed, expired, or unexpected values?
An AI coding agent should not be allowed to redefine the tests simply because its implementation fails them.
That separation is critical.
Stage 8: Freeze the Implementation Contract
Once the PRD, DevSpec, UISpec, and TestSpec have been approved, they collectively form the Implementation Contract.
This becomes the source of truth.
The coding agent receives:
- repository context,
- architecture documentation,
- coding standards,
- approved libraries,
- security policies,
- PRD,
- DevSpec,
- UISpec,
- TestSpec,
- API contracts,
- database rules,
- and deployment constraints.
Now the AI can begin implementation.
Stage 9: AI Generates the Implementation Plan
Before writing code, the coding agent should produce a plan.
For example:
- Add database migration.
- Extend authentication model.
- Create MFA service.
- Add setup endpoint.
- Add verification endpoint.
- Modify login pipeline.
- Build MFA setup UI.
- Add audit logging.
- Implement unit tests.
- Implement integration tests.
- Run regression suite.
- Update documentation.
Another AI agent—or a human engineer—reviews this plan against the specification.
Only then does implementation begin.
Stage 10: Agentic Coding
The coding agent now works through the implementation plan.
Unlike basic AI-assisted programming, the human developer does not necessarily prompt the AI file by file.
An autonomous engineering agent may:
- inspect the repository,
- identify affected components,
- create a branch,
- write code,
- modify schemas,
- generate migrations,
- create tests,
- execute tests,
- examine failures,
- repair code,
- rerun tests,
- update documentation,
- and produce a pull request.
Every change remains traceable to the feature specification.
Stage 11: The AI Must Not Grade Its Own Homework
This is a crucial SDAD principle.
The agent that created the implementation should not be the only agent verifying it.
A separate Verification Agent receives:
- the specification,
- the resulting code,
- and the test results.
It asks:
Does this implementation actually satisfy the specification?
That agent can search for:
- missing requirements,
- unhandled edge cases,
- security weaknesses,
- architectural violations,
- undocumented behaviour,
- dead code,
- unnecessary dependencies,
- insufficient test coverage,
- and inconsistencies between implementation and specification.
This separation between synthesis and verification is also central to emerging formal descriptions of SDAD. (arXiv)
Stage 12: Security Agent Review
Security should be another independent gate.
The security agent examines:
- dependency vulnerabilities,
- authentication,
- authorization,
- input validation,
- SQL injection,
- command injection,
- XSS,
- CSRF,
- insecure secrets,
- encryption,
- logging exposure,
- privilege escalation,
- API abuse,
- insecure defaults,
- and supply-chain risks.
For high-risk software, adversarial AI agents can actively attempt to break the application.
The development AI is effectively challenged by an AI red team.
Stage 13: Staging Deployment
Only after automated verification passes should the feature enter staging.
The staging system should closely resemble production.
The deployment pipeline automatically:
- Builds the software.
- Creates required infrastructure.
- Applies migrations.
- Loads test data.
- Executes smoke tests.
- Executes integration tests.
- Executes UI automation.
- Executes security scans.
- Executes performance tests where appropriate.
- Generates a release report.
The report should summarize the evidence supporting release.
Stage 14: Human Acceptance Testing
SDAD does not eliminate humans.
It changes where human judgment produces the greatest value.
Humans should evaluate things machines cannot reliably determine from code alone:
- Is the workflow intuitive?
- Does the product solve the intended problem?
- Is the interface understandable?
- Are business rules correct?
- Does the behaviour match customer expectations?
- Are there unforeseen consequences?
- Should this feature actually be released?
Human authority becomes more important, not less.
AI may generate the software.
Humans authorize the outcome.
Stage 15: Production Release
Production deployment should use the automation practices pioneered by DevOps:
- CI/CD,
- blue-green deployment,
- canary deployment,
- feature flags,
- database migration management,
- automatic rollback,
- centralized logging,
- observability,
- infrastructure-as-code,
- and secrets management.
SDAD does not abolish these practices.
It incorporates them.
The difference is that release automation is now driven by a formally defined specification and verification process.
Stage 16: Production Becomes Part of the Feedback Loop
Once deployed, AI can continuously analyze production behaviour.
Agents can monitor:
- logs,
- exceptions,
- performance,
- resource usage,
- failed transactions,
- unusual user behaviour,
- support tickets,
- security alerts,
- customer feedback,
- and feature adoption.
Suppose users repeatedly abandon a workflow at step three.
The AI might automatically create an improvement proposal:
Observed Problem: 38% abandonment at payment verification.
Probable Cause: Verification instructions unclear.
Recommended Action: Simplify verification screen.
That proposal re-enters the SDAD idea pipeline.
The lifecycle closes.
Stage 17: Keep the Specification Synchronized With Reality
One of the worst problems in conventional development is documentation decay.
The code changes.
The documentation does not.
Eventually nobody knows whether the documentation or software is correct.
SDAD cannot tolerate this because future AI development depends upon accurate specifications.
Every approved change therefore modifies both:
the software
and
the specification describing the software.
The repository might contain:
/specs
/product
/architecture
/features
/ui
/security
/testing
/api
/src
/tests
/infrastructure
Specifications are versioned alongside code.
A pull request changing behaviour without updating the appropriate specification should fail governance checks.
What Happens to the Agile Sprint?
In many SDAD environments, it becomes unnecessary.
A feature does not need to wait for a two-week sprint boundary.
Once its specification passes the approval gate, development can begin.
Some features may take three hours.
Some may take three days.
Some may require weeks.
The controlling mechanism becomes gates rather than sprints.
A typical SDAD board might therefore look like:
Idea → Analysis → Leadership Review → Specification → Spec Review → Ready for AI → Implementation → Verification → Security → Staging → Acceptance → Released
This is fundamentally different from organizing development around sprint calendars.
The New Role of the Software Developer
Perhaps the greatest change created by SDAD concerns developers themselves.
Developers do not disappear.
But their highest-value responsibilities move upward.
The SDAD engineer spends more time on:
- system architecture,
- requirement analysis,
- specification engineering,
- AI orchestration,
- edge-case identification,
- technical governance,
- security,
- performance,
- verification,
- and production analysis.
Typing syntax becomes a smaller part of the profession.
Understanding systems becomes a larger part.
The best engineer may increasingly be the person capable of describing a complex system with enough precision that an AI can build it correctly.
The New Role of QA
QA also changes significantly.
Instead of spending most of its effort repeatedly executing test cases, QA becomes responsible for defining verification strategy.
QA engineers design:
- TestSpecs,
- acceptance criteria,
- boundary conditions,
- adversarial cases,
- regression requirements,
- quality metrics,
- and release gates.
AI executes enormous test suites.
Humans determine whether those are the right tests.
The New Role of Product Management
Product management becomes closely intertwined with specification engineering.
A vague user story such as:
As a user, I want better account security.
is inadequate for autonomous AI development.
Product teams must progressively transform business intent into explicit behaviour.
The product organization therefore becomes responsible for reducing ambiguity before implementation begins.
A Practical SDAD Team Structure
A small SDAD software organization might eventually look like this:
Product Lead
Determines what should be built.
Domain Specialist
Defines what correct behaviour means.
Specification Engineer
Converts requirements into machine-readable specifications.
Software Architect
Maintains architectural integrity.
AI Development Agent
Implements approved specifications.
Verification Agent
Independently analyzes implementation.
Security Agent
Tests security and compliance.
QA/Quality Engineer
Defines testing strategy and acceptance requirements.
Platform Engineer
Maintains CI/CD, infrastructure, production systems, and observability.
Human Release Authority
Accepts responsibility for production release.
One human may perform several of these roles in a smaller organization.
Several AI agents may operate simultaneously.
The SDAD Rule: Change the Specification, Not the Prompt
Perhaps the most important operational rule in the entire methodology is this:
If the AI builds the wrong thing, do not merely improve the prompt. Improve the specification.
Suppose an AI implements a feature incorrectly because the DevSpec never explained what happens when an account is suspended.
The normal conversational AI response might be:
Oh, also make sure suspended users can't do this.
That may repair today's code.
But the knowledge disappears into a chat transcript.
In SDAD, the correct response is:
- Update the specification.
- Add the missing acceptance criterion.
- Add the corresponding test.
- Regenerate or repair the implementation.
- Verify again.
The organization becomes progressively smarter because every discovered requirement becomes permanent institutional knowledge.
Measuring SDAD Performance
Traditional development metrics such as story points and developer velocity become less meaningful.
SDAD organizations should instead consider measures such as:
Specification completeness
How often does implementation reveal missing requirements?
First-pass implementation success
What percentage of generated implementations pass verification without major revision?
Requirement-to-release time
How long from approved specification to production?
Escaped defect rate
How many faults reach production?
Spec-to-code traceability
Can each major behaviour be connected to an approved requirement?
Test coverage by requirement
Does every acceptance requirement have corresponding evidence?
AI repair cycles
How many implementation-repair iterations are required?
Human intervention rate
How frequently must developers manually repair generated code?
The objective is not to maximize the amount of code AI writes.
The objective is to maximize correct software produced from approved human intent.
Moving From Agile to SDAD
Companies should not attempt the transition overnight.
Begin with one development team.
Choose a medium-sized feature.
Create four artifacts:
- PRD — what the product must accomplish
- DevSpec — how the system must behave technically
- UISpec — how users interact with it
- TestSpec — how correctness will be proven
Place those documents under version control.
Have AI implement the feature.
Use another AI model or agent to review the implementation independently.
Measure the results.
Then improve the specification process.
After several projects, organizations will begin discovering their own reusable specification standards.
Eventually, an internal SDAD framework emerges.
From Continuous Integration to Continuous Specification
DevOps introduced the world to Continuous Integration and Continuous Deployment.
SDAD may introduce another concept:
Continuous Specification.
The software specification becomes a living digital model of the application.
Customer feedback changes the specification.
Security discoveries change the specification.
Production behaviour changes the specification.
New features change the specification.
Architecture changes the specification.
AI continuously consumes that specification to modify the underlying software.
At that point, the organization's most important software asset may no longer be its source code alone.
It may be the structured description of exactly what that source code is supposed to accomplish.
Beyond Agile
Agile solved the software-development problems of an era dominated by human programmers.
DevOps solved the deployment and operations problems created when those teams began shipping software continuously.
SDAD addresses the emerging problem of a world in which machines can produce software faster than humans can accurately describe it.
The progression can therefore be viewed as:
Waterfall:
Plan everything, then build it.
Agile:
Build incrementally and continuously refine requirements.
DevOps:
Continuously build, deploy, operate, and observe.
SDAD:
Precisely specify intent, allow AI systems to implement it, independently verify the result, and continuously synchronize specification, software, and production reality.
SDAD therefore isn't simply Agile with ChatGPT added.
Nor is it merely DevOps with an AI coding assistant.
It represents a different allocation of human and machine responsibility.
Humans decide what should exist.
Humans define constraints.
Humans describe expected behaviour.
Humans determine what constitutes acceptable evidence.
Machines increasingly perform implementation.
Machines execute verification at enormous scale.
Machines analyze production.
And humans retain authority over the final decision.
The age of AI does not eliminate software engineering discipline.
It makes discipline more important.
But that discipline moves away from manually creating every line of source code and toward the far more fundamental task of precisely describing the system we want machines to create.
That may ultimately be the central idea behind Spec-Driven AI Development:
The specification becomes the product blueprint, AI becomes the implementation engine, verification becomes continuous, and human judgment becomes the governing authority.
And that is why SDAD has the potential to become not merely another development technique, but the successor operating model to Agile and traditional DevOps for the AI-native software organization.