In an earlier article in this series, I asked what happens to the Business Analyst role when describing the thing increasingly starts to create the thing. Specification-driven development (SDD) takes that position further. What happens to software development when an AI agent can move from requirements and user stories through planning, implementation, testing and review?

Vibe coding showed how quickly software could be created through a conversation with an AI model. Structured vibe coding added the engineering controls needed to move beyond the prototype: source control, testing, security scanning, environments and release discipline. Specification-driven development appears to be the next step.

The agent is no longer simply responding to a series of prompts inside a controlled development environment. It is working through an explicit lifecycle held in the repository: constitution, requirements, user stories, plans, tasks, implementation, testing and convergence. This is not the abandonment of good software-development practice - it is the point at which those practices start becoming executable by the agent.

What is it?

Specification-driven development starts by making intent explicit before code is created or changed with the implementation progressing through a structured sequence:

Constitution: Establish the engineering principles, constraints and standards that apply to the project.
Specification: Describe the feature, user needs, functional requirements and success criteria.
Planning: Decide how the feature should fit into the architecture and identify the relevant components, interfaces and data.
Tasks: Break the work into bounded, traceable implementation and testing activities.
Analysis: Compare the specification, plan and tasks for gaps, contradictions and unsupported assumptions.
Implementation: Complete the work, usually one user story or testable slice at a time.
Convergence: Assess the resulting codebase against the requirements, plan, tests and constitutional principles, then identify what remains incomplete or unverified.

I’d argue that none of these activities are new - good development teams already establish standards, clarify requirements, plan changes, create tasks, test the implementation and review whether the result meets the intended need. Spec-driven development makes those practices part of an explicit workflow that the agent can follow.

The specification is no longer simply a document handed to a developer. It becomes an active development artefact. It influences the plan, produces tasks, guides implementation and provides the basis for testing and final review (and the documentation gets updated as the development moves along - it does not get out of sync). That is a meaningful change.

From documentation to an active control layer

Traditionally, specifications describe what developers are expected to build. Once implementation starts, the code often becomes the practical source of truth and over time, the two can (will) drift apart.

In a specification-driven approach, the specification remains active throughout the lifecycle. The agent continually uses it to determine:

what the feature is intended to do;
which user stories must be satisfied;
which constraints apply;
what work remains;
what tests are required;
whether the completed repository aligns with the original intent.

The specification begins to operate as a control layer around development, which does not make it automatically correct. A specification can contain an incorrect assumption. A retrieved requirement can misinterpret an existing behaviour or a detailed plan can describe the wrong solution very convincingly.

The value comes from creating a process in which the specification, plan, implementation and tests can be compared with one another. During my own experiment, that comparison found a difference between a generated planning artefact and the existing code. The plan expected one audit entity type, while the working application recorded another. Had the plan been implemented without analysis, the resulting feature could have silently returned incomplete information.

The process did not prove that the specification was right and the code was wrong. It checked both, established the codebase’s actual behaviour and corrected the planning artefacts before implementation continued - this discipline matters (and can be automated).

Brownfield development changes the problem

Much of the discussion around AI coding begins with an empty repository, most enterprise development does not. Organisations usually work with applications that already contain:

established architecture and integration patterns;
undocumented business rules;
historical workarounds;
inconsistent terminology;
partial test coverage;
technical debt;
behaviour that nobody is completely sure was intentional.

In a brownfield environment, the first task is not necessarily to specify something new, it may be to recover an accurate understanding of what already exists. I have used AI for this before. I once gave a model some old C code and asked it to extract functional requirements, non-functional requirements and test cases which it did remarkably well.

That was useful reverse engineering where the model read the code and produced documentation, but it did not materially change the repository or the development process. Spec-driven development goes further and the recovered understanding becomes part of the repository and starts guiding future planning, implementation and testing.

There is an important difference:

AI-assisted reverse engineering creates documentation from code. Repository-native specification-driven development creates an operating model around the code.

That could be particularly valuable for legacy modernisation and application sustainment. It may help organisations recover institutional knowledge that currently exists only in code or in the memories of a few experienced people. It also increases the consequences of getting the interpretation wrong. An incorrectly inferred requirement is no longer just a mistake in a document. It can influence future code.

What does it mean from a business perspective?

The biggest implication is not simply faster coding, it is that an agent may be able to perform a much larger portion of the development lifecycle, while people concentrate their attention at the points where judgement, accountability and risk matter most.

Development may become more disciplined, not less

AI coding is sometimes presented as an alternative to process. Describe what you want, let the model build it, and iterate until the application appears to work. Spec-driven development points in almost the opposite direction - even further than structured vibe-coding.

The easier it becomes to generate code, the more important it becomes to establish the intended outcome, constraints and acceptance evidence before implementation begins. Code generation may become inexpensive - understanding what should be built, how it should fit into the organisation and what evidence is required to trust it remains difficult.

This may make familiar development practices more important rather than less important and also make them economically practical on more projects. A small team may know that it should create better requirements, document architecture decisions, maintain traceability and build stronger test coverage when in practice, those activities are often reduced because of time and capacity. An agent can lower the effort needed to apply that discipline consistently.

The human role moves toward the phase boundaries

During my experiment, I was not directing every code change, I was largely moving through the phases (captured as Claude Skills), reading what Claude had produced and deciding whether it was ready to continue. That changed the nature of my involvement.

The agent performed much of the analysis, planning, task creation, implementation and testing. My attention moved toward questions such as:

Has the feature been understood correctly?
Does the specification represent the real user need?
Are the architecture decisions reasonable?
Has the agent distinguished existing behaviour from inferred intent?
Is the available evidence sufficient to proceed?
Has a discrepancy been resolved correctly or merely made internally consistent?
Should the agent be given authority to continue?

The human was not removed from the process - it became less operational and more judgement-based. That is a significant shift for developers, architects, Business Analysts, testers and technical leaders. Experienced practitioners may spend less time directing routine implementation and more time validating intent, architecture, exceptions, evidence and risk.

Within the maturity framework used throughout this series, this moves software development from Assist and Augment toward Advise and Act (not quite to Automate) The agent is not merely helping someone write code. It is analysing, planning and executing a multi-step process while the human controls progression. Full automation would require event-driven initiation, orchestration and substantially greater release authority.

Professional boundaries become less distinct

A specification-driven agent can move across activities that organisations traditionally distribute among several roles.

It can:

analyse an existing application;
identify features and user journeys;
write requirements and user stories;
propose an implementation plan;
identify architecture and data changes;
break the work into tasks;
generate code;
write tests;
compare the result with the original specification;
prepare a pull request.

That does not mean the agent has replaced the Business Analyst, architect, developer and tester - it means the boundaries between those activities become more compressed. The handoff from requirement to design to build to test becomes less visible because the same agent can move across all four.

For small teams, that could provide access to disciplines that previously required more people and more administrative effort. For larger teams, it raises a different question: how should responsibilities and approvals work when the technology can cross organisational boundaries faster than the operating model?

Requirements and tests move closer together

One of the strongest aspects of the process was the connection between user stories and testing. The user stories were not simply documentation, they organized the implementation and the evidence required to show that the feature worked.

The pattern became:

User story → implementation tasks → targeted tests → evidence of completion

This can reduce one of the persistent problems in software delivery: the distance between what someone requested, what a developer understood, what was implemented and what a tester later interpreted as correct (anyone remember the tyre swing progression).

The roles may remain separate, but the artefacts they work from become more closely connected. That should improve traceability and also expose ambiguity earlier, when it is less expensive to resolve.

Implementation may become more focused and more myopic

One observation from watching the implementation phase was that Claude appeared more myopic than it had during specification and planning. During the earlier phases, it seemed reflective - examined the codebase, surfaced ambiguities and compared alternatives.

Once it started implementing, it appeared tightly focused on the user story and tests immediately in front of it. That is only an observation from one exercise, not a general conclusion about coding agents and may also be a strength.

A well-defined plan allows the implementation agent to concentrate on bounded work, complete it, test it and move on reducing speculative redesign and unrelated changes.

The risk is that a focused agent may implement a poor plan very efficiently. Spec-driven development appears to divide the work into reflective and execution-focused phases. Thinking is concentrated in specification, planning and analysis. Implementation becomes more task-oriented. Convergence creates another reflective stage after the code has been produced. That may suit coding agents better than expecting them to reconsider the whole system continuously while editing individual files.

Assurance becomes more explicit

The convergence phase also changes the meaning of “done.” In my experiment, the agent assessed the current repository against functional requirements, success criteria, user stories, planning decisions and constitutional principles. It found that the feature had been implemented and supported by backend and web tests and identified remaining browser-level and live-stack verification.

That produced a more precise description of completion:

functionally implemented;
covered by unit and integration tests;
not yet fully verified through browser-level end-to-end testing;
not yet walked through against a live application stack.

Those distinctions matter to technology leaders. “Code complete,” “tests passing,” “end-to-end verified,” “release ready” and “production ready” are not the same thing. A structured agentic process can make those states more visible, provided the organisation does not allow a polished summary to replace independent evidence.

The repository becomes part of the governance record

The resulting pull request contained more than source code. It included the constitution, feature specification, user stories, plan, tasks, analysis findings, implementation, test results and unresolved convergence work at that point in time.

That provides a richer account of:

what was intended;
which decisions were made;
how the work was divided;
what was tested;
which assumptions changed;
what remains incomplete.

This can support established IT governance and service-management processes. For ITIL 4, it can provide stronger evidence for change enablement, service validation, release management and deployment decisions. For COBIT 2019, it can improve traceability, accountability and assurance over how technology changes are designed and introduced.

Procedural completeness can create false confidence

This is the main caution - a complete set of requirements, plans, tasks, tests and review findings can look very convincing. But all of those artefacts can align around the same incorrect assumption.

The risk is no longer only poorly written code, it’s a coherent, documented and well-tested implementation of the wrong interpretation. Human review therefore remains essential, particularly at the phase boundaries - the review cannot simply ask whether Claude completed the phase. It has to ask whether the work makes sense.

What do I do with it?

Don’t start by replacing the existing software-development lifecycle, start by testing whether specification-driven development can strengthen it.

Use one bounded brownfield feature or greenfield app. Choose something you understand well enough to evaluate. It should contain meaningful business behaviour, data and tests, but not create an unacceptable consequence if the agent misunderstands it.
Recover the current state before defining the future state. Ask the agent to identify existing user journeys, requirements, business rules, interfaces, dependencies and tests before proposing changes.
Separate evidence from inference. Require the agent to distinguish documented requirements, observed behaviour, inferred intent, technical constraints and unresolved contradictions.
Establish a project constitution. Define architectural constraints, security expectations, testing standards, compatibility requirements and rules about unrelated refactoring. The constitution should reflect the real environment rather than an idealized new application.
Treat phase transitions as review gates. Do not progress merely because the agent has produced an artefact. Review whether the assumptions, decisions and evidence justify moving forward.
Keep the work feature-based. One feature at a time makes the specification easier to validate, the implementation easier to control and the pull request easier to review.
Connect requirements directly to tests. Every important user story and acceptance criterion should influence the test evidence required for completion (SDD seems to drive this behaviour).
Maintain independent controls. The agent may create tests and workflows, but CI/CD, security scanning, code review and release authority should remain independently controlled.
Define completion precisely. Be clear about the difference between implementation, automated test coverage, browser verification, live-stack testing and production readiness.
Measure more than coding speed. Track defects, rework, review effort, test coverage, architectural divergence, time spent clarifying requirements and the quality of the resulting documentation. Faster code generation is only one part of the value.

The point here is not that Spec Kit or specification-driven development has invented a new way to build software. The lifecycle is familiar: understand the need, define the outcome, make the design decisions, implement the work, test it and verify that the result matches what was intended. What is changing is that an AI agent can perform a large proportion of that lifecycle using structured artefacts held alongside the code.

A useful way to think about it is:

Spec-driven development is good software-development practice made repository-native and agent-executable.

The opportunity is not simply more code, it is the possibility of greater consistency, traceability and capacity.

The agent may do much of the development work. People still have to provide judgement, challenge assumptions and decide whether the result should progress. The software development practice is changing.

AI and IT Departments, Part 7: Software Engineering is Changing - When Software Development Becomes Agent-Executable