Is software engineering really dead?

1 · The obituary is premature

Every few months a headline announces that software engineering is finished. This latest wave has been louder than usual, and for once it is not empty noise: the thing doing the replacing can actually write code, and write a lot of it, well.

So it is worth taking seriously. But "dead" is the wrong word. The job is not disappearing, it is changing shape, and the change is bigger than most of the takes give it credit for. Software engineering is reforming. What counted as the peak of the craft a few years ago is quietly being handed to machines, and what is left is the part that always mattered most and got the least time.

This post is my honest read on that shift, including one consequence I almost never hear anyone mention.

2 · Engineering was never really about the code

For years the considered epitome of a great engineer was code-first. Clean architecture, a tidy folder structure, immaculate standards, fluency in the newest stack. Those are real skills and I am not dismissing them. But they were always a proxy for the actual job, not the job itself.

Engineering, the word we borrowed, is a problem-solving discipline. A structural engineer is judged by whether the bridge stands and carries the load, not by how elegant the intermediate calculations looked. The code was our medium, the way a blueprint is a civil engineer's medium. Somewhere along the way software made the medium the whole identity, and "engineer" came to mean "person who writes good code" rather than "person who solves the problem well".

That was always a bit of a category error. The reform happening now is really just the word snapping back to its original meaning. When the medium gets automated, what is left is engineering in the older, truer sense: understand the problem, design a solution, own the outcome.

3 · Yes, AI writes better code (now let me earn that)

Here is the line people bristle at, so let me say it plainly. On the mechanical layer, AI already writes better code than most humans, most of the time. Not perfect code, and yes it can absolutely be better, but faster by orders of magnitude, more consistent, and tireless on exactly the work humans rush and resent.

It holds more of an API surface in its head than any person can. It does not get bored halfway through the boilerplate and start cutting corners. Ask it for a well-scoped function, a component, a migration, a test suite, and it will usually get you a solid draft in seconds, cleaner than the median human first pass. Pretending otherwise is not craftsmanship, it is denial.

Now the part that keeps this honest. AI is brilliant at "how do I write this" and helpless at "should this exist, and what should it actually do". It writes to a spec, inside a bounded problem someone else framed. Somebody has to set that spec, choose the constraints, and decide when the output is good enough to ship. That somebody is where the whole job is moving.

4 · So the human moves up the stack

When the mechanical layer is handled, your attention is freed for the part that was always the hard part and always got squeezed by the deadline: the decisions. What are we building, why, for whom, and with which trade-offs. Solution design. System architecture. And increasingly orchestration, directing AI agents and tools the way a lead directs a team.

The value does not vanish, it relocates. It moves up the stack, closer to the business and the user, away from the keystrokes.

This is what people miss when they measure the change purely as "AI took the coding". The coding was the lower rung. The interesting work, the reasoning about what to build and how the pieces should fit, is exactly the work that used to get crowded out because we spent most of our hours typing. Now we get those hours back and can spend them on the questions that actually determine whether a product is any good.

5 · The bar just went up, not down

This is the point I rarely hear anyone make, and I think it is the most important one. Handing the code to AI does not lower the bar for developers. It raises it, sharply.

Think about how it used to work. A human wrote the code, limited by context, by time, and by how much one brain could hold at once. When a product shipped with rough edges, "given the constraints, this is good code" was a fair defence, and often an honest one. The code itself was a legitimate bottleneck, so a limitation could reasonably be pinned on it.

That defence is mostly gone now. AI writes the code, quickly, and the human becomes the last gate before it ships. When generating a cleaner, more complete version is a few minutes of work, it is much harder to justify a product's limitation as a code problem. "The code could not do it in the time" stops being credible when the code is no longer the slow part.

What is left when you strip that excuse away is the decision. Did you scope it right? Did you catch the flaw before it shipped? Did you actually know what good looked like? The bar for shipping working, well-made software is higher than it has ever been, precisely because the cheap excuses have evaporated and you own the output with your name on it.

6 · The solutions architect rises

Follow that shift to its conclusion and one role gets a lot more prominent: the solutions architect, or whatever a given team calls the person who turns a business problem into a coherent system, picks the trade-offs, and orchestrates the build.

It is the "engineering" in software engineering made central again. Less time on "which framework this month", more on "what is the real problem, and what is the smallest system that genuinely solves it". The person who can hold the business context, the technical constraints, and the user's actual need in one head, then direct the build, including the AI doing the hands-on-keyboard part, becomes the highest-leverage person in the room.

I do not think this stays a senior-only speciality either. As AI absorbs more of the implementation, thinking in solutions moves closer to the default shape of the job, something every developer is expected to do rather than a title a few people hold.

7 · What this looks like in practice

This is not theory for me. I work this way daily across dozens of client sites. I lean on AI heavily for scaffolding, refactors, tests, boilerplate, and whole well-understood features, and it is a genuine force multiplier. It lets me move fast without re-explaining context every time or grinding through the repetitive parts by hand.

But the architecture, the design decisions, and the final quality bar stay mine, and I review everything. I never ship code I do not understand. That rule matters more in this new world, not less.

So the skills I would invest in now are the durable ones: how systems fit together, how to reason about trade-offs, how to translate a fuzzy business goal into a clear technical one, and how to judge quality rigorously. The syntax is increasingly cheap. The judgement is not.

8 · So, is it dead?

No. It reformed. The typing got automated and the engineering got promoted.

If your identity as a developer was tied to being the person who writes the code, that part of the job is genuinely shrinking, and it is fair to feel something about that. But if you came into this to solve problems, the interesting work just got closer to the surface, and the parts that used to eat your week got handed to a machine that is good at them.

Learn to think in solutions, not just syntax. Own the outcome, because the excuses that used to cushion it are gone. Software engineering is not dead. It is finally being made to live up to its name.