Spec-Driven Development (SDD): the foundation of AI-native delivery

In the previous articles we talked about how buyers should:

• Assess the AI-readiness of the software outsourcing companies they want to buy

• Develop a value creation plan to prepare for the AI transformation

• What the target Org Design should look like

(links to the previous articles in the comments)

In this article we’ll delve into more technical details: what must actually change in the SDLC so that companies can take full advantage of AI?

There are a lot of small changes that must happen, but it would take too long to talk about every single one of them.

Instead, we’ll focus on one of the most important changes: the shift towards Spec-Driven Development (SDD).

SDD is not the entire AI SDLC, but it is one of the clearest examples of how software delivery must change when AI agents start doing more of the implementation work.

At its heart, SDD sounds simple: use an explicit, version-controlled specification to guide implementation. In practice, it requires SWEs to spend much more time defining intent, constraints, architecture and acceptance criteria before agents begin writing code. That’s a difficult shift for traditional teams.

After reading this article, you will understand why and you will know how to quickly evaluate whether a team is on its way to be AI-native in its SDLC.

The simple version of SDD

Most SWEs are now using AI to write code. The difference is in how they do it. You’ll generally see these broad categories:

• The vibe-coder way: a non-SWE turned amateur developer uses a tool to generate some code, that generates something that looks nice (eg a website demo for example)

• The naive AI engineer: a traditional SWE uses AI to debug, autocomplete and mostly prompt AI to write code that he can then copy-paste into his codebase.

• The YOLO way: SWEs using AI to entirely code things by successive prompting. No hand-written code anymore, but not much review either. Fast and dangerous.

• The professional AI SWE way: use AI to help define the problem, produce a structured Spec and plan the implementation. Agents then work within clear architectural, testing and security constraints. Their changes are traceable, reviewed and validated, so humans retain oversight and can understand why the system was changed.

The latter is what I personally refer to when I say “Spec Driven Development”. It radically changes the SWE role, shifting it from writing code to being a system designer.

As you recall from the previous articles, Business Analysts (BA) used to write specs, broken down into neat stories / tickets that typically go into Jira and that SWE just go and implement.

But in the new AI SDLC org design, the Deployment Strategist and AI SWE build the specs directly, using AI. Then AI uses such specs to write the code, test and deployment scripts.

But what goes into a spec? Let’s take a closer look.

What goes into a “Spec”?

Think of the Spec as one of the sources of truth all coding agents must read when they write code. It records what needs to be built, the constraints that apply and how success will be evaluated. It works alongside architectural decisions, repository rules, test requirements and implementation plans to prevent agents from making inconsistent choices.

So the spec must typically cover:

• The business and technical context

• The problem to be solved and the expected behaviour

• Detailed functional requirements and acceptance criteria

• Architectural, security and compliance constraints

• Non-functional requirements, such as performance and reliability

• What is in scope and out of scope

• Known risks, dependencies and unresolved questions

• The tests or evidence required to confirm that the implementation works

A separate technical plan then describes the technical approach, affected components, work packages, sequencing and likely files to be changed. These documents should remain version-controlled and be updated when implementation reveals new information.

This is somewhat of a simplification, but the goal is to give the non-technical reader an overview of what “the Spec” is. Each team has its own template for each client project, but the principles are the same.

This should trigger the following question.

If AI writes such specs, how does one make sure that it was written properly to start with?

Enter: Human-In-The-Loop (HITL).

Human-In-The-Loop (HITL)

HITL is a collaboration pattern between humans and AI. As the name implies, we want to keep a human responsible for a certain outcome / output (in this case, the spec).

The role of the AI SWE is therefore to make sure they understand the problem space, the client’s business context, the technical trade-offs to make, the different kind of solutions that could be implemented, etc.

Equipped with that understanding, the AI SWE uses AI to draft, challenge and refine the specification. The team then reviews it against the business requirements, architectural constraints, risks and acceptance criteria before implementation begins.

Like I said earlier, there are a lot of considerations to take into account to know whether a spec is ready-to-go or not.

Because it is a completely different “Spec” than what BA used to hand off to SWE, one needs to first understand what kind of problem the SDD approach solves in order to know what good looks like, and how it affects the way software is being built.

What SDD solves and what it changes in the way we build software

There are several reasons why we need Specs

• To have a single source of truth on what needs to be built, why, how it’s been built, and be able to make informed decisions when changes are required (and not just say “Why don’t we ask AI to find where the problem is and fix it?” That’s the YOLO guy). Note that the spec will evolve over time as do the client’s requirements

• To divide the work without losing the overall intent. Large changes usually need to be broken into smaller work packages that agents can implement and test independently. These packages should remain linked to a higher-level specification and implementation plan, so local decisions do not contradict the architecture or the intended business outcome

• To standardize the development process across distributed SWEs. Everyone must stick to it. If not, you end up with different practices that can create conflicts

• To really spend time doing what SWE should really be doing: thinking through the client’s problem and actually solving it, so that the client gets value

Once that source of truth is established, AI coding agents can start getting to work.

Here’s a simplified and stylized example of how a typical AI SDLC flow looks like. Note that this is illustrative of developing a piece of software for a client, not of building or fine tuning an AI model.

A simplified workflow

1. Prepare the AI working environment

First, the company establishes rules for how AI agents are allowed to work, including:

• Coding and documentation standards

• Rules for testing and validation

• Approved tools

• Security restrictions

• Actions that require human approval

• Etc.

These controls should be built into the company’s systems rather than depending on individual employees writing good prompts.

2. Define the work clearly

Before coding begins, the team decides on what goes into the spec, including all the things listed above. This is the most important part of the work.

3. Break the work into smaller units

AI SWE then decides how to split the work into “packages” so that work can be carried out as independently as possible by AI coding agents, allowing parallel agents to work on parallel things whenever possible.

4. Let agents implement and test

The AI agent writes the code, updates documentation and runs the required tests.

The style, conventions and best practices that AI coding agents need to follow should be described in step #1. Without them, the codebase becomes messy very quickly.

5. Use AI to review AI-generated work

A separate AI reviewer can compare the implementation with the original specification, check for obvious problems and identify missing tests or risks.

This reduces the amount of basic checking required from engineers, but does not remove the need for human review.

6. Apply human judgment

During review, the responsible AI SWE decides whether the work is ready, requires a small correction or needs to be reconsidered more fundamentally.

7. Integrate and push to the common repository

Approved work is integrated into the common repository. Automated tests, security checks and AI-assisted code review can then examine the combined change before it is merged.

A SWE Lead remains accountable for ensuring that the change meets the agreed functional, architectural, security and release criteria.

The work then moves through staging, acceptance testing and controlled deployment. Production monitoring, rollback procedures and user feedback remain part of the SDLC, and may require the specification and tests to be updated again.

In this simplified but directionally correct example, notice a few things about the role of the AI SWE:

• He has spent most of his time thinking about the problem/solution (the spec), setting up the right environment for the AI Coding agent to do its work and coordinating with the team. He has spent very little time (if at all) writing code.

• Judgment and experience are becoming premium: the AI SWE must decide on how to organize the work to be done, make architectural choices, integration choices etc. This only comes with actually working with AI coding agents on real-world problems

• While the coding agents are working, the AI SWE is coordinating other coding agents to do parallel work, reviewing and integrating works already done by other agents, perhaps working on the next spec or helping out colleagues.

• He has not lost time in endless meetings trying to clarify requirements from BAs. Instead, he is spending much time coordinating with other AI SWE and getting inputs from functional experts to make sure the functional spec are correct (eg a SWE may not know all the intricacies of credit scoring and will need the input of a credit scoring subject matter expert for example)

• His scope has grown from “writing code” to “understand the problem / solution space”, “managing the environment around AI Agents”, “making decisions on how to architect things” and “making decisions on deployment models”.

In other words, the AI SWE has a totally different skillset and mindset than the traditional SWE.

That’s why it’s so hard to adapt (not so long ago, SWEs wrote 90% of the code), and that is also why it is an exciting opportunity for those who do.

We already shared the ideal profile required to be an effective AI SWE. Hopefully you have a better appreciation of the type of people you will need by now.

In terms of process, how do you know if the company you intend to buy is AI-SDLC-ready?

What buyers should be looking for in AI-SDLC-readiness

A company has not adopted an AI SDLC simply because its SWE use Claude Code.

A more advanced company should be able to demonstrate:

• A repeatable method for specifying work before agents begin

• Repository-level rules covering coding conventions, testing, security and documentation

• Automated tests, security gates and AI-assisted processes

• Defined human approval points based on the risk of the change

• Processes for coordinating multiple agents without creating integration conflicts

• Version-controlled records of specifications, implementation plans and agent-generated changes

• Measures of delivery speed, defects, rework, rollback and client outcomes

Most importantly, a mature company has a leadership team capable of redesigning engineering roles and workflows around AI and keep evolving it as the technology progresses.

During due diligence, buyers should ask to inspect a completed change from beginning to end: the original requirement, specification, agent instructions, implementation, test results, reviews, production release and any subsequent corrections. This is more revealing than a repo showing a cool AI-made demo.

For a thorough assessment, buyers need external evaluators who have worked with agent-based delivery in real software environments. Tool demonstrations and management presentations are not enough. The evaluator should examine whether the underlying controls, workflows and delivery outcomes exist in practice.

Closing the loop on AI SDLC

A well-designed AI SDLC will increase delivery capacity, shorten implementation cycles and reduce some forms of rework.

Clients will definitely start noticing. Whether or not this translates into higher revenue and long-term contracts is another commercial question. For now, you know what it takes to deliver, and the kind of mindset shift required among the SWEs.

In combination with our other articles on the transformation of the software outsourcing industry, you should now have the general direction on what it takes to become an AI consulting + delivery company, including:

• What to assess during buyers’ due diligence

• What to include in the value creation playbooks

• How to transition to an AI SDLC Org Design

• What profiles you need for the new team

Now it’s time to find the right company to buy, and transition a legacy business into an AI-driven revenue. We wish you lots of success, and if you need help along the way, email us at info@keystone-one.co.

Until next time!