Against the death-of-programming genre

You know the article. It opens with a demo, moves to a paragraph about how many lines the author produced in an afternoon, arrives at the phrase “the end of programming as we know it”, and closes with career advice for people who have not started yet. Some version of it has been published every fortnight for two years.

I am not going to argue that nothing has changed, because a great deal has. My position is narrower and, I think, more useful to anyone running a team: the genre measures the profession by code production, which was never where the difficulty lived, and it is now being used as evidence in headcount decisions by leaders who have never checked it against the delivery data sitting in their own systems.

The category error, stated plainly

The genre’s implicit model is that a developer’s job is to convert an agreed intention into working code, and that the value is in the conversion. Automate the conversion and the job disappears.

Anyone who has run delivery knows the conversion was rarely the expensive part. The expensive part is upstream and downstream of it: working out what should be true of the system, discovering that two teams assumed different things, finding the constraint nobody wrote down, deciding what happens in the case that was not specified, and being accountable when it goes wrong at two in the morning.

Test the model against your own history. Think of the last four projects that ran late. Count how many were late because the code took too long to type.

I have run this exercise with a lot of leaders and the answer is almost never more than one.

What the genre measures

• Lines produced per hour
• Time from prompt to running demo
• Whether a model can pass an interview question
• Whether a greenfield app can be built in a weekend

What made your last project late

• Requirements that were agreed but not the same in two heads
• A dependency on a team with different priorities
• A constraint discovered in week six
• Review and environment capacity
• Someone had to decide, and could not

The evidence the genre points at is real, and it points somewhere else

Here is where I have to be fair, because the genre is not built on nothing.

Entry-level developer postings are down roughly 40 percent. Something in the region of 41 percent of production code was AI-generated by early 2026. Those are serious numbers and anyone dismissing the whole conversation has to account for them.

But look at what the same data set does when you cut it differently. The drop in junior hiring was not uniform: some large enterprises increased junior hiring in the same period that startups cut it. Automation does not check your funding stage. If this were a mechanical consequence of capability, it would land the same way everywhere, and it did not. It looks much more like a cost decision made under uncertainty, with different organisations reaching different conclusions from the same technology.

Then look at what happened to flow. LinearB’s 2026 benchmarks put pickup time on agentic pull requests at 5.3 times longer, and median review duration up 441.5 percent. Production went up. The system’s ability to absorb what was produced did not. That is not a profession dying. That is a bottleneck moving to a stage of the process that is still done by people, and getting worse there.

What the genre costs you operationally

I care about this less as a debate and more as a delivery problem, because the genre has operational consequences and they are all bad.

It discourages entry into a role you will be short of. Hiring pipelines have a lag of years. Every graduate who reads that the profession is closing and goes elsewhere is someone you cannot hire in 2029, when the bottleneck has moved again.

It licenses headcount decisions with no local evidence. “The industry is shrinking engineering” is a much easier thing to say in a budget meeting than “our review queue is the constraint and I want to fund it”. The first sentence is a narrative. The second is a claim you could check by Friday.

And it puts the transition conversation on the wrong footing with your own team. If the framing is that the work is disappearing, every process change you propose reads as a step towards redundancy, and you will get quiet, well-mannered resistance to all of it. If the framing is that the constraint has moved and the valuable work is now upstream, the same changes read as an investment in the people you are asking to make them.

The claim"Agents write most of the code, so we need fewer engineers."

The checkWhere does work actually wait in your system? Measure time in review, time waiting for a decision, time waiting for an environment.

The usual findingMerge volume is up. Time in the queue before a human looks is up more. Nothing is waiting on code being written.

The decision it impliesFund the constraint. Cutting upstream capacity when the downstream is saturated makes the number worse, not better.

Where this breaks down

The strongest counter is that “the job changed, it did not disappear” is what every displaced profession said. Typesetters said it. Draughtsmen said it. In both cases the residual role was real, considerably smaller, and paid less. Pointing at the parts of the job that are still human is not proof that the number of humans stays the same, and I should not pretend it is. My argument is about what the work is, not about how many people it needs, and those are different claims.

Down 40 percent is a fact regardless of who caused it. A graduate cannot eat my argument that the decision was a choice made with a bad cost model. If they cannot get an interview, the genre described their world accurately and my objection is academic to them. That deserves saying plainly rather than being tidied away as a data-interpretation point.

Some of the genre’s authors are describing their own experience honestly. A solo founder who used to need three contractors and now needs none is not writing propaganda. They are reporting something true about their situation. The error is generalising from a context with one decision-maker, no compliance surface and no legacy to an enterprise with fourteen teams and a release calendar, but the underlying observation is not fabricated.

Trust data cuts both ways. Developer trust in AI output fell from around 40 percent to 29 percent in the Stack Overflow 2025 survey. I read that as evidence that verification is now the work. Someone else can read it as a transitional complaint that improves with the next model generation, and then my “the constraint is downstream” argument has a shelf life measured in model releases.

And I have a commercial interest. We sell tooling for the verification layer, so an argument that concludes “the valuable work moved to verification” is convenient for us. Discount accordingly, and check the claim against your own queue rather than against my incentives.

The takeaway

The death-of-programming genre gets the direction right and the object wrong. Code production has genuinely stopped being scarce. It was also never the constraint, and your own delivery data will say so more credibly than any essay.

The real risk is not that the genre is too gloomy. It is that it offers a ready-made justification for cutting the part of your organisation that is upstream of your actual bottleneck, at exactly the moment that bottleneck is getting worse.

If you take one thing into next week: before you use any industry narrative in a headcount conversation, pull the median time your changes spend waiting for a human decision, this quarter versus a year ago. If that number went up, you have your own evidence, and it points the other way.