What Is AI SDD and Why Engineering Teams Are Adopting It

AI adoption isn’t the question anymore. A 2025 developer survey found 84% of developers use or plan to use AI tools. More than half use them daily. AI-authored code now accounts for 27% of all production code across a sample of 4.2 million developers, up from 22% one quarter earlier.

The tools work. The organizational outcomes don’t always follow.

Faros AI analyzed telemetry from 1,255 teams. Teams with high AI adoption completed 21% more tasks and merged 98% more pull requests. But PR review time increased 91%. The code got written faster. Humans couldn't review it fast enough. AI-driven coding gains disappeared when review bottlenecks, brittle testing, and slow release pipelines couldn't match the new velocity.

The chart below shows the three metrics Faros AI tracked across 1,255 teams with high AI adoption: task completion, PR volume, and review time side by side.

This is Amdahl's Law applied to software delivery. A system moves as fast as its slowest link. AI changed the speed of one link. Everything downstream stayed the same.

METR ran the most rigorous study to date: a randomized controlled trial with 16 experienced open-source developers working on 246 real tasks in their own repositories. The finding surprised everyone. Developers using AI took 19% longer than those working without it. And the developers themselves estimated they were 20% faster. The perception gap is worth sitting with.

METR's early-2026 follow-up suggests the slowdown has likely reversed as tools improved, but the study couldn't confirm it cleanly due to selection bias. Developers who declined to participate said they didn't want to work without AI on half their tasks. The tools had become load-bearing.

The 2025 DORA Report adds another layer. AI adoption now shows a positive relationship with delivery throughput. But it shows a negative relationship with delivery stability. Speed without structure creates instability. Teams working in loosely coupled architectures with fast feedback loops see gains. Teams with tightly coupled systems and slow pipelines see none.

The pattern across all three datasets converges on one structural gap: the definition of work. AI changed the speed of execution. Planning, specification, and review stayed manual, informal, and bottlenecked. SDD addresses that gap.

Spec-Driven Development (SDD) means writing a structured specification before AI generates code. The spec becomes the source of truth for both humans and AI agents. Code derives from it. Tests validate against it. Documentation stays anchored to it.

The contrast of AI SDD with vibe coding is sharp. Vibe coding, a term coined by Andrej Karpathy and named Collins Dictionary's Word of the Year, works like this: prompt an AI, get code back, iterate until the output feels right. It's fast for prototypes. It falls apart at team scale because every developer's prompts encode different assumptions about what the system should do.

SDD replaces that with a shared contract. A spec typically lives as a structured markdown document, version-controlled alongside the code. It defines goals, constraints, acceptance criteria, and architectural decisions. Not a 40-page PRD. A lightweight, living artifact that both humans and AI agents read before writing a single line of code.

The table below compares how the two workflows sequence the same work and where the review effort lands in each.

An ArXiv paper published in early 2026 maps three levels of SDD rigor. Spec-first means writing the spec before implementation, then coding against it. Spec-anchored means the spec stays in sync with the code over the full lifecycle. Spec-as-source means code is generated directly from the spec and regenerated when the spec changes.

Most teams start at spec-first. The others require tooling maturity that’s still emerging.

The historical lineage is short. Test-Driven Development made tests the driver of implementation. Behavior-Driven Development made user-facing scenarios the driver. SDD makes the full specification the driver, and AI the executor.

What changed isn’t the idea of specifying before building. What has changed is that AI models now have sufficiently large context windows and strong enough code generation to make specs executable in practice.

GitHub released Spec Kit in September 2025. Kiro, Tessl, and other tools followed. The approach has moved fast from concept to tooling. Wikipedia added an article on SDD in March 2026. InfoQ, Thoughtworks, and EY have all published adoption analyses. The practice is early but accelerating.

SDD shifts the developer's primary output from writing code to defining intent. That single change ripples through planning, review, and how knowledge accumulates across features and hires — the three shifts below.

The most fundamental change is what a developer produces first. Without SDD, the first artifact is code. With SDD, it is a specification. That reordering changes everything downstream: what gets reviewed, when misalignment surfaces, and how AI agents receive their instructions.

At Cleveroad, we noticed this shift happening before we formalized it. Engineers working on complex features with AI agents were already writing out intent before prompting. They described constraints, expected behavior, and edge cases the same way they would sketch a design on a whiteboard with a colleague. The prompt came second. The spec came first. SDD turns that instinct into a shared team practice rather than a habit that lives inside one engineer's head.

In practice, this changes the planning phase first. Instead of a PM writing a ticket that a developer interprets and an AI agent prompts from, the flow becomes: requirements go into a spec, the spec gets reviewed, and then the AI generates code against it. The interpretation step moves from inside each developer’s head into a shared document that everyone (and every agent) reads before writing a line of code.

The most measurable workflow change is where the review effort sits. Without SDD, interpretation gaps surface during code review or QA, sometimes weeks after the original decision was made.

GitHub’s Spec Kit documentation uses a scenario that will feel familiar. A team builds a notification system. The PM thinks "notification preferences" means per-channel toggles. The backend engineer builds a single on/off switch. The frontend developer assumes OS-level notification integration. The designer mocks up something that would require rebuilding half of the user service.

Three sprints of work, and everyone made reasonable assumptions based on incomplete information. SDD surfaces those assumptions during a spec review, when changing direction costs keystrokes rather than entire sprints.

This is the change engineers feel most. They review intent before AI writes code, rather than reviewing code afterward. The Faros data on exploding review queues indicates that teams are still reviewing at the code level as code volume doubles. SDD rebalances where that effort sits. Reviewing a spec takes less time than reviewing the code it produces, and it catches misalignment earlier.

A spec doesn’t expire when the feature ships. Every spec becomes a reusable context for the next feature and the next AI agent session.

For onboarding, the impact compounds over time. New engineers read specs to understand what the system should do. They don’t reverse-engineer intent from implementation. Teams that build a library of well-maintained specs create institutional knowledge that doesn’t leave when developers do.

For agent orchestration, specs become load-bearing infrastructure. As AI agents move from autocomplete to autonomous task execution, they need a contract to execute against. The 2025 DORA Report found that 90% of organizations have adopted at least one internal developer platform, and platform quality directly correlates with an organization’s ability to get value from AI. Specs are part of that platform layer.

At Cleveroad, we’ve seen this in our own agentic AI development work. When we build long-running AI agent workflows for clients, the spec layer is not optional. Agents without a structured contract drift, produce inconsistent outputs, and require expensive human correction at the end of every run. The spec is the control surface.

SDD adoption is an organizational capability, not a tool install. Teams that run it on top of a broken delivery process don’t get a better process — they get a more visible one. Specs surface misaligned assumptions and slow review cycles, the moment you start writing them. The path to adoption runs in five steps: audit your foundation, run a pilot, read the six-week curve, decide on scope, and act on what the data tells you.

Before you write a single spec, check three things: test coverage, review cycle time, and CI pipeline speed. A structured code audit gives you an honest read on all three before you commit to SDD. If review turnaround exceeds 24 hours or test coverage sits below 60%, fix those first.

In our experience, the teams that struggle most with AI adoption aren’t the ones with the wrong tools. They’re the ones where review is already a bottleneck, and AI just doubles the queue. AI-coauthored code carries more defects on average than human-only PRs. Without fast, structured review, that gap widens silently.

Security and IP policy belong here, too. In practice, the clearest blocker we see isn’t technical. It’s the absence of a decision about what can go to an external model and who signs off on AI-generated code before it merges. Get that answered before any tooling decision.

Pick one team and one mid-complexity feature, one with cross-team dependencies or architectural implications. Write a spec: goals, constraints, acceptance criteria, architectural decisions. Hand it to an AI agent. Measure time to working code, review cycles, and defect count against a comparable feature built without a spec.

When we run this with clients, we typically scope the first pilot to two weeks and pick a feature the team already understands well. The point of the pilot is to build the spec-writing habit, not to validate the feature itself. A familiar codebase removes one variable.

Feature selection matters more than most teams expect. Too small, and the spec overhead exceeds the value before the pilot produces any signal. Too large and the pilot takes long enough that other variables contaminate the results. A feature that one engineer could build in a week without AI, but that touches two or more systems, tends to be the right size. That’s where the spec earns its cost in the first review cycle.

Set a six-week evaluation window and instrument AI usage at the repo level from day one. Track what percentage of merged code is AI-authored. Compare PR review time and defect density on AI-assisted versus human-only pull requests. Without this baseline, you can’t measure whether SDD changed anything.

The first two weeks will feel slower. Developers treat spec-writing as overhead before they see how much review time it saves downstream. By weeks three through six, specs get shorter and more precise as writers learn what level of detail AI agents actually need.

After the first month, the returns become measurable. In our engagements, the gains show up in review cycle time first: fewer clarification loops, fewer rewrites from misunderstood requirements. Only later do they appear in overall delivery speed. The compounding effect becomes visible around week six and grows from there.

Judge the pilot on two separate questions: is SDD the right fit for this type of feature, and is the team ready to run it well?

A team that finds SDD valuable on complex, cross-team features but skips it on simple bug fixes is using the tool correctly. Feature-level fit is expected and normal. That is not a reason to abandon it.

The harder call is team-level fit. If the overhead consistently exceeds the value across most feature types after six weeks, that points to a foundation problem, not a methodology problem. Step 1 is worth revisiting before any further rollout, and outside AI consulting can help you read that signal and decide whether to fix the foundation or adjust the approach.

Six weeks give you enough data to distinguish between two different failure modes. Fast review cycles with low code quality point to a problem with spec precision. Good specs with slow review cycles point to a review process problem that predates SDD. Keeping those two signals separate makes the next decision much cleaner, whether that’s expanding the rollout, adjusting the spec format, changing the tooling, or concluding SDD doesn’t fit the current workload.

The pilot gives you real delivery data against a real feature. That beats any benchmark from another team’s codebase.

Consistent value from AI-assisted development requires the same things that make any delivery process work: clear intent, structured review, and measurable outcomes. At Cleveroad, we build AI into software delivery for clients in regulated industries. The margin for drift is low. The standard for output is high.

Working with Cleveroad means working with an engineering team that includes Anthropic-certified engineers. Our team has delivered projects in compliance with HIPAA, GDPR, FDA, and ISO requirements. Environments where unstructured AI output is not an option.

Why engineering teams choose Cleveroad:

• 15+ years of software delivery experience across web, mobile, cloud, and AI/ML
• 280+ in-house engineers with domain knowledge across healthcare, fintech, logistics, and retail
• Full-cycle delivery: from discovery and architecture through deployment and post-release support
• Three cooperation models: Dedicated Team, Staff Augmentation, and Time & Material
• ISO 9001 quality management and ISO 27001 information security certifications
• AWS Select Tier Partner status within the AWS Partner Network

To demonstrate our expertise, we’d like to share one of our recent AI-assisted product delivery cases.

Proprio Cloud Solutions, a Michigan-based SaaS company, came to Cleveroad with two parallel product streams, a team at capacity, and a regression testing process that consumed a full working day per release cycle across three client environments.

Cleveroad embedded a four-person AI-assisted team built around Claude Code workflows. The full-stack engineer parsed the entire codebase with AI assistance and was contributing production code within two weeks, which is roughly half the typical ramp time for NetSuite's SuiteScript ecosystem. QA engineers generated Playwright test scripts directly from acceptance criteria, cutting script creation from a full day to two hours. The project manager used Claude Code to decompose features into sprint-ready stories, reducing planning prep from hours to minutes. The business analyst produced user guides and test flows with AI-assisted drafting, shortening documentation cycles from days to hours.

As a result, our client got four major platform releases shipped on schedule. The Field Service mobile MVP launched with offline-first architecture and real-time NetSuite sync. Sprint output increased by 35% compared to a conventionally staffed team of the same size, with code quality holding steady throughout.

• See more details in our AI-Assisted ERP Development for NetSuite SaaS Platform case study

Here’s what Luke Abbott, CTO at Proprio Cloud Solutions, says about this cooperation and why he recommends Cleveroad’s AI-assisted development service: