Part B of a two-part series. Part A — “Spec-Driven Development Doesn’t Remove Your Knowledge SPOFs” — published last week and lays out the SPOF argument and the evidence base this piece builds on. Worth reading first if you haven’t already.

Link to Part A: Spec-Driven Development Doesn’t Remove Your Knowledge SPOFs

Quick recap of where Part A left things. The pitch for spec-driven development — author a structured specification, generate code from it, externalise knowledge so the system no longer depends on the people who built it — collapses on closer inspection. Tacit knowledge stays tacit. Spec rot creates new SPOFs. Spec authors become the new scarce resource. The enterprise systems where SPOF risk is highest are exactly the ones (customised COTS, configuration-heavy platforms, cross-system processes, regulated estates) where SDD struggles to apply. And the empirical evidence on AI-generated code — METR’s productivity findings, GitClear’s churn and duplication data, DORA’s stability decline, Microsoft’s DELEGATE-52 degradation curve, Sourcegraph’s “80% problem” — paints a less reassuring picture than the marketing.

That’s where Part A finished. The obvious next question: if the SPOF claim doesn’t hold up and the evidence on AI code at scale is this mixed, what does spec-driven development actually buy you? And how does an enterprise capture that value without falling into the failure modes the evidence points at?

The short answer is that the benefit is real but lives somewhere different from where the vendors point. And whether that benefit lands or evaporates depends almost entirely on a function the SDD discourse barely mentions: quality engineering.

So what’s the benefit?

What changes with spec-driven development is not the number of senior people you need. It’s what they spend their time on, and how far their output reaches.

In traditional development, an architect designs something, hands it to a team, and then spends months in code review, clarifying intent, correcting drift, answering “what did you mean by…” questions, and rescuing implementations that went sideways. The senior person’s judgement is delivered through a high-friction, high-toil channel — bilateral conversations, ad-hoc meetings, late-stage corrections.

In spec-driven development, that intent goes into a structured artefact upfront. The AI handles the mechanical translation to code. The senior person’s time is reclaimed for design, review, and the next problem. The same judgement now reaches further because it’s captured in a form that doesn’t require their continued presence to be useful.

This is the asymmetry that matters: writing a good spec is hard, but reading one is much easier. One senior person authoring a high-quality spec enables a much larger group — mid-level developers, support engineers, new joiners, auditors, testers, downstream integrators — to understand, maintain, and extend the system without each of them reconstructing the architect’s mental model from scratch.

That’s a force multiplier on senior judgement. Not a replacement for it.

The economic framing

If I were making the business case for this internally, I wouldn’t pitch it as “removes the need for senior skill” or “anyone can maintain anything.” Decision-makers will see through both. The honest pitch is:

The output of our senior thinking is currently captured in a form — code, and the heads of the people who wrote it — that scales linearly with the number of people who need to consume it. Each consumer pays a cost to reconstruct the original intent. Spec-driven development shifts that cost from O(n) per consumer to O(1) at authoring time. Our senior architects produce the same judgement, but it now reaches further, lasts longer, and survives their tenure.

That’s a defensible claim. It also reframes the investment question from “how many architects do we need” to “are our architects spending their time on the highest-leverage activity, and is the output of their thinking captured in a form that compounds?” Most enterprises would answer no to both.

The quality engineering shift — and the testability bet

This is where the picture changes most materially for organisations that take quality engineering seriously, and it’s also where I’d push hardest on the assumptions.

The naive read of spec-driven development is that it reduces the need for testing. Specs are precise. Code is generated from specs. Therefore the code is correct by construction. Therefore testing collapses to a residual concern.

This is wrong, and it’s the kind of wrong that creates real production risk if it goes unchallenged.

The testing need doesn’t reduce. It transforms, and in important ways it increases. There are now four distinct verification activities where there used to be one:

Spec validation. Does the specification correctly capture intent? This is the new front door for defects. A spec that’s wrong produces high-quality bad code very efficiently. The cost of validating intent at the spec stage is real, and the skills required — domain understanding, ambiguity detection, edge case generation, contract reasoning — are exactly the skills senior quality engineers bring. This is the most valuable upstream shift the QE function can make.

Implementation verification. Does the generated code faithfully realise the spec? Given the code quality evidence covered in Part A, the answer cannot be assumed. AI-generated code requires the same forms of testing — unit, integration, performance, security — that human code requires, and arguably more rigorous integration and security testing given the patterns the evidence shows.

Regeneration assurance. When the spec changes and the code is regenerated, does the new code still pass the existing tests? Does the test suite itself need regenerating, given that the implementation may be structurally different even when the behaviour is the same? How do you maintain stability across iterations when the long-horizon evidence says fidelity degrades? These are governance questions traditional development doesn’t ask in the same form.

Cross-system behavioural testing. The 80% problem doesn’t go away because the code came from a spec. End-to-end behaviour across multiple systems, integration contracts, and emergent properties still need testing, and the spec doesn’t capture them because no single spec ever could.

The governance load increases too. Specs are now controlled artefacts. They need versioning, change control, traceability links to code, links to tests, links to requirements, sign-off workflows, audit trails. For regulated industries, the spec becomes a compliance object in its own right. None of this is wasted effort — it’s how the spec earns its place as a source of truth. But it isn’t free, and the discipline isn’t trivial to build.

This is also where the most interesting opportunity for quality engineering sits — and it’s not in any of the obvious places.

If specs are the source of truth, testability can be baked into them at the artefact level. Observability requirements. Logging contracts. Error scenarios and recovery paths. Performance envelopes. Non-functional requirements. Telemetry hooks. Idempotency properties. Failure mode coverage. None of these are typically first-class concerns in traditional development; they get retrofitted as the system matures, usually badly. In a spec-driven world, they can be non-negotiable elements of the spec template itself, which means every regeneration carries them forward by construction.

That’s a genuinely novel capability. Testability as default. Compliance hooks as default. Observability as default. For quality engineering as a function, that’s a chance to shape what “production-ready” means upstream rather than enforce it downstream. The discipline that benefits most from spec-driven development is arguably not engineering — it’s the disciplines that engage with the spec early enough to influence what it requires.

This is also where the SPOF argument actually gets stronger, but only conditionally. If specs are authored without QE engagement, you’ll get specs that are structurally sound but operationally fragile — and a regenerated fragile system. If QE engages at spec authoring time and shapes the template, you get something closer to the original promise: production-ready systems regenerable from a source of truth that encodes operational quality alongside functional behaviour.

The conditional bit matters. None of this happens automatically. It’s an organisational choice that requires the QE function to push upstream into design, and the engineering function to accept that quality requirements are a first-class spec concern rather than a downstream consumer of the spec.

The structural parallel to the broader argument for quality engineering as strategic enablement is obvious and worth naming. Move quality thinking upstream. Capture it in artefacts that survive beyond the people who produce them. Reframe the senior QE function from end-of-pipeline gatekeeper to leveraged risk manager at design time. The mechanism is different from spec-driven development; the asymmetry is the same. The disciplines that benefit most are the ones that engage with the spec early.

The uncomfortable bit

Spec-driven development is a capability amplifier, not a capability creator. Organisations with architectural depth, design review culture, ADR discipline, and documentation maturity will get a meaningful uplift because they’re formalising and AI-enabling something they already do. Organisations without those foundations will discover that spec-driven approaches surface the absence rather than fix it. You can’t generate good specs from a culture that doesn’t reason architecturally in the first place — and a structured-looking spec that doesn’t capture the things that matter is arguably worse than no spec, because it creates false confidence.

This is the part the tooling vendors won’t tell you, and it’s the part that matters most for the enterprise rollout question. The right strategic question isn’t “should we spec-drive everything.” It’s “which systems carry the most knowledge SPOF risk, where does the cost of spec’ing them earn its keep against the alternatives — ADRs, runbooks, pair rotation, structured documentation standards — and what does the surrounding governance need to look like for it to be worth doing?” Spec-driven development sits in that toolkit. It doesn’t replace it.

Closing

Spec-driven development is worth taking seriously. It will reshape how senior engineering judgement is captured and consumed across enterprises that have the foundations to use it well. It will produce more durable, more regeneratable systems for the systems it can actually be applied to. It will make the work of testers, auditors, and downstream teams meaningfully easier where the conditions are right.

It will not remove your knowledge SPOFs. The structural knowledge will move into artefacts — that’s real. The tacit knowledge will stay where it always was. The spec authors will become the new scarce resource. The discipline required to keep specs trustworthy will become a capability you have to invest in. And the systems where SPOF risk is highest — your customised COTS estate, your integration backbone, your regulated legacy core — will be the systems where SDD is hardest to apply.

Sold honestly, the story is still strong. Specs externalise structural knowledge. They give senior judgement leverage it doesn’t otherwise have. They create a place for quality engineering, security, and compliance to engage upstream and bake non-functional requirements into the artefact rather than retrofitting them at the end. They make modernisation economically viable in cases where it previously wasn’t. That’s a real value proposition.

Sold as “no more key-person risk” or “anyone can maintain anything,” it’s the kind of claim that survives the pilot and fails the audit.

The interesting question for any engineering leader looking at this isn’t whether to adopt spec-driven development. It’s whether your organisation has the architectural depth to make the upstream investment pay back, whether your QE function is positioned to shape the spec template rather than consume its output, and where, across your estate, that investment earns its keep first.

The vendors will sell you the methodology. The value comes from what you build around it.

This is Part B of a two-part series. Part A — “Spec-Driven Development Doesn’t Remove Your Knowledge SPOFs” — covers the structural problems with the SPOF claim and the empirical evidence on AI-generated code at enterprise scale, including the METR, GitClear, DORA, Microsoft DELEGATE-52, Sourcegraph, Stanford, NYU, and ACM TOSEM studies referenced in this piece. Sources are listed in full at the end of Part A.

Spec-Driven Development Doesn’t Remove Your Knowledge SPOFs