From Infrastructure as Code to Software as Specs

If you've spent time with Terraform or CloudFormation, you already know the pattern: stop hand-crafting servers, define desired state, let the tool handle the rest. Code, not config files. Infrastructure as cattle. This post argues the same shift is coming for software itself — and that the specs you write today are the thing worth protecting.

Terraform Didn't Version Control the VMs

The insight behind infrastructure-as-code wasn't about tooling. It was about what's worth preserving. When provisioning becomes cheap and repeatable, you stop treating the running instance as precious. You throw it away and regenerate it.

Code generation from specs is getting cheap in the same way. I've watched AI agents produce working implementations from a well-maintained set of rules and skills, reliably enough that I've started questioning something I'd never questioned before: why do I treat the code as the thing worth protecting?

What We Actually Care About

If the implementation is regenerable, the things worth protecting are:

• Specifications and requirements — what the thing is supposed to do
• Contracts and interfaces — how components talk to each other
• Tests — the definition of correct

The implementation becomes an artefact of the build, not a thing you maintain.

What Changes When You Think This Way

Code reviews shift from nitpicking implementation to evaluating whether the spec is right. Governance and compliance operate at the specification level — closer to where decisions actually get made.

You still commit the generated code — it's versioned, reviewed, and deployed just like any other codebase. But the mindset shifts: the code becomes a build artefact you can regenerate, not the primary thing you protect. When something needs to change, you update the spec and regenerate rather than patching the implementation directly.

Technical debt stops accumulating. That rushed feature built with shortcuts? Regenerate it with proper patterns. The cruft that builds up over years of patches simply disappears when you regenerate from a clean spec.

Software evolves without manual refactoring. As new patterns and practices emerge, you re-run generation and pick them up. The implementation adapts; the spec stays stable.

Compliance becomes reactive rather than painful. New regulation comes down, you update the spec, regenerate. No auditing hundreds of files, no scrambling to patch — the implementation just conforms to whatever rules flow from above.

I'll admit I found this slightly unsettling at first. A lot of my identity as an engineer is tied up in how I write things, not just what they do.

Where the Line Between Spec and Code Blurs

We've already seen this pattern succeed with infrastructure. As AI capabilities improve, the distinction between specification and implementation keeps narrowing. Entire codebases could be regenerated with better patterns, newer languages, or optimised approaches simply by re-running generation against stable specifications. The spec and the running software start to feel like the same thing expressed at different levels of detail.

Where We Will See This Working First

This transformation won't happen overnight or uniformly across all software. We'll see it first in specific contexts where the benefits are clearest and the risks most manageable:

• Small discrete tools — focused utilities with narrow scope and clear success criteria
• Scripts and CLIs — the glue code that large orgs quietly depend on, often owned by one person
• Small library packages — well-defined contracts, easy to validate
• Enterprise data products — established patterns, lots of existing validation

These all share the same property: you can write a spec that fully describes the behaviour, and you can tell when the output is wrong. As the approach proves itself in these domains, it will gradually expand to larger and more complex systems.

The Spec Is the Asset

Infrastructure engineers have learned to stop treating servers like pets. The next logical step is to stop maintaining code in the same way and start prioritising the specifications that truly matter.