Everyone is talking about AI replacing developers.
I think that is the boring version of the conversation.
The more interesting version is this:
AI is not killing developers.
AI is killing the illusion that typing code all day automatically means you are creating value.
And honestly, that illusion needed to die.
For years, a lot of software work has been judged by visible activity.
More commits.
More tickets.
More meetings.
More Slack updates.
More “quick syncs.”
More dashboards.
More Jira movement.
More lines of code.
Somewhere along the way, we confused motion with progress.
Now AI tools are exposing that confusion very quickly.
Because if a tool can generate a component, write boilerplate, create tests, explain an error, summarize documentation, and scaffold a small app in minutes, then the valuable part of development was never just typing.
It was knowing what should exist in the first place.
The new flex is not speed
Speed is everywhere now.
Everyone can build faster.
Everyone can prompt faster.
Everyone can ship a half-working prototype faster.
That is not the hard part anymore.
The hard part is knowing when not to build.
That sounds less exciting, but it is becoming one of the most important software skills.
Anyone can ask an AI tool to create a dashboard.
But should the dashboard exist?
Anyone can generate five landing page variants.
But do users understand the offer?
Anyone can vibe-code an app over the weekend.
But does the app solve a real problem?
Anyone can create more features.
But does the product become better, or just louder?
The developers who stand out now are not the ones who blindly generate more.
They are the ones who can judge what matters.
Vibe coding is fun, but vibes are not architecture
I get the appeal of vibe coding.
You describe what you want, the tool creates something, and suddenly an idea becomes visible.
That is powerful.
It lowers the barrier to building.
It helps non-technical people experiment.
It helps developers move faster.
It makes side projects feel alive again.
But there is a catch.
Software does not only need to run.
It needs to survive contact with users, edge cases, scale, security issues, future changes, messy data, and tired humans maintaining it six months later.
The prototype can be a vibe.
Production cannot be only a vibe.
At some point, someone has to ask boring but important questions:
- What happens when this fails?
- Who owns this data?
- Can this be tested?
- Can another developer understand it?
- Is the generated code doing what we think it is doing?
- Are we adding complexity because it looks impressive?
- Will this still make sense after the demo?
That is where engineering still matters.
Not because developers type better than AI.
Because good developers notice what the generated output does not explain.
The junior developer problem is really a learning problem
A lot of newer developers are worried right now.
That fear makes sense.
If AI can generate beginner-level code, what happens to beginner-level developers?
But I do not think the answer is “juniors are useless now.”
The real issue is that the old learning path is breaking.
Before, you learned by writing small pieces of code, making mistakes, debugging them, reading documentation, and slowly building judgment.
Now, AI can skip some of those painful steps.
That sounds good until you realize the painful steps were where the learning happened.
If someone builds ten projects with AI but cannot explain the tradeoffs, debug the failure, or reason about the system, they did not become a developer.
They became a passenger.
The goal should not be to avoid AI.
That would be unrealistic.
The goal is to use AI without outsourcing your thinking.
Ask it for help.
Ask it to explain.
Ask it to compare approaches.
Ask it to generate tests.
Ask it to find flaws.
But do not let it become the only brain in the room.
We are entering the age of taste
This may sound strange, but taste is becoming a technical advantage.
Not taste as in “make it pretty.”
Taste as in knowing what is good.
Good UX.
Good naming.
Good abstractions.
Good tradeoffs.
Good defaults.
Good documentation.
Good error messages.
Good product decisions.
Good enough for now versus dangerous shortcut.
AI can produce options.
A strong developer can evaluate them.
That difference matters.
When everyone can generate code, the scarce skill becomes judgment.
The person who knows what to keep, what to delete, what to simplify, and what to question will be more valuable than the person who just produces more output.
Productivity theater is getting exposed
This is probably the part people do not want to admit.
A lot of modern work is performance.
We perform productivity in meetings.
We perform urgency in Slack.
We perform progress in ticket updates.
We perform intelligence by making simple things sound complicated.
AI makes this harder to hide.
If a task that used to take three days now takes three hours, the question becomes:
What were we actually doing with the rest of the time?
Sometimes the answer is valid.
Planning matters.
Testing matters.
Communication matters.
Review matters.
Context matters.
But sometimes the answer is uncomfortable.
We were waiting.
We were overcomplicating.
We were rewriting the same thing.
We were building features nobody asked for.
We were protecting processes that no longer made sense.
AI will not fix bad management.
It may actually make bad management louder.
But it will force teams to ask better questions about where time really goes.
The future developer is not just a coder
The future developer looks more like a hybrid.
Part engineer.
Part product thinker.
Part debugger.
Part architect.
Part editor.
Part systems thinker.
Part person who can say, “This is not worth building.”
That last part is underrated.
Because when building gets cheaper, saying no becomes more valuable.
Teams will not struggle because they cannot create enough software.
They will struggle because they create too much software without enough thinking.
Too many tools.
Too many dashboards.
Too many automations.
Too many internal apps.
Too many features.
Too many AI-generated workflows that nobody maintains.
The bottleneck will not always be production.
It will be direction.
So what should developers do?
Do not panic.
But also do not pretend nothing is changing.
The safest move is not to compete with AI at the level of typing.
That is a losing game.
Instead, get better at the parts AI makes more important:
Understand systems.
Learn product thinking.
Get good at debugging.
Write clearly.
Review code deeply.
Understand security basics.
Learn how to test.
Improve your taste.
Ask better questions.
Build things users actually need.
Know when a simple solution is better than a clever one.
And most importantly, stay close to the “why.”
Why does this feature exist?
Why does this bug matter?
Why does this user care?
Why is this architecture worth the complexity?
Why are we building this at all?
The developer who understands the why will always have leverage.
The uncomfortable truth
AI is not coming for developers equally.
It is coming first for shallow work.
Boilerplate.
Repetition.
Unclear tickets.
Copy-paste development.
Resume-driven architecture.
Features built only because someone said “we might need it later.”
But AI also creates a trap.
It lets people produce shallow work faster than ever.
So the real divide will not be AI users versus non-AI users.
It will be thoughtful builders versus output machines.
The thoughtful builder uses AI to think better, move faster, and test ideas.
The output machine uses AI to create more noise.
One becomes more valuable.
The other becomes easier to ignore.
Final thought
AI did not make software easier.
It made pretending harder.
It made it harder to pretend that more code means more value.
Harder to pretend that speed means clarity.
Harder to pretend that a working demo means a good product.
Harder to pretend that developers are only paid to type.
That is a good thing.
Because the best developers were never just typists anyway.
They were translators.
They translated messy human problems into useful systems.
That work is not disappearing.
It is becoming more obvious.
Top comments (0)