Will AI replace programmers?
Not as a category. It is replacing a task, which is turning a clear specification into working syntax, and that task used to fill a lot of hours. The work that remains is deciding what to build, judging whether generated code is right, and owning systems in production, and demand for that has gone up rather than down.
The question is badly posed, which is why it produces bad answers in both directions. “Programmer” is not one job. It is a bundle of quite different activities that happen to be done by the same person, and they are not equally exposed.
Split the bundle and the answer stops being a guess.
Splitting the bundle
the job, by exposure │ ├── spec ──► syntax .................. heavily automated ├── boilerplate and scaffolding ...... heavily automated ├── standard implementations ......... heavily automated │ ├── debugging ........................ partly ├── code review ...................... partly, with a human liable │ ├── deciding what to build ........... barely ├── knowing a requirement is wrong ... barely ├── owning production ................ barely └── undocumented context ............. barely
If most of your hours sit in the top block, your hours are genuinely under pressure. That is not a comfortable thing to say and it is true.
If most of your value sits in the bottom block, demand for it has increased, because there is now more code being produced and therefore more to decide about, judge, and maintain.
Why the bottom block holds
Requirements are not specifications. The hard part of software has never been the typing. It is that the person asking does not know what they want, cannot describe the process they perform daily, and will recognise the right answer only when shown the wrong one. Automating the typing does not touch this.
Context lives in people, not repositories. Why the invoicing job runs at 02:00. Why that table is never joined directly. Which client will escalate to the CEO. None of it is written down, and a model cannot read what does not exist.
Somebody has to be accountable. When a deployment corrupts production data, a company needs a person who understands what happened and can fix it. Responsibility does not distribute to a tool.
Maintenance dominates. Most software work is changing existing systems without breaking the parts that already work. That is exactly where generated code is weakest, because the constraints are implicit and historical.
┌─ WORTH CHECKING ─────────────────────────────────────────────────────┐ │ │ │ Private, finished, owned by you, and doing nothing. │ │ │ │ [ See what your repos are worth ] │ │ │ └──────────────────────────────────────────────────────────────────────┘
What genuinely changed
Compression. A developer who could carry one system can now carry three. That is a real productivity shift and it has real consequences, the most obvious being that some teams need fewer people to do the same work.
Whether that reduces total employment depends on whether the world wants more software than it currently has. Historically every fall in the cost of producing software has been met with a rise in how much gets built, because the backlog of things worth automating has never been close to exhausted. That pattern might break. Nobody credible knows, and anyone claiming certainty in either direction is performing.
The honest position is that the distribution of who does well has shifted towards judgement and away from throughput, and that the bottom rung of the ladder has been removed while the ladder stayed the same height. That second problem is real and the industry has not solved it.
The part with a direct bearing on you
There is a detail in this story that most developers have not registered.
The reason models are good at code is that they were trained on code. They need more of it, and specifically the kind that was never published: real production systems with real commit history, because the public supply is both exhausted and unrepresentative, and synthetic code is a poor substitute.
Which means the archive of work behind you has changed status. It used to be finished. Now it is an input that labs will pay to license, non-exclusively, with you keeping everything.
That is a strange symmetry and worth sitting with. The thing compressing the writing half of your job is also the thing that turned your back catalogue into an asset.
What to actually do
Get closer to decisions. The developer in the room when scope is set is much harder to replace than the developer handed a ticket.
Learn to review well. Judging whether generated code is right, for this system, with these constraints, is the skill the next decade rewards.
Own something in production. Accountability is the least automatable thing you can hold.
And stop deleting your old repositories.
What to read next
- Is software engineering dead, the same question from the other end
- What AI labs pay for code, the figures behind the symmetry
- Archiving a GitHub repository, the five minute version of the advice above
Common questions
- Will junior developers still be hired?
- Yes, but the route in has changed. The small, well-specified tasks juniors were traditionally given are the ones models handle best, so the way in now runs through demonstrating judgement early rather than accumulating volume.
- Should I still learn to program?
- Yes. Reading, reviewing, and judging code is now the higher-value half of the skill, and none of it is possible without being able to write code yourself.
- Which specialisations are most exposed?
- Work that is mostly translation from a clear spec into standard syntax, in a popular stack, with no ownership of the outcome. Work involving unclear requirements, unusual systems, or production responsibility is much less exposed.
- Are models actually good enough to replace a developer?
- They are very good at producing plausible code and much weaker at knowing whether it is the right code for a system whose context is not written down anywhere. That gap is where the job now lives.
- Why do AI labs want to license real code if models are so capable?
- Because capability came from real code and needs more of it. Synthetic code trains poorly, and the public supply is exhausted and unrepresentative. Private production code with real history is the scarce input.