SDD at Enterprise Scale: A Governance Problem in Tooling Clothes

Spec-driven development has a compelling pitch. Write a clear specification. Hand it to an AI agent. Receive working code. The tools are real: GitHub’s Spec Kit, Kiro’s EARS pattern, Tessl, OpenSpec. ThoughtWorks put SDD on their Technology Radar. Anthropic runs spec-first workflows internally. The approach works.

It works on greenfield projects. In single repos. With small teams.

At enterprise scale, it collapses. Not because the tooling fails, but because the organization does.

Seven Barriers That Aren’t About Code

Hari Krishnan published a thorough analysis of enterprise SDD adoption in February 2026. He identified seven barriers that current SDD tools do not address. Read through them and notice what they have in common:

Developer-centric tools. Every SDD tool assumes the user is an individual developer working inside a code editor. Product managers, architects, compliance officers, and QA leads have no seat at the table. The spec is a developer artifact in a world where specs now govern cross-functional decisions.

Mono-repo assumptions. Spec Kit, Kiro, and Tessl all assume one repository. Enterprise codebases span dozens or hundreds of repos with complex dependency graphs. A feature that touches three services in three repos needs three coordinated specs. No tool handles this.

Unclear artifact separation. Where does the business context live? Where does the implementation detail live? SDD tools conflate product requirements, architectural constraints, and coding instructions into a single specification file. At scale, this produces specs that are too long to be reliable and too mixed to be auditable.

Poor backlog integration. Enterprise teams track work in Jira, Linear, Azure DevOps, or Shortcut. SDD tools create a parallel planning system. Two sources of truth for the same work means neither is trustworthy.

Undefined collaboration patterns. Who writes the spec? Who reviews it? Who approves changes? SDD tools provide version control through git, but version control is not governance. A diff shows what changed. It does not show whether the change was authorized, reviewed by the right people, or compliant with organizational policy.

Spec variance. Every team writes specs differently. Without organizational standards for spec structure, quality, and review, the “specification” is just another name for “document that varies by author.”

Brownfield ambiguity. Most enterprise code was not written with SDD. Introducing spec-driven workflows means retrofitting specifications onto existing systems. The tools assume you are starting fresh. You are not.

These seven barriers share a root cause. They are all organizational coordination problems. Tooling cannot solve them because they exist in the space between tools, teams, and processes.

The Waterfall Elephant

Let’s address the obvious critique directly.

SDD asks teams to write detailed specifications before generating code. This sounds familiar. It should. It is the core premise of waterfall development, a methodology the industry spent two decades escaping.

The SDD community has a response: specs are living documents, iterated alongside code. This is true in theory. In practice, the evidence is less reassuring.

Scott Logic tested Spec Kit on a real feature and produced 2,577 lines of markdown before writing a single line of application code. The process took ten times longer than iterative prompting. Birgitta Bockeler, from Martin Fowler’s team at ThoughtWorks, reviewed the major SDD tools and concluded: “I’d rather review code than all these markdown files.”

ThoughtWorks placed SDD in the “Assess” ring of their Technology Radar (Volume 33, November 2025), not Trial or Adopt. Their assessment warns of “elaborate and opinionated” workflows and the risk of “relearning a bitter lesson.”

The bitter lesson is this: comprehensive upfront specification has failed before. CASE tools in the 1990s. Model-driven architecture in the 2000s. No-code platforms in the 2010s. Each promised that better specifications would eliminate the hard part of software development. Each discovered that the hard part was not specification but feedback. Software is learned, not specified. Requirements clarify through building, not before it.

SDD could be different. AI agents can iterate faster than human developers, which compresses the feedback loop. But “could be different” requires organizational infrastructure that does not exist yet. Assuming the infrastructure will materialize because the tooling is good is the same bet those earlier movements made.

Multi-Repo Orchestration: The Missing Pattern

Krishnan’s most valuable contribution is his proposed workflow for coordinating specs across multiple repositories. He describes three phases: Discover, Design, and Task.

In the Discover phase, teams identify which repos a feature touches and what business context each needs. In Design, they create coordinated specifications where business context stays on product boards and implementation details stay in repos. In Task, they break specs into executable units assigned to agents in specific repos.

This matters because it describes what no SDD tool currently provides: a way to manage the organizational complexity of specifications that span team boundaries.

As we explored in The Spec Layer, five independent teams discovered that specifications are the primary governance surface for AI agents. But that discovery assumed single-team, single-repo contexts. Enterprise reality is messier. A specification that governs an API endpoint in one repo must coordinate with specifications governing the frontend in another repo and the data pipeline in a third. The governance surface is not a single spec. It is a network of interdependent specs.

We have written about what effective agent specs contain and why specs are governance artifacts. Multi-repo orchestration is the next frontier: how do you govern a constellation of specs that must remain consistent across organizational boundaries?

Krishnan’s three-phase model is a starting point, not a solution. It describes the workflow. It does not describe the enforcement mechanisms, the review processes, or the reconciliation procedures when specs in different repos contradict each other. Those are governance questions.

The Bottleneck Has Moved

Adrian Cockcroft, former VP of Cloud Architecture at AWS, identified the real constraint in a February 2026 post about managing agent swarms: “The surprising insight from working with agent swarms is that the problem isn’t writing code. They do that extremely well. The bottleneck is managing them.”

This is the shift that enterprise SDD adoption reveals. The bottleneck has moved from code production to intent articulation, coordination, and oversight. More precisely, it has moved from a technical bottleneck to an organizational one.

Consider what “managing agents” requires at enterprise scale. Assigning the right context to each agent across repo boundaries. Ensuring specifications are consistent with organizational policy. Reviewing generated code for compliance, security, and architectural coherence. Reconciling outputs from multiple agents working on different parts of the same feature. Maintaining audit trails from specification to deployment.

None of these activities are about writing better specs. They are about building the organizational infrastructure to govern spec-driven workflows. The tooling is necessary but not sufficient. A team with excellent SDD tools and no governance infrastructure will produce well-specified chaos.

Deloitte’s 2026 enterprise AI report confirms the broader pattern: only one in five companies has a mature governance model for AI agents. The other four are deploying agents with ad-hoc oversight. SDD does not fix this problem. It concentrates it. When the spec drives everything, the spec becomes the single point of organizational failure.

The Bug Classification That Matters

Krishnan introduces a distinction worth preserving: spec-to-implementation failure versus intent-to-specification failure.

A spec-to-implementation failure means the agent did not follow the spec. The spec was correct. The agent misinterpreted it, lost context, or produced output that contradicts its instructions. This is a tooling problem. Better prompting, better context management, better agent harnesses can address it.

An intent-to-specification failure means the spec itself was wrong. The person who wrote it misunderstood the requirement, omitted an edge case, or failed to account for a constraint from another team. This is a governance problem. No amount of tooling improvement fixes a wrong spec. Only organizational processes (review, cross-functional validation, compliance checks) catch it.

Enterprise SDD will generate both types of failures. The tooling community focuses almost exclusively on the first type. The second type is more dangerous because it produces code that perfectly implements the wrong thing. It passes all automated checks. It satisfies the spec. The spec was wrong. This is the “almost right” problem at the specification layer, and it requires organizational, not technical, solutions.

What Works: Brownfield Incremental Adoption

If your organization is considering SDD at scale, here is what the evidence supports.

Start with the harness, not the spec. Before writing specifications, build the infrastructure that makes specs governable: review workflows, approval chains, compliance gates, audit trails. As we explored in What Is an Agent Harness?, the infrastructure around the AI matters more than the AI itself. The same principle applies to specifications. The governance infrastructure around the spec matters more than the spec format.

Use MCP as the integration bridge. Model Context Protocol can connect existing backlog tools (Jira, Linear) to spec workflows, which avoids the dual source of truth problem. Krishnan identifies this as the practical path for brownfield adoption. MCP’s enterprise readiness features are still pre-RFC as of March 2026, but the protocol is already functional for basic integration. As The Context Crisis showed, context management is the operational constraint. MCP helps by giving agents structured access to existing systems rather than requiring all context to live inside the spec.

Adopt incrementally, by team. Do not roll out SDD organization-wide. Let one team run the full workflow on a bounded project. Measure what works and what breaks. Then propagate the patterns, not the tools. Every organization’s coordination challenges are different. A pattern that works for a payments team will not work for a machine learning platform team.

Separate business context from implementation detail. Krishnan’s Discover-Design-Task phases provide a useful framework here. Business context belongs on product boards visible to stakeholders. Implementation specifications belong in repos visible to engineers and agents. Governance connects the two: ensuring the implementation spec faithfully represents the business intent.

Build the review process before you need it. When specifications drive code generation, spec review is more consequential than code review. Invest in spec review as a formal organizational process with defined reviewers, approval criteria, and escalation paths. This is not overhead. It is the control that prevents the “perfectly implemented wrong thing” failure mode.

The Organizational Capability That Matters

SDD’s promise is real. Clear specifications, executed by capable agents, can compress development cycles dramatically. The economics work. The tooling improves monthly.

But tooling solves tooling problems. Enterprise SDD adoption fails on organizational problems: coordination across teams, consistency across repos, governance across the full lifecycle from intent to deployment. These problems are old. They predate AI. They are the same coordination challenges that made waterfall fail and that Agile partially addressed by compressing feedback loops.

The question for enterprise teams is not “which SDD tool should we adopt?” It is “do we have the organizational infrastructure to govern spec-driven workflows at scale?” If the answer is no, the tool choice is irrelevant.

SDD at enterprise scale is a governance problem wearing tooling clothes. The organizations that recognize this will invest in governance infrastructure first and tooling second. The organizations that don’t will rediscover what the industry learned in the 1990s: specifications without feedback loops, review processes, and organizational coordination produce precisely detailed software that nobody wanted.

---

This analysis synthesizes Spec-Driven Development: Adoption at Enterprise Scale (February 2026), Why We Need a Purpose-Driven Agent-Based Developer Management Platform (February 2026), ThoughtWorks Technology Radar: Spec-Driven Development (November 2025), SDD Tools Comparison (2026), and Deloitte State of AI in the Enterprise (2026).

Victorino Group helps enterprises build the governance infrastructure that makes spec-driven development safe for production. Let’s talk.