In 2009 I built a complete WordPress site on EC2, from source, in the time it took a train to get from St Pancras to Ashford. It had monitoring. It had SSH login. It had a seed article. By the time I got off the train, I knew Chef would become a fundamental part of my professional life.

Like many engineers of my generation, I'd graduated through config files, shell scripts, Perl, a little Python and a healthy amount of SSH. That was the first level: you write configuration files and, when they are not enough, a shitty script to push the system into shape.

Chef was the next level up. You wrote software that modelled the resources you cared about, and software that described how to reach the desired state. A package. A service. A template. A user. A machine, converged.

The profound idea wasn't that you could automate machines. We'd been doing that for years. It was that you stopped describing how to configure a machine and started describing what kind of machine ought to exist. The tool took responsibility for working out how to get there. Once I'd understood that, I found it difficult to look at systems administration in quite the same way again.

Every so often our profession undergoes one of these shifts. They are surprisingly hard to recognise while they're happening. Afterwards they seem obvious.

I had always assumed that software engineering consisted, fundamentally, of writing software. Sometimes that software is shippable product. Sometimes it's provisioned infrastructure, serving a product. Sometimes it's code to analyse telemetry or orchestrated deployments. But the activity itself remained reassuringly constant. A human understood the problem, wrote the program and the computer executed it.

That assumption has stopped being true.

I now spend much of my day working alongside an LLM: discussing designs, challenging assumptions, reviewing approaches and generating drafts. The code still matters, but increasingly the code isn't what I spend most of my time personally crafting.

Adam Jacob is an old friend of mine. We worked together at Chef - where he was co-founder, and were active together in the early days of the DevOps movment. I knew he'd been thinking along similar lines, so I invited him to talk to me and my leadership team. He couldn't explain the thinking without showing us Swamp, the open-source product he's been building, as the manifestation of his philosophy.

Adam sorted people into three responses to agents. Some refuse. Some decide the agents can help them do their existing job faster. And some realise they have a new job entirely: building the environment the agents work in, for gains far beyond anything faster typing could give. When I pushed him for evidence, he described his own product's development: a team of five watching features, large refactors and bug fixes move through in hours rather than weeks, with 100% external UAT testing keeping the pace safe in a way that would have been inconceivable before agents. The point was not just the numbers. It was that much of what we take for granted — our approaches, our rituals, our workflows — was built on assumptions about how humans read, build, think and write. The agentic world does not share them. Swamp is the machine Adam built for that third kind of person — the one that makes the new job better, safer, and easier.

I had already been reaching for something like it, semi-manually, glued together. Swamp is what that looks like built properly. I started playing with it and felt the same jolt I'd had with Chef: this changes everything. I've had little more than a week with it, and I've barely scratched the surface — I am no expert in the tool. But what I have seen is enough to feel like a genuine paradigm shift, the kind that makes you ask different questions.

An agent left to its own devices writes code that can look plausible and work today, while remaining brittle, resistant to change, bug-ridden, and almost untraceable — you cannot tell why any of it is the way it is.

The engineering challenge is to make the space in which the model thinks smaller and better shaped.

This connects with how I already think and teach engineering. Model the types. Most systems can be designed by deciding which records exist, which states are valid, and which states must be impossible. The classic exercise is: how does an elevator work? Not the buttons and motors first. The records first. What is a floor? What is a request? What is a car? Which transitions are possible, and which must be impossible? The aim is to make invalid states unrepresentable.

Graphs matter for the same reason: many systems are graph-shaped, and seeing that changes how you model them. Property-based testing is one of the best ways to test: specify the rules behaviour must obey, not just examples. These are the patterns I reach for, and they are exactly the kind of thing Swamp bakes in, already bakes in, or makes easy to bake in. All of this is about shaping the problem space before intelligence, human or artificial, starts acting inside it, and Swamp makes that operational.

Adam borrows a phrase from Tesla's factories: "the machine that writes the machine."

That is the third level up. First you write config files and shitty scripts. Then you write software that models resources and converges systems. Now you write software that builds the factory in which agents produce quality software.

Swamp makes the agent's world narrower and harder to misuse.

A Swamp model says what kind of thing can exist, with typed schemas an agent can discover rather than prose it has to infer. A workflow is declarative YAML, so the shape of the automation is visible as structure rather than hidden in arbitrary glue code. CEL expressions wire models together in a safe, deterministic, non-Turing-complete language, which means the agent gets composition without being handed an unbounded programming surface.

When a Swamp step runs, its output becomes durable, versioned, queryable evidence with provenance. An agent should not have to rediscover what just happened, scrape terminal noise or hallucinate organisational memory. It should be able to ask what is known and build from there.

The declared world lives in Git, while runtime evidence is kept separately. The agent can edit reviewable files, then query what actually happened as structured fact, with JSON output treating machines as first-class readers.

For most of my career we have treated software as the thing we produce. The future of software engineering is the deliberate construction of environments in which reliable software can be produced by agents inside constraints humans have designed.

This is not the same as saying the human remains in the loop as a drag on automation, a temporary checkpoint to be compressed until human time tends towards zero. That view has the direction wrong. The human does not disappear. The human ascends into the design loop.

The software engineer is no longer primarily the co-writer of the product. The software engineer writes the software that defines the factory.

Chef changed the object of attention from the command to the desired system. Swamp changes it again, from the program to the conditions under which programs are produced.

Software engineers are no longer primarily writing software. We are building the conditions under which software can be written well.

I believe the world is genuinely different. The honest caveat is that a shift felt this strongly could still be my own cognitive bias recognising a pattern I am predisposed to see. But I do not think it is.

Back to main page