Every eighteen months since 2023, someone has announced that software engineering is about to end. The announcements have gotten more credible, because the tools have gotten genuinely good. And yet demand for experienced engineers has not collapsed — it has shifted.
Understanding why matters, because the answer is not "AI is not smart enough yet." It is structural, and it tells you what to hire for.
The Specification Problem
Here is the argument in one line: to fully specify what software should do, you have to write something as precise as code.
That is not a limitation of AI. It is what programming is. The reason we write code rather than describing intentions is that natural language is ambiguous, and computers require exactness. A prompt detailed enough to produce a correct, complete, secure system is a program written in a slower and less precise language.
What actually happens in practice: someone writes a prompt, gets 80% of what they meant, and then spends the remaining effort discovering the other 20% — usually through failure. The discovery process is engineering. Moving it from a text editor to a chat window does not eliminate it.
Software Is Mostly Not Code
Sit with a senior engineer for a week and count the hours. Writing new code is rarely the majority. The rest goes to:
- Figuring out what the requirement actually means
- Determining why the existing system behaves the way it does
- Deciding which of three bad options is least bad
- Understanding the blast radius of a change
- Reproducing something that only fails in production
- Negotiating scope with people who want incompatible things
AI helps with several of these — meaningfully so with the third and fifth. It does not remove any of them. The bottleneck in most software organisations was never typing speed.
Four Structural Reasons
1. Context that lives outside the codebase
The reason a table has a denormalised column is that a migration failed in 2023 and the rollback was never finished. The reason a service has a two-second timeout is that a downstream partner's SLA is soft. None of this is in the repository. It lives in people, in incident channels, and in institutional memory.
A model reading your codebase sees the what. Engineering decisions require the why, and the why is frequently undocumented and occasionally embarrassing.
2. Accountability cannot be automated
When a payment system double-charges 4,000 customers, an organisation needs someone who understands the system, can decide whether to roll back or patch forward, and can be accountable for that call. Regulators, boards, and customers require a responsible party.
You can automate a task. You cannot automate responsibility for the outcome of that task. This is why the highest-stakes systems — payments, healthcare, safety — have the most engineering oversight per line of code, not the least.
3. Correctness at the system level
Models are good at local correctness: this function does what it says. Software fails at the seams — race conditions between services, retry storms, partial writes, clock skew, cache invalidation under load.
These failures emerge from interactions, not from any single component being wrong. Reasoning about them requires holding a mental model of the whole system under adverse conditions, including the parts that are not in the context window because they are in a different repository, a vendor's infrastructure, or a database's locking behaviour.
4. The verification asymmetry
Generating a plausible solution is cheap. Verifying that it is correct is expensive — and verification is the part that requires expertise.
This creates an uncomfortable dynamic: AI dramatically increases the supply of code needing review, while the ability to review it well remains a scarce human skill. Teams that scaled generation without scaling verification are the ones currently in trouble. We wrote about the downstream cost in The Hidden Cost of AI-Generated Software.
What Is Genuinely Changing
Being clear about what AI cannot do should not obscure what it has already changed:
| Shifting away | Shifting toward |
|---|---|
| Writing boilerplate | Reviewing and verifying |
| Memorising APIs | System design and integration |
| Manual test authoring | Defining what correctness means |
| Implementation speed as a skill | Judgement and problem framing as skills |
The junior role is changing the most, and honestly. The traditional path — learn by writing a lot of straightforward code — is disrupted, because that code is now generated. New engineers need to develop review skill and system intuition earlier, which is harder to teach and requires more deliberate mentoring.
That is a real problem for the industry. It is not the same as engineers becoming unnecessary.
The Practical Read
If you are hiring: value judgement, debugging ability, and system-level reasoning over raw implementation speed. The candidate who can explain why a design will fail under load is worth more than the one who types quickly, and that gap is widening.
If you are an engineer: the durable skills are the ones AI does not touch — understanding a domain deeply, reasoning about failure, translating ambiguous human needs into precise systems, and being the person who can be trusted when it breaks.
If you are running a business: the mistake is not adopting AI too slowly. It is assuming that faster code generation means you need less engineering rigour. It means you need more, applied differently. Our take on the broader shift is in How AI is Transforming Businesses in 2026.
Building software that has to work — under load, under audit, at 3am — is still an engineering discipline. If you need a team that treats it that way, talk to us.