For years, I thought being a good programmer meant knowing your stack really well. I was a Laravel developer, A React developer, A Node.js developer and A Go developer.
And there was some truth to that.
I spent years working with Laravel, for example, and naturally became faster at solving problems with Laravel. I know the ecosystem, the common mistakes, the packages, the conventions, and probably a few things that weren't even written in the documentation.
My stack became part of my identity as a developer.
But I think AI is slowly changing that.
Not because frameworks and programming languages don't matter anymore. They obviously do.
It's because AI has made moving between them much easier.
Today, I can open a codebase written in a language or framework I haven't touched in years, or maybe have never used seriously, and get productive much faster than I could before.
I can ask AI to explain the project structure.
I can ask it to explain a piece of code.
I can ask it to translate something I understand in PHP into Go.
I can ask it to help me write tests.
I can use it while debugging.
I can even ask it why a particular approach might be a bad idea.
That doesn't suddenly make me an expert in that technology.
But it means I don't need to spend weeks just getting comfortable enough to start solving the actual problem.
And I think that's a pretty big change.
Your Stack Is Becoming Less Important
There was a time when knowing a technology itself was a significant advantage.
If you knew Laravel, you had to learn Laravel.
If you wanted to learn React, you had to spend time understanding React.
If you wanted to work with Kubernetes, good luck.
You read documentation, watched tutorials, built things, broke things, fixed them, and slowly built up experience.
That's still how you become good.
But AI has changed the entry point.
The first few hours with a new technology are no longer as painful as they used to be.
You can have an AI sitting beside you explaining things as you go.
That's why I think we're going to see more programmers become stackless.
Not literally stackless.
We will still have people who specialize in certain technologies.
But I think the idea of a developer being defined primarily by their stack will become less important.
The question won't be:
"Are you a Laravel developer or a Go developer?"
It will increasingly be:
"Can you solve this problem?"
And then:
"What is the best way to solve it?"
This is where I think things get interesting.
You might assume that if AI can write code, engineering experience becomes less important.
I actually think the opposite is happening.
Because writing the code has never been the whole job.
Imagine I ask an AI:
Build me a payment system.
It can probably generate a surprisingly good starting point.
But then what?
What happens if the payment provider sends the webhook twice?
What happens if the payment succeeds but our server crashes before updating the database?
What happens if the customer closes the browser halfway through the payment?
What happens if the provider times out but the payment actually went through?
What happens if Redis goes down?
What happens if our queue is delayed for 30 minutes?
What happens when we have 100,000 transactions instead of 100?
What happens when someone tries to exploit the system?
Those aren't really syntax problems.
They're engineering problems.
And you usually learn to think about them because you've been burned by them before.
Maybe you've shipped something that worked perfectly in development and fell apart in production.
Maybe you've dealt with duplicated webhooks.
Maybe you've had a database lock bring down part of your application.
Maybe you've had Redis disappear at the worst possible time.
Maybe you've spent six hours debugging something that turned out to be one line of code.
Those experiences change how you think.
And that's something AI can't simply give you by generating another 500 lines of code.
I think one of the biggest changes AI brings to programming is that the quality of your questions matters more.
A developer with little experience might ask:
"Write a payment service."
An experienced engineer might ask:
"Design a payment service that is idempotent, handles provider timeouts and duplicate webhooks, supports reconciliation, and doesn't mark an order as paid until the transaction can be verified."
Same AI.
Very different result.
The difference is not necessarily the ability to type better prompts.
It's understanding the problem well enough to know what questions need to be asked.
That's engineering experience.
And as AI gets better at writing code, I think this becomes even more important.
This is probably the part I'm most excited about.
AI makes it easier for programmers to become curious.
You don't have to say:
"I'm a PHP developer, so I don't touch Go."
You can learn Go.
You don't have to say:
"I don't know Kubernetes, so I can't understand what's happening here."
You can investigate it.
You don't have to spend three days trying to understand an unfamiliar library before making your first change.
You can ask questions while you're learning.
This means programmers can become broader without necessarily becoming shallow.
A backend engineer can understand more frontend concepts.
A frontend engineer can understand infrastructure.
A web developer can explore distributed systems.
Someone working primarily with SQL can start understanding event-driven architectures.
The boundaries between disciplines become easier to cross.
And I think that's a good thing.
Being able to use AI to generate code is not the same thing as being an engineer.
In fact, I think AI might make bad engineering easier to produce.
You can now generate an impressive amount of code very quickly.
And that's dangerous if you don't understand what you're generating.
You can create a beautifully structured system that doesn't solve the actual problem.
You can introduce unnecessary microservices because AI suggested them.
You can add five layers of abstraction to a simple application.
You can copy a security pattern that looks correct but has a subtle vulnerability.
You can generate code that passes your tests and still fails in production.
AI can make you faster.
But it can also make you wrong faster.
That's why experience matters.
I don't think the future belongs to programmers who know the most frameworks.
And I don't think it belongs to programmers who know the most AI tools either.
The real advantage is going to be the engineer who can take a messy problem, understand it, break it down, make good decisions, use whatever tools are available, and know when those tools are wrong.
AI is reducing the value of memorizing syntax.
It's reducing the friction of learning new technologies.
It's reducing the cost of moving between stacks.
But it's increasing the value of something much harder to acquire:
engineering judgment.
You can ask AI how to implement something.
But you still need to know whether you should implement it.
And maybe that's where programming is heading.
Less about being the person who knows every tool.
More about being the person who knows what to build, why to build it, and what could go wrong.
The stack isn't disappearing.
It's just becoming less of the identity.
The engineer is becoming the moat.