Infrastructure as Code (IaC) is the practice of defining machines, networks and the services on them in code, keeping that code in version control, and building from it. Martin Fowler’s definition, from a post based on Kief Morris’s work:
Infrastructure as code is the approach to defining computing and network infrastructure through source code that can then be treated just like any software system.
The rule that follows from it is short. “At no time should anyone log into a server and make on-the-fly adjustments.” A change goes into the code, and the code changes the machine.
Why it matters more with an agent
An agent starts every session with no memory of the last one. A fix made by hand lives in one machine, and the next rebuild erases it. A decision written into the code survives everyone forgetting it, the agent included. That makes IaC the part of the team’s memory that can be run, not only read.
None of this is new
In 1998, Steve Traugott and Joel Huddleston described running financial trading-floor infrastructure from a single version-controlled source they called the gold server. Their rule is Fowler’s, long before Fowler wrote it down: “Never log into a machine to change anything on it. Always make the change on the gold server and let the change propagate out.”
They claimed what we are trying to prove, that “we could actually destroy entire server farms and rebuild them with relative impunity”. And their reason for not editing machines by hand was about memory, long before anyone worked with an agent: “nobody ever remembers all of those custom tweaks when the boot disk dies on a major NFS server.” What an agent changes is how often the forgetting happens. It happens every session.
What it bought here
- Three hypervisors built from bare metal, 24 to 31 August 2026, each re-run with nothing left to change and no edits to the code.
- The Git server deleted and rebuilt on 4 September 2026. The rebuild found four defects, three in code already reviewed and merged, and after the fixes its history came back exactly: 308 merge requests and 1,021 notes.
- Two network machines each rebuilt twice on 5 September 2026, with both second runs needing zero edits.
- A check that compares the running estate with the code, hourly, live since 14 September 2026. Its first run found real drift, which the code then fixed.
- This site, declared in the same repository and served by the estate it describes.
Where we fall short
Merging is not applying. A change lands in the code when it is merged, but every apply is still a person running the code against the machines. On 31 August 2026 a merged change was believed live twice in one session while the machine still ran the old one. The hourly check now notices some of that drift. Nothing closes it automatically.
No pipeline runs the code. Automatic pipelines in this repository have been off since 30 August 2026, by the operator’s call. The checks run by hand before each change. Fowler’s definition expects the full discipline of continuous delivery. We are not there yet, and continuous integration and delivery is a page we have listed as upcoming, not one we can write.
Where we stop on purpose
Some things here are done by hand deliberately, each from a written procedure:
- Installing each hypervisor, at the console.
- Each host’s network, set once per host, by hand, as a documented handoff. A mistake there can lock everyone out, and it changes almost never.
- The machine image every new machine is cloned from, built rarely.
These are boundaries, not gaps, and we once wrongly listed two of them as defects. But the boundary has a price we should state: the hand-built image is the one owner nothing can verify. Every machine built from code starts from something that was not.