The most-cited AI prediction in B2B software over the last two years has been wrong in an interesting way. The claim that AI agents will collapse the SaaS business model — variously credited to Satya Nadella, Peter Levine and a cluster of others — has been framed correctly, but partially. It is true that AI erodes the value of software-as-service in some contexts. The tools are doing things that used to require a vendor. The case is real, even when overstated.
But the more useful question is not what dies. The more useful question is what becomes newly valuable. AI does not simply make software cheaper to build. It moves where the commercial value lives.
This article is about what is becoming valuable. The short answer is the specification. The longer answer takes about two thousand words.
What Governance as Code left on the table
The first three articles in this series asked one question: how does governance live inside an organisation, in a form that takes effect by structure rather than by description? This article asks a different question that follows from it: in what form does the structural design of governance move between organisations? You cannot hand a client a running workflow. You cannot transfer an operating-model decision right by writing it down on someone else’s letterhead. The structural artefact has to take a form that can be built afresh inside the receiving organisation’s own infrastructure. That form is a specification — but a specification in a particular sense, which the rest of this article sets out.
The previous article in this series closed with a deliberate handover. Governance as Code set out the architectural insight that effective governance is not written into documents but built into systems — a principle independently rediscovered in software engineering, manufacturing, the built environment and organisational design (Baxter & Abraham, 2026c). It closed by handing forward an interesting commercial question: if implementation becomes cheaper and the system enforces its own rules, what becomes commercially scarce?
The answer this article gives is the specification — the buildable, reviewable, governable account of what the system must do, what constraints it must obey, how it must be verified, and how it should be implemented inside the client’s own infrastructure.
The deeper treatment of governance-as-code lives in Governance as Code (Baxter & Abraham, 2026c). The wider participative-governance frame underneath it lives in AI Governance from the Boardroom to the Front Line (Baxter & Abraham, 2026b) and The Complete Guide to Strategy Governance (Baxter, 2026a). One architectural insight, expressed so far in three forms: structural permission (social), structural control (procedural), governance as code (technical). This article takes up the fourth: specification as the unit of commercial transfer.
Code is becoming cheap
Start with what has actually changed.
AI-assisted engineering has reduced the time and labour required to produce many categories of working code. The defensible claim is not that all software is now easy, nor that engineering expertise has become unnecessary. It is narrower and stronger. The marginal cost of producing a first working implementation has fallen sharply for a growing class of work, and that changes where the commercial value concentrates.
The evidence is now clear enough to act on. Thoughtworks identifies spec-driven development as an emerging AI-assisted engineering practice, and argues — counter-intuitively to people who expected AI to make specifications obsolete — that AI coding has made specifications more important, not less, because models can manipulate text and build from natural-language requirements with a fluency that was not available even eighteen months ago (Thoughtworks, 2025a; 2025b). GitHub’s Spec Kit treats the specification as a contract for AI agent behaviour: a reviewable artefact that AI tooling generates from, tests against and validates against (GitHub, 2025a; 2025b). AWS’s Kiro treats requirements.md, design.md and tasks.md as first-class workflow objects, automatically loaded into the AI’s working context (Kiro, 2026a; 2026b).
The implication is the same in each case. AI-era engineering is not “prompt and hope”. The mature pattern is “specify, plan, generate, validate” — and the specification is what holds the work together.
Cheap code creates a governance problem
The next step follows only if you take Governance as Code seriously.
If software can be generated quickly but governance must be embedded structurally, then fast code without embedded governance is a liability. Faster generation amplifies whatever quality and constraint discipline the producing process applies. Generation without governance amplifies failure modes; generation with embedded governance amplifies value. The two are not symmetric. Errors made faster spread faster.
This is the Governance as Code conclusion in commercial register. Effective governance lives in the components, the gates, the runtime constraints, the validators — not in the policy document that describes them. As code becomes cheap to produce, the cost of producing it without those components rises rather than falls. The discipline that makes code correct — the constraints, the contracts, the verification stack — becomes more valuable, not less.
The infrastructure-and-policy-as-code traditions are the technical vocabulary the AI era is now reaching for. Open Policy Agent and HashiCorp Sentinel are commercial-grade examples of governance expressed as executable policy rather than documented intent (Open Policy Agent, n.d.; HashiCorp, 2025). What worked for cloud infrastructure works, with adaptation, for AI agents. The principle is the same.
The implication for procurement is direct. A vendor selling AI-accelerated implementation without a credible specification of the constraints and verification surface is selling speed without governance. The buyer absorbs the governance work as integration risk. That trade is sometimes worth making. It is increasingly rarely the right trade for business-critical systems.
The specification becomes the critical artefact
If implementation gets cheaper but governance must remain embedded, the locus of judgment moves up the stack. The work of deciding what to build, under what constraints, with what governance properties, and for what outcomes — this is specification work, and it is where human expertise now concentrates.
A working definition.
Software by Specification is a commercial model in which the supplier’s primary deliverable is not a running software product but a buildable, reviewable and governable specification: a structured account of what the system must do, what constraints it must obey, how it must be verified, and how it should be implemented inside the client’s own environment using AI-assisted engineering.
This is not a conventional requirements document. For a specification to function as a structural artefact rather than a description, it has to carry eight layers. Together they constitute the buildable form of structural design.
- Intent — the business outcome, the user problem, the strategic rationale, the success measure. Begins in language because judgment begins in language.
- Behaviour — the system’s expected behaviour expressed as concrete examples or scenarios that can be tested. Specification by Example and behaviour-driven development provide the long-running precedent (Adzic, 2011; North, 2006).
- Interface and contract — how the system interacts with users, other systems, data and services. API-first development is the cleanest mainstream precedent (Swagger, n.d.; Atlassian, 2019).
- Data and knowledge — what data the system uses, where it comes from, how it is governed, how authoritative content is distinguished from generated synthesis.
- Constraint and governance — what the system must not do; the policies, security boundaries, access rules, escalation triggers and audit-trail requirements expressed as enforceable rules. The Governance as Code material lives here.
- Verification — how the organisation will know whether the system works: acceptance tests, regression checks, policy checks, evaluation datasets, human review criteria.
- Implementation — the reference architecture, target infrastructure, build sequence and AI-agent instructions.
- Evolution — versioning, change control, decision logs, lifecycle review.
This is not a four-hundred-page Word document. The mature form of a specification of this kind is a versioned document set, much of it machine-readable, much of it executable, all of it reviewable.
The eight layers are the argumentative form. The commercial form is necessarily tighter. The AI Value Worx specification package, set out at aivalueworx.com/how-we-work, commits to four operative artefacts: module specifications, governance-as-code specifications, unit test specifications and data contracts. Between them, those four cover six of the eight layers. Module specifications carry behaviour at component level, internal interfaces, and implementation architecture. Governance-as-code specifications carry the constraint-and-governance layer. Unit test specifications carry verification. Data contracts carry data, knowledge and the data-flow part of system interfaces.
The two layers the package does not commit to in document form — intent and evolution — are carried in the consultancy conversation that wraps the package. Intent is established in the Discovery Sprint, where strategic outcome is shaped before a single specification is written. Evolution is governed across the Customisation Retainer, where decisions are recorded, versions are managed, and the specification is kept honest against the system as it grows. Eight in argument. Four in commercial commitment. Plus the consultancy that holds the rest.
Specifications are not new. AI changes the economics
A fairness check. Specification-led engineering has been around for decades. This article should not pretend otherwise.
API-first development is the cleanest mainstream example. Atlassian reported moving from implementation-driven API design to specification-first API development and seeing benefits including reduced development time, tighter feedback loops and better API design (Atlassian, 2019). The AWS engineering team has used formal specification and model checking to design distributed systems since 2011 — precisely because conventional testing misses subtle failure modes in critical infrastructure (Newcombe et al., 2015). Specification by Example and behaviour-driven development have given delivery teams business-readable specifications for over a decade (Adzic, 2011; North, 2006).
The continuity is that specification-led work has always reduced ambiguity and coordination cost. The change is what AI does to the economics. The translation cost from specification to working implementation has fallen, and is still falling. What used to require a team can now be done by a single capable engineer with a good specification and good agent tooling. The specification was always valuable. AI has just made it the rate-limiting commercial step.
The Martin Fowler site captures the gradient usefully. It distinguishes spec-first development (specification written first, used to drive AI-assisted build), spec-anchored (specification persists after delivery and supports evolution), and spec-as-source (specification is the primary artefact humans edit; code is generated from it) (Fowler, 2025). A Software by Specification engagement does not have to claim spec-as-source from day one. Spec-first and spec-anchored is enough.
Build yours from my specification
Three commercial patterns now compete for the same enterprise software budget.
| Model | Commercial promise | Dependency pattern |
|---|---|---|
| SaaS | Rent my running software | Vendor-owned product and infrastructure |
| Custom development | Pay people to build software for you | Labour-intensive implementation dependency |
| Software by Specification | Build yours from my specification | Client-owned implementation; supplier-owned specification authority |
Software by Specification is not a universal SaaS replacement. SaaS is durable for commodity capabilities, well-specified workflows, and contexts where vendor-operated infrastructure is the right answer. Aaron Levie’s position — that AI agents augment SaaS rather than replace it for most enterprise contexts — is correct for a large portion of the market (TechCrunch, 2025; Reuters, 2026). Forecasts of SaaS’s complete demise are not what the evidence supports.
What changes is the boundary. Software by Specification becomes attractive in contexts where the conventional SaaS trade-offs no longer hold: business-critical systems where governance, confidentiality, integration with internal data, or organisation-specific operating logic matters more than vendor-operated convenience. In those contexts, the commercial deal is no longer “rent my software”. It is “buy my specification authority; build inside your own walls”.
A running SaaS product is a vendor dependency. A specification is a document. That is its commercial superpower: it can be read, reviewed, adapted, executed, owned and audited inside any organisation’s own infrastructure. The vendor owns the specification authority. The client owns the build.
This commercial pattern has a name. We call it the firewall proposition: the separation of capability from code, with the supplier providing the specification package and the client building inside its own infrastructure. The single-sentence form, as the AI Value Worx home page now states it, is direct: “the fundamental design choice in AI Value Worx is the separation of capability from code”. Twelve words of commercial promise on top of fifteen hundred words of intellectual argument.
Conclusion
The reader who has followed this article through can now read the AI Value Worx home page differently.
Three of its four founding differentiators are this article’s argument made commercial. The firewall proposition is the Software by Specification pattern. Specifications as the deliverable is the eight-layer stack reduced to four operative artefacts. Self-sustaining by design is the client-owned-implementation principle: when the engagement ends, what continues is the client’s system, in the client’s infrastructure, maintained by the client’s team. The fourth differentiator, evidence not opinion, is what the AI Value Intelligence corpus delivers — a separate capability this article has not needed to argue for.
What the website asserts in twelve words, this article argues in two thousand. Each is incomplete without the other. The intellectual case requires the commercial form to be more than a thesis; the commercial form requires the intellectual case to be more than a brochure. This is the Software by Specification proposition embodied — the architectural insight of this series taking commercial form. The same move that puts governance into the structure of the workflow puts commercial value into the structure of the specification.
For the senior commercial buyer, the practical move is now in front of you. The intellectual case is here, on the page. The commercial form is at aivalueworx.com — where the proposition is asserted, the package is set out, and the engagement model is described. Read either as a window into the other.
Three articles asked how structural design lives inside an organisation. This one asks how it travels. SaaS rented you the running software. Software by Specification gives you the specification authority — the structural artefact in transferable form — and lets you build the running software inside your own infrastructure. The artefact worth owning, in the era when code is cheap, is the structural one.
That is what we sell.