Every technological revolution looks the same from a distance. A new tool appears. It’s powerful. People panic. Some people lose their jobs. But the people who learn to use the tool — really use it, not just poke at it — they end up more valuable than before. Every single time.
The printing press didn’t kill writers. It killed scribes. The ones who just copied text. The ones who could think, compose, and edit? They thrived. They had a distribution machine now.
AI is the same story. It’s not replacing engineers. It’s replacing engineers who don’t think.
The opportunity is enormous — and it has an expiry date
Right now, in 2026, we are in the window. The train is at the station. The doors are open. Most people are still standing on the platform arguing about whether the train is real.
If you are an engineer — civil, mechanical, electrical, physics, math, whatever — you already have the hard part. You can think in systems. You understand constraints. You know that a 10% safety factor is not the same as a 50% safety factor and you know when each matters. You can do math. You can reason about failure modes.
That is exactly the mindset software engineering requires. And it’s the mindset that most people prompting ChatGPT to write code do not have.
You have an unfair advantage. Use it.
But you need fundamentals
Here’s where most people screw this up. They see AI writing code and they think: “great, I don’t need to learn the fundamentals. I’ll just describe what I want and the AI will build it.”
That works for a toy project. It falls apart the moment anything real happens.
Real means: the system has to scale. Or it has to be secure. Or it has to talk to three other systems. Or the database schema you picked in week one is now a bottleneck and the whole thing needs restructuring. Or — and this is the most common one — the AI generated something that looks correct, runs without errors, and gives you the wrong answer.
If you don’t understand architecture, you can’t tell AI what to build. If you don’t understand trade-offs, you can’t evaluate what it built. If you don’t understand testing, you won’t catch the bugs. If you don’t understand the deployment pipeline, you can’t ship.
Fundamentals are not the boring stuff you learn before you get to the good stuff. Fundamentals are the good stuff. They’re the difference between someone who can direct AI to build a real system and someone who can only ask it to write a function.
Thinking like a developer
There’s a specific way developers think that is different from how most people think about computers. It’s not about knowing syntax. It’s about mental models.
A developer thinks: “this system has three components. Component A talks to Component B through an API. If B goes down, what happens to A? What happens to the user? Where do we put the retry logic? What’s the timeout?”
A non-developer thinks: “it works on my machine, ship it.”
The developer is thinking about failure modes. About boundaries between systems. About what happens when things go wrong — not just when things go right. This is exactly how a structural engineer thinks about a bridge. You don’t just design for the average load. You design for the worst case. You think about what fails first and what cascades from there.
That transfer of thinking — from physical engineering to software engineering — is what makes engineers so dangerous in this field once they get the vocabulary right. You already have the instincts. You just need the words.
The train is leaving
I say this bluntly because I think it matters: the window to get on board is not infinite.
Right now, a mechanical engineer who learns software architecture and AI tooling is rare and incredibly valuable. In five years, it’ll be expected. In ten years, it’ll be the minimum. The people who move now will be the senior engineers, the team leads, the architects. The people who wait will be playing catch-up forever.
This is not speculation. This is the pattern from every previous wave. The engineers who learned CAD early dominated. The ones who learned simulation early dominated. The ones who learned data analysis early dominated. Every time, the early movers captured a disproportionate share of the opportunities.
AI is the biggest one yet. And unlike learning CAD, the barrier to entry is lower than ever. You don’t need a CS degree. You don’t need to go back to university. You need a laptop, curiosity, and the willingness to be a beginner for a few months.
What to actually do
Start with the environment. If you can’t navigate a terminal, manage files, use Git, and SSH into a remote machine, nothing else works. That’s Dev Environment for Engineers.
Then learn how software engineers think. Not how to code — how to think. Architecture. Trade-offs. Patterns. What happens when your system has 10 users vs. 10,000. When to use a monolith vs. microservices (hint: almost always a monolith). How to test, deploy, and monitor. That’s Software Engineering Fundamentals & Systems Thinking.
Then use AI to build things. Real things. Not tutorials — things that solve a problem you actually have. You’ll make mistakes. The AI will make mistakes. But now you’ll have the foundation to catch those mistakes, fix them, and learn from them.
The machine always wins. That’s been true since the industrial revolution. But the machine needs a driver. And the driver who understands what’s under the hood — who can think in systems, reason about trade-offs, and take responsibility for the output — that driver will never be replaced.
The train is at the station. Get on.