
For a while there I genuinely wondered if my job was about to disappear. The AI assistants got good — startlingly good — at writing code. Watching one generate a working feature from a sentence is a strange experience when writing code is supposedly what you do for a living.
So I did what a lot of developers did. I panicked a little, then I paid close attention. I wanted to know which parts of the job were getting automated and which parts were getting more valuable.
The answer surprised me. The most durable skill wasn't a language, a framework, or anything you'd find on a "skills to learn in 2026" list. It was something quieter, and AI made it the whole game.
The developer skill that survived — and got more valuable — is the ability to clearly define the problem: to figure out what should be built and why, precisely enough that it can be built correctly. AI can write the code. It cannot decide what code is worth writing. That judgment is now the job.
The short version:
Here's the uncomfortable truth that the AI wave made obvious: a lot of "programming" was really just translation. You knew what you wanted, and you laboriously translated that intent into syntax the computer understood.
AI is exceptional at translation. Tell it clearly what you want and it produces the syntax in seconds. The mechanical act of writing code — the loops, the boilerplate, the standard patterns — turns out to be the most automatable part of the whole craft.
For a moment that feels like the end of the profession. If the computer can write the code, what's left?
What's left is everything that was always actually hard. AI automated the answer-producing. It did nothing for the question-asking — and in software, asking the right question is most of the work. That's the same judgment I keep circling back to in the brutal truth about becoming a senior developer: the value was never the typing.
Photo by Mariia Shalabaieva on Unsplash
The skill that survived, and thrived, is problem definition. Knowing, precisely, what needs to be built and why.
This was always the hard part, but it used to hide behind the typing. When writing code took most of your time, the thinking got smeared across the whole process — you'd figure out what you wanted as you built it, course-correcting in syntax.
Now the typing is nearly free. Which means the thinking stands exposed, and it's clearly the bottleneck. When you can generate a feature in seconds, the question isn't "can I build this?" It's "is this the right thing to build, and do I understand it well enough to build it correctly?"
That question contains all the genuinely difficult work:
None of that is typing. All of it is judgment. And AI, for all its power, has none of it — it produces what you ask for, brilliantly, even when what you asked for is wrong.
Working with AI day to day made the shift concrete. The bottleneck physically moved, and you can feel where it landed.
| Phase | Before AI | After AI |
|---|---|---|
| Decide what to build | Hard | Hard (and now the bottleneck) |
| Specify it precisely | Often skipped | Essential — AI needs it |
| Write the code | Slow, most of the time | Fast, nearly free |
| Verify it's correct | Important | Critical — you must judge the output |
Notice what happened. The cheap part — writing code — got cheaper. The expensive parts — deciding and specifying and verifying — stayed expensive and became the entire job. The clearer and more precise your thinking, the better the AI's output. The vaguer your thinking, the more confident garbage you get back.
I started seeing AI as an extraordinarily fast junior developer who types perfectly and thinks not at all. It will build exactly what I describe. So the quality of what I get is capped entirely by the quality of my description. The work became describing — which is roughly what I found when I tried coding with only AI for two weeks: the bottleneck moves to how precisely you can think. Surveys like GitHub's Octoverse show how fast AI-assisted development is being adopted, which only sharpens how much the human judgment matters.
AI didn't replace the developer. It deleted the easy half of the job and left us alone with the hard half.
If problem definition is the durable skill, it's worth deliberately building. Here's what's worked for me:
The reassuring part is that these are the skills that made someone a senior engineer all along. AI didn't invent a new game. It just made the thing that always separated good developers from fast typists into the only thing that matters.
Photo by Ilya Pavlov on Unsplash
It's easy to read all this as a loss. I read it as a gift.
The tedious part of the job — the boilerplate, the syntax-wrangling, the rote translation — got handed off to a machine that's genuinely better at it. What's left is the interesting part: understanding problems, making judgment calls, designing solutions, deciding what's worth building.
That's the part most of us got into this work for in the first place. The AI wave didn't take the soul of the job. It took the chores and left the craft. The developers who'll thrive aren't the ones who type fastest — that race is over and the machine won. They're the ones who think clearest about what to build.
If staying durable in an AI-shaped industry is on your mind, it's worth following along for more of these honest takes.
Q: Should I stop learning to write code by hand? No. You can't define problems well or judge AI output if you don't understand code deeply. The skill shifted from producing code fast to reasoning about it well, and the second still requires real fluency. Learn to code — just know that the typing speed isn't where your value lives anymore.
Q: Won't AI eventually do the problem definition too? AI can help explore and refine a problem, but defining what should exist requires understanding human needs, business context, and trade-offs in a messy real world. That's a fundamentally different kind of task from generating code from a clear spec. For the foreseeable future, deciding what's worth building stays a human job.
Q: Does this mean junior developers are in trouble? It means the path changed. The old route — get fast at writing code, then slowly develop judgment — is disrupted, because fast code-writing is now cheap. Juniors who lean hard into understanding problems, reading code critically, and learning trade-offs will rise faster than ever. The skill ceiling moved up, not away.
Q: How is this different from just "being a senior engineer"? It isn't, really — and that's the point. The judgment that defined senior engineers was always the scarce, valuable thing. AI simply removed the camouflage of typing speed that let people look productive without it. The durable skill was always there; now it's the whole job.
AI can write the code. It cannot decide what code is worth writing, understand the real problem, or judge whether the result is actually right. Those were always the hard parts — they were just hidden behind the keyboard.
The skill that survived the AI wave is the oldest one: thinking clearly about what to build and why. Everything else got automated. That got essential.
So if you're worried about staying relevant, don't chase the next framework. Get unreasonably good at understanding problems and judging solutions. The machine will handle the typing. The thinking is yours, and it's worth more than it's ever been.
I went from 200 to 11,000 subscribers without hiring anyone. AI didn't write my newsletter — it did everything around it.

One person, output that looks like five. It isn't about working more hours — it's about a kind of leverage teams rarely have.

One idea a week to a published issue in under an hour. The boring system behind a newsletter I never dread sending.

Comments
Sign in to join the conversation
No comments yet. Be the first to share your thoughts!