Coding Was Only a Transition Phase

There's a take going around that AI is coming for software engineers. My mum believes it. A lot of people on LinkedIn believe it. And honestly, if you define software engineering as "writing code for a living," they might have a point.

But that definition was always wrong.

The Linus Argument

Linus Torvalds built Git in his spare room. No AI, no Stack Overflow, no LLM to autocomplete his thoughts. Just a man with a deep understanding of system principles and the discipline to translate them into working software. What he built was genuinely complex for its time, not because the syntax was hard, but because the thinking behind it was hard.

Fast forward to today. Anyone can scaffold a CRUD API in minutes. You don't need an MIT degree to ship a web app. The tools have democratized the mechanical parts of the job so thoroughly that "I can write code" is no longer a differentiator: it's a baseline.

So if the baseline is gone, what's left?

What Actually Survives

I know a senior engineer who ships entire SaaS products in days. The common reaction is dismissal: he's just using AI, it won't hold up. But that reaction misses the point entirely.

He ships fast because he understands why systems fail. He knows which corners are safe to cut and which ones will collapse under load at 2am. He designs for observability before he designs for features. He treats every line of code as a liability, something that will need to be read, debugged, and eventually replaced, not as an achievement.

That judgment isn't something you prompt out of a model. It comes from internalizing how systems behave under pressure, how failures cascade, and how to build things that remain predictable when the unexpected happens.

The Shift That's Already Happened

The craft was never really about syntax. It was always about:

• Systems thinking — understanding how components interact and fail together
• Translating intent — turning ambiguous human problems into precise, executable specifications
• Designing for failure — building systems that degrade gracefully rather than collapse catastrophically
• Judgment under uncertainty — knowing when to ship and when to hold

AI accelerates the mechanical execution of all of this. It does not replace the thinking that precedes it.

What This Means for Engineers Today

If you're still optimizing for syntax recall, you're training for a job that's already been automated. The engineers who will matter in the next decade are the ones who can look at a system and immediately understand its failure modes, before writing a single line.

That means reading more architecture post-mortems than tutorials. It means caring about why a system exists before caring about how to build it. It means treating "it works on my machine" as the beginning of the conversation, not the end.

Code is a medium. The message is the system.

In Closing

I'd choose this path in every lifetime, not because I love writing code, but because I love the problem of making complex systems reliable and understandable. That problem isn't going anywhere. If anything, AI makes it more important, because now the bottleneck isn't implementation speed: it's the quality of the thinking that drives it.

Don't be the engineer who competes with autocomplete. Be the one who decides what gets built and why it won't break.

That job has never been more relevant.