Is it still worth learning to code?

Yes, but learn to read code more than you learn to write it. Reviewing, debugging, and judging generated code is now the higher-value half of the skill, and you cannot do any of it without being able to write code yourself.

Are junior developer jobs disappearing?

Junior hiring has contracted, because the tasks juniors were traditionally given are the tasks models handle best. The route in now runs through demonstrating judgement early rather than accumulating volume of simple tickets.

Will there be fewer software engineers in ten years?

Nobody credible knows. Historically, every drop in the cost of producing software has increased the amount of software the world builds. That pattern may hold or it may not. Planning around either certainty is a mistake.

What should an experienced developer focus on now?

The parts a model cannot do: deciding what to build, understanding a business well enough to know which requirement is wrong, owning production, and maintaining systems whose context is not written down anywhere.

Is software engineering dead?

Every few years the industry announces its own death. Offshoring was going to do it. Then low-code. Then bootcamps flooding the market. Then no-code. The job is still here and it pays better than it did during any of those panics.

That said, the current round is not the same as the previous rounds, and pretending it is would be dishonest. Something real has changed.

What actually changed

The cost of producing a unit of working code fell hard.

Not to zero. It still takes someone who knows what they are doing to get a non-trivial change into production without breaking something. But the part of the job that was “translate this clear specification into correct syntax” has genuinely been compressed, and that used to be a lot of hours.

If your value was mostly in that translation step, your value took a hit. That is uncomfortable and it is true.

What did not change

Deciding what to build. Models do not know which feature will matter, and a business cannot usually tell you either. Someone has to sit with the people who do the work, watch them, and figure out what is actually wrong.

Knowing when a requirement is wrong. The most valuable thing an experienced developer does in a planning meeting is say the requested thing will not work, and explain why, before three weeks are spent building it.

Owning production. A model does not get paged. It does not carry the knowledge that the invoicing job fails on the last day of the month because of a timezone bug someone worked around in 2019 and never documented.

Maintenance. Most software work is not building new things. It is changing existing things without breaking the parts that already work. That requires holding context nobody wrote down, and it is exactly where generated code is weakest, because the context is not in the repository.

The part that actually hurts

Junior hiring.

The traditional path in was: be handed small, well-specified tasks, do a lot of them, gradually accumulate judgement. Those small well-specified tasks are the ones that got automated first. The bottom rung was removed while the ladder above it stayed the same height.

This is a genuine structural problem and the industry has not solved it. The practical answer for anyone starting out is to get to judgement faster: build things end to end, own something in production, and be able to explain why you made each decision. Volume of tickets completed is no longer the currency.

What the job turns into

Fewer hours writing, more hours reading. More time deciding. More time reviewing work you did not write and being accountable for it anyway. Broader scope per person, because one person can now cover ground that used to need three.

That is not the death of a profession. It is what happened to every profession that got better tools. It does mean the distribution of who does well shifts, and it shifts towards people with judgement and away from people with typing speed.

The strange side effect

Here is something almost nobody has noticed.

The same models compressing the writing half of the job are trained on code. They need more of it, and specifically they need the kind that was never published, because public code is already collected and heavily over-represented by libraries and tutorials.

Which means the accumulated output of a long career has become a thing labs will pay to license. Not sell. License, non-exclusively, so you keep it.

Twenty years of shipped client work used to be pure past tense. It now has a second life, and most developers sitting on that archive have not connected the two facts.

┌─ WORTH CHECKING ─────────────────────────────────────────────────────┐
│                                                                      │
│  Private, finished, owned by you, and doing nothing.                 │
│                                                                      │
│  [ See what your repos are worth ]                                   │
│                                                                      │
└──────────────────────────────────────────────────────────────────────┘

The honest summary

Software engineering is not dead. The specific activity of converting a clear specification into working syntax is worth much less than it was, and if that was the whole of your job then the whole of your job is under pressure.

Everything around it, the deciding, the judging, the owning, the maintaining, is worth more, because there is now more code in the world to decide about, judge, own, and maintain.

Plan for that, not for either extreme.