Every few weeks somebody sends me a scary headline — “AI will replace all programmers by next year.” And every few weeks some senior engineer replies “nothing will change, relax.” Both are wrong, and both are lazy. The truth is in the middle, and it is actually more interesting than either. Something real IS changing, but it is not the thing most people are panicking about. Let me share how I am thinking about it, plainly.
I have been writing code for many years now, and I use AI every single day to write code. So this is not a theory for me — it is what my own work looks like today. Let us talk honestly about where this is going.
What is actually changing
AI is getting very good at one specific thing: turning a clear idea into working code. Give it a well-defined task and it will produce the function, the test, the boilerplate, faster than any of us can type. That is genuinely a big deal and I don’t want to downplay it.
But here is the part people miss. Writing the code was never the whole job — it was just the most visible part. Think about everything you actually do in a day.
Look at that chain. Writing code is one box out of six. The other five are all about judgment:
- Framing the problem — figuring out what actually needs to be built, and why. AI cannot sit in the meeting and understand that the “login bug” the customer reported is really a trust problem that needs a different solution entirely.
- Designing it — choosing the right trade-offs so the thing holds up at scale, six months later, when ten other features depend on it.
- Verifying it — and this one is huge. AI writes code that looks correct and confident, exactly like a junior who is very sure of themselves. Somebody with real understanding has to check it is actually right. The AI will not catch its own subtle bug.
- Integrating and owning it — wiring it into a messy real system, and being the person who gets paged at 2am when it falls over in production.
So the work is not vanishing. It is shifting. The cheap part (typing) got automated, so the value moved to the expensive parts: deciding the right thing to build, and making sure it is genuinely correct and reliable. The engineer who only typed is in a tough spot. The engineer who thinks, decides and verifies is more valuable than before, not less.
Which roles rise, which shrink
Now the question everyone actually wants answered. I will be honest here, even the uncomfortable parts.
Please don’t read this as “juniors are finished” or “my favourite language is dead.” That is the wrong way to look at it. The honest question is much simpler: what do you add that the AI cannot?
If your only real answer was “I write code quickly” — that moat is drying up fast, and we should be clear-eyed about it. But if your answer is “I understand the problem, I design the right thing, I catch the bugs the AI misses, I own it when it breaks, and I know this domain deeply” — then you are becoming more valuable, because now you can do all of that AND have AI do the typing for you. One good engineer with AI leverage can now do what used to need a small team.
The roles that shrink are the ones that were only ever typing. The roles that grow are the ones that decide, verify and take ownership.
What to watch out for
A few honest warnings, because I have seen these creeping in — including in myself.
- Skill atrophy is real. If you let AI write everything and you stop thinking, your own fundamentals quietly rust. Six months later you cannot debug a hard problem because you have not actually solved one yourself in a while. This is the biggest danger, and it is silent.
- Verification debt. Shipping AI code you did not really read is borrowing against the future. It works today, and then one day their is a subtle bug nobody understands because nobody actually wrote that part. Read what you ship.
- The junior’s dilemma. Juniors learn by doing the “easy” work — and that is exactly the work AI now does. So juniors have to be more deliberate: don’t just accept the AI’s code, fight with it, understand it, break it. The ones who do this will become excellent seniors faster than ever. The ones who don’t will stay stuck.
- Over-trusting confident output. AI is confidently wrong very often. Treat it like a fast, talented, slightly careless colleague whose work you always review — not an oracle.
So what is the actual future?
Here is my honest belief: software engineering is not dying, it is growing up. For a long time our field rewarded people mostly for typing speed and knowing syntax. That era is ending, and good riddance. What is coming rewards judgment, taste, verification and ownership — the things that were always the real job underneath.
That is genuinely good news for anyone willing to keep learning, beacuse judgment is not something you are born with. You build it, deliberately. That is what the companion article — How to Stay Valuable as a Software Engineer in the AI Era — is entirely about: the concrete skills to build, how to learn faster using AI (without hollowing yourself out), and the exact habits that keep you on the right side of this shift.
Takeaways
- AI automates typing code — but that was one step out of six. Value moves to judgment (framing, design) and verification (catching the AI’s bugs, owning the outcome).
- Rising roles: outcome-owning seniors/staff, AI/ML engineers, systems/reliability, security, domain experts who code, “force multipliers.” Shrinking roles: pure ticket-to-code churn, boilerplate-only, manual-only QA, “typing by headcount.”
- The real dividing line is not senior-vs-junior or language-vs-language — it is “what do you add that the AI can’t?”
- Watch out for skill atrophy, verification debt, and over-trusting confident-but-wrong output. Read what you ship.
If you found this useful, the hands-on continuation is the playbook article. See also the AI-era practice guides on commits, pull requests and code review, and the AI Agent Development course if you want to build with this stuff.
