AI will replace the code's
Every few years a technology arrives that is declared the end of programming. This time the claim has more weight behind it — but the conclusion is still wrong.
Thu 22 February 2024

Every few years a technology arrives that is declared the end of programming. Compilers were going to do it. Then visual programming. Then low-code platforms. Each time, the number of working developers went up rather than down. AI is a genuinely larger shift than any of those, but the conclusion people draw from it is still the wrong one.
What actually changed
Large language models are extraordinarily good at producing plausible code. Give one a well-scoped function signature and a description, and it will write something that compiles and usually works. That capability is real and it has changed the texture of daily engineering work.
What it has not changed is the hard part. Writing the code was rarely the bottleneck. Deciding what to build, understanding why the previous approach failed, and holding the whole system in your head well enough to know which change is safe — that is the work, and it is still yours.
Where it genuinely helps
The gains are real, but they cluster in specific places:
- Boilerplate and glue code, where the shape is obvious and the work is tedious
- Unfamiliar APIs, where the model has read more documentation than you have
- First drafts of tests, which are easier to review than to write from nothing
- Translation work — one language to another, one framework to another
Where it does not
Ask a model to work inside a large codebase with a decade of accumulated decisions and it starts to struggle. Not because it cannot write the code, but because it does not know which of the fifteen plausible approaches your team already tried and abandoned. That context lives in people, in code review history, in post-mortems — not in the training data.
There is also the matter of accountability. When a system fails at three in the morning, someone has to understand it well enough to fix it. Generated code you never really read is a liability that comes due at the worst possible moment.
What this means for your team
The teams getting the most out of these tools are not the ones generating the most code. They are the ones who have gotten faster at the mechanical parts and reinvested that time into design, review, and testing. The output is not more code — it is better-considered code, arrived at sooner.
The job is changing, as it always has. It is not disappearing.


