One of the reasons I think the conversation around AI and software engineering feels so noisy right now is that people are treating AI as if it is something completely separate from the history of software development.
I don’t see it that way.
To me, AI coding tools are just another layer of abstraction.
Software has always moved forward through abstractions. We went from working closer to the machine to higher-level languages, then to richer frameworks, managed runtimes, cloud platforms, and increasingly powerful tooling. Every layer made building easier. Every layer allowed more people to participate. And every layer created the same temptation: to assume that because the abstraction is powerful, the underlying understanding matters less.
In practice, the opposite tends to happen. The people who get the most value from a new abstraction are usually the ones who understand enough of what sits beneath it to use it well.
That is exactly how I think about AI.
Early in my career, I started in C++ on embedded systems, where understanding what was happening underneath the language really mattered. Later I moved into Java, C#, Node.js, and JavaScript, and even though I no longer had to think at that same low level day to day, that foundation continued to shape how I built software. It influenced how I thought about trade-offs, performance, abstractions, and system behaviour.
That experience is why I find the current “AI will replace software engineers” conversation a bit misleading.
AI can generate outcomes, but engineering is about shaping solutions
Coding agents are already very good at producing outputs. You can ask for a feature, a service, a refactor, or a workflow, and they can often generate something that looks impressive very quickly.
But producing an outcome is not the same as engineering a solution.
A solution is not just something that works once. It has to account for edge cases, implied requirements, maintainability, security, scalability, cost, and the broader system it lives inside. It has to solve the actual problem, not just the visible task.
That is where software engineering starts to matter.
If someone uses these tools without much engineering depth, they may still get an outcome, but they may not know what questions were never asked in the first place. They may not see the hidden trade-offs or the long-term weaknesses in what was generated. The tool can still produce code, but it cannot replace the judgment needed to decide whether that code is actually the right solution.
This is what the market seems to be rewarding
This has also come up repeatedly in conversations I’ve had with hiring managers, engineering managers, CTOs, and founders. What stands out is that they are not mainly looking for people who can simply code. They are looking for people who can solve problems, understand needs, navigate trade-offs, and connect technical decisions to business outcomes.
That feels important.
Because once implementation becomes easier and cheaper, the value shifts more clearly toward judgment, ownership, and problem-solving. In other words, toward engineering.
What I think is actually happening
I do think AI will compress some kinds of work, especially work that is mostly about taking a clearly defined task and turning it into code. But I don’t think that means software engineering disappears. I think it means the gap between coding and engineering becomes harder to ignore.
For years, those two things have often been treated as if they were the same. AI is exposing that they are not.
The engineers who will benefit most from these tools are not just the ones who can generate the most code. They are the ones who can frame problems well, apply constraints, evaluate trade-offs, and recognise when a plausible output is still the wrong answer.
That is why I don’t think AI is replacing software engineering. I think it is making real engineering more visible.
And maybe that is the more interesting shift: coding is getting cheaper, but engineering is getting more valuable.