If software can build software

Last month a test suite of mine went green, all 863 tests, on software I shipped and didn’t write. An AI agent wrote the code from a brief I wrote, over sessions I reviewed. I’ve built software for a living across four industries, and the honest description of what happened is that software built my software. Which puts a sharper question on the table, one I hear asked with growing confidence: if software can build software, why would anyone still need an engineer?

The thesis behind it is clean. Building software was a skill. The skill is now performed by the thing being built, and a skill that machines perform stops being a profession. Typesetters, weavers, and the human computers who once filled rooms with arithmetic: the list of precedents is long, and on the surface the engineer fits right at the end of it.

But this exact question has been asked before, inside software itself, and the profession’s answer is instructive. A compiler builds software from a description. So does a framework. So does SQL, which lets you state what you want and never say how. Each layer took over construction work engineers used to do by hand, and each time some people concluded the engineer was finished. What happened instead, every time: engineers moved up one level of specification, and the profession got bigger.

Fred Brooks explained the mechanism in 1986. The hard part of software was never the construction. He called that the accidental complexity. The essence was something else: knowing what to build, deciding between things that can’t both be true, fitting a system into a messy world. Tools kept eating the accident. The essence stayed with the person.

So far, so reassuring. But the old answer doesn’t fully cover this wave, and I want to be honest about why. AI is the first construction layer that also reaches into the essence. It builds what I specify, and it also proposes what to build from a vague sentence. The compiler never did that. This is why the question has teeth now, when it didn’t for fifty years.

Here’s what the question gets wrong anyway. “Engineer” describes a bundle of four jobs: deciding what should exist, constructing it, verifying that it does what was intended, and answering for it when it doesn’t. One person did all four, and construction was the visible one, the billable one, the one we named the profession after. AI unbundles the role and eats construction. The question “why do you need an engineer” assumes the bundle was the job. Construction was just the notation.

I can watch the unbundled job in my own week. The brief is the deciding: scope, constraints, a definition of done. Skip that part and you get the feeling of building rather than the thing you meant to build. The review is verification, and it holds the result to the intent behind the brief, because the agent satisfies the letter of a brief far more reliably than it satisfies the point of one. And the name on the result is mine. My proudest engineering artifact this quarter is a text file.

The last part of the bundle is bedrock. Deciding and verifying might shrink as the machines get better at proposing and checking. Answering doesn’t shrink. No court, no regulator, no customer anywhere accepts software as the responsible party. When something built by software fails, “who answers for this” still needs a person, and the person who can answer well is the one who decided, specified, and verified.

So the thesis has it backwards. Software building software doesn’t remove the engineer. It removes the disguise. For seventy years, construction was so demanding that it hid the actual job underneath it. Now the construction is handled, and the job it was hiding stands in the open: knowing what should exist, telling whether it does, answering for it. In the open, that work has nowhere left to hide, and neither does anyone who only ever did the construction.