The Developer Is Not Dead. But the Role Is Changing Fast.
The New York Times just published a piece titled “Coding After Coders: The End of Computer Programming as We Know It.” They interviewed 70+ developers at Google, Amazon, Microsoft, and startups. Washington Post followed. Stanford published data saying AI is already bleeding jobs from young people in software development. And somewhere in San Francisco, a junior engineer anonymously told the SF Standard: “I’m basically a proxy to Claude Code. My manager tells me what to do, and I tell Claude to do it.”
I’ve been writing software for 12 years. I’ve heard “developers are done” more times than I can count — first it was low-code, then no-code, then offshore teams, then “anyone can code now with Stack Overflow.” Every wave came, every wave receded, and we were still here.
This time feels different. Not because AI will eliminate developers — it won’t — but because it’s changing what “being a developer” actually means, and the industry hasn’t figured out the implications yet.
The Part That’s Actually Scary
Let me be honest about the thing that keeps me up at night — and it’s not job losses.
It’s the pipeline.
AI tools are compressing junior developer onboarding from 24 months to 9 months. That sounds great. Except those same juniors are showing 17-point comprehension gaps compared to previous cohorts. They ship faster, but they understand less of what they’re shipping.
Meanwhile, 72% of tech leaders surveyed plan to reduce entry-level developer hiring. McKinsey estimates AI already automates 25–30% of tasks that used to belong to juniors.
So here’s the problem: who trains the next generation of senior engineers if juniors stop doing the foundational work?
Senior engineers became senior because they debugged horrible production bugs at 2 AM. They traced memory leaks. They optimized a query that was killing the database. They built something from scratch and watched it fall apart and learned why. You don’t get that from reviewing AI-generated code and clicking “accept.”
The skill atrophy is real. And it’s a problem we’re going to feel in 5 years, not today.
What’s Actually Being Automated (And What Isn’t)
Let me be precise here, because the headlines aren’t.
AI is genuinely good at:
- Boilerplate and repetitive code patterns
- CRUD operations, standard API integrations
- Unit tests for well-defined functions
- Converting designs to code (the mechanical part)
- Explaining existing code
- First drafts of anything
AI consistently struggles with:
- Understanding why a system is designed a certain way
- Context-aware architectural decisions
- Debugging distributed systems failures
- Performance optimization that requires understanding the full stack
- Security-critical code that needs adversarial thinking
- Anything involving ambiguous, evolving business requirements
Notice what the second list has in common: judgment, context, and experience. That’s not a coincidence.
What This Means If You’re a Junior Dev Right Now
This is the section I’d want someone to have sent me if I were starting out today.
Don’t outsource the learning. Use AI for shipping, but deliberately practice without it. Take the ugly ticket nobody wants. Debug something manually. Write the query by hand before asking AI to optimize it. Your side projects are where you build real skills now — treat them like a deliberate practice gym.
Understand what you ship. If you can’t explain the code AI wrote for you, you don’t own it. That’s not skill — that’s liability. A senior engineer will spot it instantly in a code review. More importantly, you won’t be able to debug it when it breaks at 3 AM.
Move toward judgment, not output. The developers who will thrive are the ones who can look at an AI-generated solution and say “this is wrong for our system and here’s why.” That requires knowing architecture, understanding trade-offs, and having opinions built from experience. Start developing that now.
Pick a depth specialty. Generalist “I know a bit of everything” is becoming commoditized. Distributed systems, security, performance engineering, AI integration, domain-specific complexity (fintech, healthcare, logistics) — pick something hard and go deep.
What This Means If You’re a Senior
Your job description just changed whether your company knows it yet.
You’re no longer primarily evaluating whether code works. You’re evaluating whether code is maintainable, secure, and architecturally sound — because AI can make broken, insecure, architecturally unsound code look completely reasonable on first read.
The bar for code review just went up dramatically. You need to ask: does this person understand what they shipped, or did they just accept a suggestion?
You’re also now in the business of intentional skill development in a way you weren’t before. If your juniors never struggle through hard problems, you’re not building a team — you’re building a group of prompt operators who will be helpless without the AI.
The Real Take
I’m not afraid of AI replacing developers. I am paying close attention to what happens to the craft of software development when the tedious parts disappear.
The tedious parts taught us things.
Debugging that nasty bug for three days taught us to read code slowly. Writing boilerplate taught us patterns. Struggling with SQL taught us to think about data. You skip that and you skip the building blocks of intuition.
The developers who will matter in 5 years are the ones who use AI as a tool to go faster and deeper — not the ones who use it as a replacement for understanding. AI is raising the ceiling of what one developer can build. But it’s also quietly lowering the floor of what developers actually know.
That gap is where the real story is. And we should be talking about it more.
Are you a junior dev navigating this transition? Or a tech lead trying to figure out how to build a team in this environment? I’d love to hear how you’re thinking about it — find me on X.