If the machine writes the code, what are software engineers for?
A Chapter 1 excerpt from the book published as Sean Neal.
In the span of roughly two years, a generation of AI tools has emerged that can do something no previous technology could: generate working software from natural-language descriptions. GitHub Copilot can autocomplete entire functions. ChatGPT and Claude can produce full applications from a single prompt. Cursor, Windsurf, and a growing roster of AI-native development environments are collapsing the distance between intention and implementation. For the first time, the core mechanical act of software engineering—translating requirements into running code—is something a machine can do passably, and sometimes impressively, well.
This is the question nobody wants to ask: if writing code was the thing that made software engineers valuable, and machines can now write code, what exactly are software engineers for?
I have been working in the software engineering field for over twenty-five years. It is an uncomfortable question because it touches identity, not just economics. Most software engineers did not stumble into the profession for the paycheck alone. They were drawn to it by something deeper—a love of building, a pleasure in making complex things work, a satisfaction in the craft of well-structured code. To ask whether the craft still matters is to ask whether a core part of their professional self-conception still holds.
And so the profession has largely responded with two opposite reactions, both of which miss the point.
The first reaction is denial. You hear it in the confident assertions that AI-generated code is “always buggy,” that language models “don’t really understand” what they are producing, that any serious system still requires a human engineer from start to finish. There is truth in each of these claims, but the people making them often sound like the newspaper editors of 2005 explaining why the internet would never replace print journalism. They are describing the current state of the technology and mistaking it for a permanent ceiling.
But here is what the denial camp gets wrong: they are benchmarking AI against the standard of a senior engineer working on a difficult problem, and then declaring victory when the AI falls short. The more relevant benchmark is the median task that the median engineer performs on the median day. Most software engineering work is not designing distributed systems from scratch. It is writing CRUD endpoints, debugging CSS layouts, migrating data between formats, and wiring up the same authentication flow for the hundredth time. On that benchmark, AI is already competitive, and improving fast.
The second reaction is panic. This camp treats every incremental improvement in AI coding ability as proof that the profession is months away from obsolescence. They extrapolate from demos. They see an AI produce a working to-do app from a single prompt and conclude that enterprise software architecture will be automated by next quarter. They confuse the ability to generate code with the ability to engineer software, which is a bit like confusing the ability to string words together with the ability to write a novel.
The panic camp makes a different error: they collapse the distinction between coding and engineering. Coding is the act of producing instructions that a computer can execute. Engineering is the act of deciding which instructions should be produced, why, under what constraints, and with what tradeoffs. The first is a mechanical skill. The second is a judgment skill. AI is rapidly automating the first. It has barely begun to touch the second.
Both reactions share a common error: they define software engineering as code production. If engineering is writing code, then a machine that writes code is an existential threat. If engineering is writing code, then pointing out that the machine writes bad code is a sufficient defense. But the premise is wrong, and it has always been wrong. We have just never been forced to confront how wrong it is until now.
Software engineering has never been primarily about writing code. It has been about understanding problems, making decisions under uncertainty, managing complexity over time, and building systems that serve human needs in the real world. Code was the medium, not the message. The fact that writing code was difficult and time-consuming created a natural conflation—if the hard part of your day was writing code, it was easy to conclude that writing code was the hard part of the job. But that was always an illusion. The hard part was knowing what to build, why to build it, and how to ensure it would work not just today but six months and six team members from now.
We have been here before. When high-level languages arrived, the reaction from many assembly programmers was skepticism, sometimes outright hostility. The early C compilers produced code that was less efficient than hand-tuned assembly. That conclusion was technically correct and strategically catastrophic. The result was not fewer programmers. It was more programmers, solving more problems. Their low-level knowledge did not become irrelevant. It became leverage.
The underlying dynamic is this: when a tool handles the mechanical part of a discipline, the value shifts to the judgment part. When the compiler writes the assembly, the value is in knowing what to compile. When the cloud provisions the servers, the value is in knowing what architecture to deploy. When the AI writes the code, the value is in knowing what code should be written, and why, and what will happen when it runs in the real world.
The honest answer to “will AI replace software engineers?” is neither yes nor no. AI will replace some of what software engineers do, enhance other parts, and leave certain elements completely untouched. The engineers whose value is in the mechanical act of translating well-understood requirements into working code are the most exposed. The engineers whose value lies in understanding what to build, why it matters, how it fits into a larger system, and what can go wrong are becoming more valuable. This is the uncomfortable middle: the profession is neither doomed nor unchanged. It is being restructured around judgment rather than production.
If you have spent fifteen years getting exceptionally good at writing clean, performant, well-structured code—and a twenty-dollar-a-month subscription to an AI tool can now produce something that looks remarkably similar in a fraction of the time—you are entitled to feel unsettled. The grief is worth naming, because it often masquerades as something else. When an engineer insists that AI code is “always garbage” despite mounting evidence that it is improving rapidly, what you are sometimes hearing is not a technical assessment. It is a defense mechanism. Acknowledging that the machine can do part of your job well means acknowledging that part of your job was less special than you thought. That is a loss, and losses deserve to be felt before they can be processed.
The qualities that made great software engineers great have not changed. What has changed is that those qualities are no longer hidden behind the noise of manual code production. For decades, the sheer difficulty of writing code served as a kind of gatekeeping device—if you could produce working software, that alone was proof of value. Now that AI can produce working software, that proof is gone. In the age of AI, the signal—judgment, taste, systems thinking, deep understanding—becomes the whole game.
What the tools cannot do—yet—is exercise judgment. They cannot tell you that a feature request is solving the wrong problem. They cannot look at a design and say, “This is technically correct but it feels wrong,” and then explain why it feels wrong in terms that lead to a better design. They also cannot maintain a coherent vision across a large system over time. This is not a matter of scale or compute. It is a matter of the kind of understanding involved, which requires not just pattern recognition but something closer to caring about the outcome.
There is a version of this transition that goes well: AI handles the tedious parts, engineers focus on the interesting parts, and better software gets built faster. There is also a version that goes badly: organizations mistake AI-generated code for AI-generated engineering, lay off the people who provided judgment and taste, ship increasingly brittle systems, and discover too late that the thing they automated away was the thing that was holding everything together.
The question nobody wants to ask is not “will AI replace software engineers?” The real question is: “What was software engineering all along, and do we value it enough to preserve it?”
The full argument is in Who You Really Are: Software Engineering After the Code Writes Itself (Amazon paperback and Kindle): https://www.amazon.com/Who-You-Really-Are-Engineering/dp/B0GV5R52CN