AI Doesn't Replace Engineers Equally
The biggest impact of AI isn't that it replaces engineers. It's that it amplifies the gap between those who want to learn and those who want to avoid learning.
Yesterday I watched a video from Theo that stuck with me for the rest of the day.
He drew a simple diagram that split engineers across two dimensions:
- New vs. experienced
- Weak vs. strong
At first glance, it looked like another version of the classic skill matrix. But the interesting part wasn't the diagram itself.
It was what happens when AI enters the picture.
Most discussions around AI focus on whether it will replace developers. I think that's the wrong question.
The more important question is:
Who does AI make better, and who does it make irrelevant?
The Same Tool, Different Outcomes
People often talk about AI as if it affects everyone equally.
It doesn't.
Give the exact same AI tools to two different engineers and you'll get completely different results.
One engineer uses AI to avoid thinking.
The other uses AI to accelerate thinking.
The outputs may look similar today.
The skill growth won't.
The Engineer Who Stops Learning
There's a type of engineer that AI helps immediately.
They can generate code faster.
They can produce cleaner-looking solutions.
They can fix bugs they don't fully understand.
From the outside, their productivity appears to increase.
The problem is that nothing inside their head changes.
The AI becomes a substitute for understanding.
When something breaks outside the patterns they've seen before, they struggle.
When they're asked to design a system instead of implementing one, they struggle.
When they need to debug a production issue that requires deep understanding, they struggle.
Because while the output improved, the engineer didn't.
AI became a crutch.
And the scary thing about crutches is that they can make it difficult to notice you're no longer walking on your own.
The Engineer Who Uses AI as a Teacher
Then there's another type of engineer.
Usually newer.
Usually curious.
Usually willing to look stupid for five minutes in exchange for understanding something forever.
These engineers use AI differently.
They ask:
- Why does this work?
- What are the alternatives?
- What tradeoffs am I missing?
- Can you explain this like I'm new to the topic?
- What would happen if I changed this assumption?
Instead of replacing the learning process, AI compresses it.
What once required hours of searching through documentation, blog posts, and forum discussions can now happen in a single focused conversation.
The engineer still does the thinking.
They simply receive feedback faster.
And feedback speed has always been one of the biggest predictors of learning speed.
The Real Divide Isn't Experience
What surprised me most about Theo's diagram is that experience isn't the defining factor anymore.
We've all met people with ten years of experience who are effectively repeating the same year ten times.
We've also met developers with one or two years of experience who are growing at an incredible pace.
AI seems to amplify this difference.
The motivated junior engineer becomes dangerous much faster.
The stagnant senior engineer becomes easier to expose.
The gap isn't about intelligence.
It's about curiosity.
It's about whether someone wants to understand what's happening beneath the surface.
The End of "Google and Copy-Paste"
For years, many developers survived on a workflow that looked something like this:
- Search for a problem.
- Find a similar solution.
- Copy the code.
- Make small modifications.
- Move on.
To be fair, every developer has done this at some point.
The difference is that it used to be enough.
Today, AI can do that workflow faster than any human.
If your primary value comes from finding existing solutions and stitching them together, you're competing directly against a machine that's optimized for exactly that task.
The developers who thrive won't be the ones who know the most snippets.
They'll be the ones who understand:
- Architecture
- Tradeoffs
- System design
- Business requirements
- Debugging
- Communication
- Decision making
The things that happen before code is written and after code is deployed.
AI Is an Amplifier
One way I've started thinking about AI is that it's less like a replacement and more like an amplifier.
An amplifier makes a signal louder.
It doesn't change the signal itself.
If you're curious, AI amplifies curiosity.
If you're disciplined, AI amplifies discipline.
If you're constantly learning, AI accelerates learning.
But if you're lazy, it amplifies laziness too.
It allows you to produce more without necessarily becoming more.
That's why two engineers can use the same tools every day and end up moving in opposite directions.
What I'm Watching Closely
The trend that concerns me isn't AI replacing developers.
It's the widening gap between developers.
The people who actively learn are improving faster than ever before.
The people who avoid learning are finding more ways to hide that fact.
For now.
But eventually understanding compounds.
And so does the lack of it.
The difference becomes obvious when systems become more complex, stakes become higher, and problems stop matching the examples.
That's when the engineer has to think.
And thinking can't be outsourced forever.
A Question Worth Asking
I've been thinking about this question ever since I saw that diagram:
When you use AI, are you learning faster, or are you avoiding learning altogether?
Because the answer to that question might determine whether AI becomes the greatest accelerator of your career—or the reason you stop growing.