A new way of building software

Sooner or later, someone in a leadership meeting asks whether AI means the business can build its own software now. One approach behind that question is called spec-driven development, or SDD. If you haven't come across it yet, you're in good company. It's still new, and most organizations are just beginning to explore it.

The idea is simple. Before an AI coding assistant writes any code, the team writes a clear, structured description of what they want built and how it should behave. That description, the specification or "spec," becomes the guide the AI follows and the standard the finished code is checked against.

It's moving quickly into the mainstream. The largest technology companies are building it directly into their developer tools. Amazon launched Kiro, an AI development environment organized around specs. GitHub, part of Microsoft, released the open-source Spec Kit, and Microsoft now offers training on SDD for enterprise developers. Google introduced Conductor to bring SDD to its Gemini and Antigravity tools. When the companies behind the tools your developers already use all move in the same direction, it tends to reach enterprise teams sooner rather than later.

Early assessments have been cautious. When Thoughtworks first added SDD to its Technology Radar in November 2025, it placed the technique in "Assess" and warned that some tools generate specs too long to review well. Its April 2026 edition was warmer, reporting real value from tools like GitHub Spec Kit, though still in "Assess."

Because much of a spec is written in plain language, SDD is sometimes described as a way for anyone to build software. Business leaders have heard that promise before, from no-code tools. The conclusion is understandable, but it isn't quite what SDD is. What SDD changes is how business, technical, and QA teams work together, and which part of the spec each one brings to the table.

"Who owns the spec?" is the wrong question

As SDD gains traction, a central debate has formed: Who should own the specification? Some argue that business leaders should take ownership because specifications capture business requirements and intended outcomes. Others argue that engineers must remain accountable because specifications also define technical decisions that require specialized expertise.

Each side is partly right, but both are approaching the specification as a single document when, in practice, it often consists of multiple files serving different purposes. For leaders, the more useful question isn’t who owns the spec, but who should be accountable for each part of it.

What's inside a spec

There's no single standard yet for what a spec contains. One clear example comes from the Spec-Driven Development with Coding Agents course from DeepLearning.AI and JetBrains.

It starts with a project "constitution" of three files that rarely change:

• mission.md: why we're building this, for whom, and what's in scope
• roadmap.md: the phases of work, in the order they'll be built
• tech-stack.md: the languages, frameworks, and technical constraints the team works within

Each feature then gets its own folder with three more files:

• requirements.md: the feature's scope, key decisions, and context
• plan.md: the structured tasks the AI agent will carry out
• validation.md: how the team defines success and confirms the work is ready to release

Other leading tools name these files differently, but the structure is the same: a few stable files that capture why the project exists and the technical standards it follows, plus a set of files for each feature describing what to build, how to build it, and how to prove it works. GitHub Spec Kit pairs a constitution with spec, plan, and task files per feature, often adding separate files for data models and API contracts. Amazon's Kiro uses project-level steering files for product, technology, and structure, then requirements, design, and task files per feature.

Spec Kit keeps business principles and technical standards in a single constitution file, so business and technical leads share ownership of it.

Where the lines fall, and why

Technical experts own the technical files. The tech stack and the plan hold decisions that call for specialized technical expertise: which programming language and frameworks, which versions, coding conventions, how the code is organized, and the step-by-step instructions the agent follows. These choices decide whether software is secure, maintainable, and able to work with everything else the organization runs. Business constraints still shape them, such as approved vendors, licensing, compliance, and cost. But an architect must turn those constraints into decisions.

Business users lead the files that define intent. The mission and requirements are where business users contribute most: the problem, the users, the outcome, the business rules, and what's out of scope. The roadmap is shared. The business sets priority, and engineering sets sequence, because technical dependencies often decide what can be built first.

QA owns validation. QA knows what to test and where customers run into trouble. Business users add acceptance criteria in business terms, and engineers add the technical checks required before code is merged.

Technical experts review every file. In practice, AI agents draft much of every file. The human job shifts from writing to recognizing what's missing, and that takes technical judgment, even in business-owned files. Thoughtworks reports the same pattern from its own teams using GitHub Spec Kit: experienced engineers with strong clean-coding and architectural practices tend to get the most value from spec-driven workflows.

Consider a hypothetical requirement for a customer portal: "Customers can view their order history." A business user reviewing the AI-generated draft might confirm that it reflects what customers need. An engineer would likely have more questions. How far back should the order history go? What happens when the order system is slow or down? Can all that data be shown to customers under the organization's privacy policies? None of these are coding questions, but each changes what gets built. Without technical review, the agent fills those gaps with assumptions. Some are harmless. Others lead to costly rework, or to security flaws in the code the agent writes from them. That risk is well documented. In its 2025 GenAI Code Security Report, Veracode found that AI-generated code introduced security vulnerabilities in 45% of the coding tasks it evaluated across more than 100 models.

Separation of concerns, for people

Engineers use the phrase "separation of concerns" to describe well-designed software: each component does one job, and does it well. Spec-driven development applies the same principle to people.

Business users focus on intent. Architects and engineers focus on how it's built. QA focuses on proving it works. No one's role disappears, including QA's, which becomes more central when the spec itself defines what "done" means.

Google's 2025 DORA research, drawn from nearly 5,000 technology professionals, describes AI as an amplifier: it magnifies an organization's existing strengths and weaknesses. GenAI doesn't replace these roles. It multiplies the value of each by taking on the drafting and the typing, so people spend more of their time on judgment. That's the opposite of "anyone can code." It's everyone contributing what they know best.

Where this goes next

These lines reflect where the tools are today, not where they'll stay. As AI agents get better at spotting integration gaps, surfacing unstated requirements like performance and security, and explaining technical trade-offs in plain language, business users will be able to take on more of the spec with confidence.

That shift will be gradual. It will happen file by file, not all at once, and technical review will remain the anchor for a long time. The organizations that benefit most will be the ones that move that line deliberately, not by accident.

What leaders should do now

Spec-driven development is still early, which gives leaders an advantage: you can set clear ownership from the start instead of untangling it after adoption scales.

Start with accountability. Give business leaders and product owners ownership of the mission, requirements, and acceptance criteria, the parts that capture what the business needs. Keep architects and engineers accountable for the technical files and for reviewing whether the plan is feasible. Bring QA in at the beginning, not after development is done. On lean teams, one person may wear several hats, but ownership and independent review should stay clear.

Then look at the economics. SDD adds work up front: writing, reviewing, and maintaining specs. The business case depends on whether that investment lowers costs downstream. Factor in tooling, training, and the ongoing effort of keeping specs in step with the software.

Finally, start small. Pick one contained initiative and set a baseline. Track time spent writing and reviewing specs, rework, defect rates, and overall delivery effort, and compare them with similar work done the usual way. That comparison will show whether SDD makes delivery more predictable, improves quality, and lowers the cost of getting working software into production.

If your teams are starting to explore spec-driven development, TSG can help establish the roles, ownership structures, and review practices needed to turn the approach into a scalable, effective process. Connect with our experts to discuss how to put SDD into practice.