Spec-Driven Development: Why MCP Is the Missing Integration Layer for Enterprise AI

Hari Krishnan's recent InfoQ article on Spec-Driven Development at enterprise scale lands at exactly the right moment. As AI coding agents move from interactive prompting toward sustained autonomous execution, the question is no longer how fast can we write code — it's how effectively can we articulate intent.

The article maps a clear evolution: vibe coding to plan mode to spec-driven development. Each step reduces the instructional burden on the developer and increases the agent's independent execution time. But the article's most important contribution isn't the technical framework. It's the warning about what happens when enterprises adopt it wrong.

The "SpecFall" Problem

Krishnan coins the term "SpecFall" — the spec-driven equivalent of "Scrumerfall." If you've worked in enterprise software for any length of time, you've watched organizations install Agile ceremonies without changing how people actually collaborate. Daily standups become status reports. Sprint reviews become demos nobody acts on. The process is there; the culture isn't.

SDD faces the same risk. Adopted as a purely technical practice — better token management, longer agent runs, fewer hallucinations — it produces what Krishnan calls a "markdown monster": layers of specification documents that are outdated on arrival. The real value of SDD isn't technical efficiency. It's turning specs into the collaboration surface where product, architecture, engineering, and QA build shared understanding before agents start executing.

This distinction matters. Teams that treat specs as documentation will drown in stale markdown. Teams that treat specs as dialogue will direct agent swarms.

The Enterprise Gaps Are Real

The article identifies several gaps in current SDD tooling that anyone working in enterprise environments will immediately recognize:

Mono-repo assumptions. Most SDD tools keep specs co-located with code in a single repository. Enterprise systems span microservices, shared libraries, infrastructure repos, and platform components. When a feature touches six repositories, where does the spec live?

Developer-centric interfaces. Specs live in Git repos, code editors, and CLIs. Product managers — the people who should be defining the "what" — face immediate barriers to participation.

No backlog integration. Enterprises have qualified backlogs in Jira, Linear, or Azure DevOps representing months of prior refinement. Current SDD tools don't connect to them.

Unclear brownfield paths. Nobody is starting from scratch. Existing codebases need specs layered in incrementally, not generated wholesale by feeding an entire project to an LLM and hoping the context window holds.

These aren't theoretical concerns. They're the reason most teams try SDD on a side project and never bring it into their production workflows.

MCP as the Integration Bridge

This is where the article's architecture gets interesting — and where I think the strongest practical signal lives.

Krishnan proposes MCP servers as the integration layer between existing enterprise tools and SDD workflows. The pattern is straightforward: developers pull stories from Jira or Linear into their SDD workflows via MCP, and progress updates flow back to backlog tools automatically. Business context stays visible on product boards. Technical implementation details stay in repositories. MCP bridges the gap without forcing product managers to learn Git.

The multi-repo orchestration pattern extends this further. A product owner articulates business intent in the backlog. An architect encodes technical constraints and repository boundaries into reusable "context harnesses." When a story enters the system, agents guided by that architectural context automatically decompose it into repository-specific sub-issues — front-end work here, API changes there, infrastructure updates somewhere else.

This isn't speculative. It's the kind of connective infrastructure that MCP was designed for. The protocol's strength is exactly this: making AI agents first-class participants in existing tool ecosystems rather than requiring everyone to migrate to new ones.

Having spent the past several months building OpZero — an MCP bridge for AI-agent-driven deployments — I can confirm that MCP's role as enterprise connective tissue is only growing. The pattern Krishnan describes for backlog integration is directly analogous to what we see with deployment orchestration: agents need standardized interfaces to existing infrastructure, not replacements for it.

Harness Governance: Where Quality Engineering Evolves

The most forward-looking section of the article introduces "harness governance" — treating the context harnesses that guide agent execution with the same rigor we apply to production code.

The key insight is bug classification. When something goes wrong, it's either:

A spec-to-implementation gap: the spec was clear, but the agent diverged. Fix the validation mechanisms.
An intent-to-spec gap: the spec itself was incomplete. Improve the elicitation process.

Each category drives different improvements. Over time, the harnesses accumulate domain knowledge, anticipate edge cases, and generate more complete specifications. Quality engineering shifts from validating finished implementations to validating the harnesses themselves.

This reframes the role of senior engineers in an agent-augmented world. We're not reviewing code line by line. We're ensuring the context that generates the code is robust. It's a fundamentally different skill — closer to systems thinking than code review.

The Pragmatic Takeaway

If you're leading an engineering team and thinking about SDD adoption, the article's brownfield guidance is the most immediately actionable: don't try to retroactively spec your entire system. Spec areas as you touch them. Each bug fix, feature addition, and refactor becomes an opportunity to grow specification coverage organically. Start where the pain is, and let coverage expand naturally.

And if you're evaluating SDD tools (OpenSpec, GitHub SpecKit, Amazon Kiro, Tessl), the tooling landscape is still immature and fragmented. That's both a challenge and an opportunity. The space rewards practitioners with real implementation experience more than it rewards tool selection.

The enterprises that get this right won't just ship code faster. They'll build organizational capability for directing agent swarms — and that's a fundamentally different competitive advantage than individual developer productivity.

The original article by Hari Krishnan is available on InfoQ. It's worth reading in full, particularly the sections on specification style selection and the OpenSpec workflow integration examples.

Spec-Driven Development: Why MCP Is the Missing Integration Layer for Enterprise AI