Now that the machine writes the code well, the engineer's craft moves to the floor the machine works on.
I became an engineer because I like building things that work — and, hopefully, things that are a little remarkable. The code was always how I got there; it was never the point of it. So when a machine arrives that can write that code, and write it well, it doesn't take the craft away. It gives me a better question: now that the machine is this good, how do I get the most out of it — more built, and built better?
This is exactly the kind of problem I enjoy most. I design the thing that works — the structure, the constraints, the way the parts fit. When the machine takes over the writing, that instinct doesn't go away; it moves to where it matters most now, which is the environment the machine works in.
There's a name people are starting to use for this work — harness engineering — and the idea behind it is good: an agent does better when you design the environment it builds inside, instead of just giving it a prompt and hoping for the best. Give it the real shape of the code, clear constraints, and a way to check itself, and the output stops being a gamble. If a machine fails, it's my problem.
A picture from the real world helps here. Think of the engineer who runs a factory floor. The machines do the making; the engineer owns the line — its layout, its power, the materials feeding each station, the order the work moves through. Nobody measures that engineer by how fast they can turn a single bolt. They are measured by how well the whole line runs once they step back from it. That is the move I'm making: from turning bolts to designing the floor.
And a floor works only if two things are true. Most of the talk is about the first, and skips the second.
I have to see it clearly enough to shape it, and the machine has to reach into it freely, without a locked door at every turn.
The first keeps me in charge — I can't improve a station I've never looked at. The second is the one that matters most to me. If the agent can only reach a tool through a gate, a wrapper, or a rate limit, that tool might as well not be there at all. An agent boxed into a corner is a weak one; a strong one can move freely, with the same reach I'd give a trusted colleague.
In software, the busiest part of that floor is the command line. It's where the most capable machines plug in — open, scriptable, asking no one for permission — and it's also the hardest part to see all at once: hundreds of tools, each one a maze of subcommands and flags, most of it behind a help page you have to go looking for. The agent reaches all of it freely; I can barely remember it all. Closing that small gap is what made me build a little tool (that I called "Bract"), which I've written about separately.
The direction is clear, and I'll be honest about how I feel about it: for me, the craft has never been more exciting. The machine will always type faster than I can — and that is exactly what frees me for the bigger, longer-lasting work of designing the place where good software gets made. Build the floor well, keep the right doors unlocked, and let the machines run. It's a lot of fun.