The “AI Will Replace Programmers” Claim, Unbundled

This claim generates more heat than any other in the field, partly because it is personal and partly because the sentence contains three different assertions that are almost never separated. They require different evidence, and the evidence currently points in different directions for each.

Three claims in one sentence

• Capability — a model can produce the artefacts a programmer produces, at acceptable quality, for some share of the work.
• Employment — as a result, fewer people will be paid to do this job.
• Timeline — this happens within a stated period.

These are logically independent. Capability can rise sharply while employment rises too, if demand for software rises faster — the standard pattern when a complement gets cheaper. Employment can fall without capability being the cause, since hiring responds to interest rates and revenue as much as to tools. And every capability claim ever made about this field has been more accurate about direction than about date.

The capability claim

The strong version — models produce a large share of routine code at a quality that survives review — is the one with the most support, and the position that dismisses it has already lost ground. Anyone asserting that models cannot write useful code is making a claim contradicted by the daily experience of a large number of working engineers, and the honest sceptical position moved on from there years ago.

Where it needs qualification is the shape of the competence, and the shape is specific. Code generation is strongest where the task is well specified, self-contained and similar to a great deal of public code; weakest where the difficulty is in figuring out what to build, in understanding a large existing system with undocumented constraints, or in the parts that fail only in production. That is not a small caveat, because in most established codebases the second category is where the time goes.

Two measurement traps make this claim hard to assess from announcements. Coding benchmarks are drawn heavily from public repositories, so contamination is a live concern for any score on a test set old enough to have been crawled. And the standard benchmarks measure function-level synthesis against unit tests, which is a real skill and not the same skill as changing one behaviour in a system of two million lines without breaking three others. Why benchmark scores do not transfer applies here with unusual force.

The employment claim

This is the claim people care about and it is the one with the least direct evidence, for a mundane reason: the data that would settle it arrives late, is aggregated across job titles that mix very different work, and is confounded by the largest interest-rate move in a generation happening simultaneously. Any attribution of a hiring change to AI over that period is an inference, not a measurement, and it should be labelled as one. What employment data can and cannot show goes through the specific problems.

Two mechanisms push in opposite directions and both are real. Cheaper production of software raises the amount of software worth building, which raises demand for whoever specifies, integrates and maintains it. Cheaper production also lowers the number of people needed per unit of output. Which dominates is an empirical question about the elasticity of demand for software, and it has a different answer for a firm whose backlog is longer than its capacity than for one whose product is finished.

The distributional point is separate and less contested. If the strongest gains are on well-specified self-contained tasks, that describes the work junior engineers are usually given, which means the effect on the entry rung can be quite different from the effect on the profession in aggregate — and a profession that stops training juniors has a supply problem later. That argument does not depend on any forecast about totals.

The timeline claim

Timelines are where this discussion has the worst track record in both directions, and it is worth being precise about the failure mode rather than just noting that predictions were wrong.

The recurring error is extrapolating from a demo to a deployment without accounting for the parts that are not the demo. A capability shown in a controlled setting has to clear code review, security review, regulatory constraints in some sectors, integration with systems that have no API, and the accumulated habits of people who have to change how they work. Those add years, reliably, and they are invisible in the announcement. The same gap is why an impressive demo is weak evidence about a product.

The opposite error is assuming that because the last three timelines were too aggressive, the next one is too. That is not an argument about the technology; it is an argument about the people making forecasts, and it fails whenever the underlying trend continues.

Reading the next headline about this

When the next version of this claim appears, split it into the three parts and ask what each is resting on. A capability claim should point at an artefact you can inspect. An employment claim should point at data with its confounders stated. A timeline claim should say what would have to be true for it to hold, and what the author would accept as having falsified it. A claim that supplies none of the three is a mood, and moods have been wrong in both directions here.

The version of this claim most likely to be true is also the least quotable: that the composition of the work changes faster than the headcount does. More time specifying, reviewing and integrating; less time typing the obvious implementation. That has happened repeatedly in this profession — compilers, garbage collection, package ecosystems, managed infrastructure each removed a category of work that people had been paid to do — and on none of those occasions did the number of programmers fall. It is not a law that it cannot happen this time, and it is a reason to want the employment claim argued from data rather than from how large the capability feels.