‎

Are we still writing software?

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...