Software Engineering is dead (again) - by Jeff - JoT

JoT

SubscribeSign in

Software Engineering is dead (again)<br>For real this time. It’s died N times already.

Jeff<br>Aug 03, 2026

Share

Do you remember the pre-AI world? I’d have an idea, find an algorithm that solved it, spend a few evenings coding it, and then realise my idea was in fact stupid.<br>As AI grew more capable, the time to implement my ideas collapsed to near zero. The fun went with it, so I stopped.<br>But I lost so much! The struggle in those few evenings was the learning. Mapping a problem to a new domain forced me to understand the idea properly. Often it was the mapping itself that revealed why the idea was stupid.<br>Once you notice the joy was in the making, it’s easy to buy into the rest of the AI-hype too. Software factories. Mass redundancies. It’s easy to become a doom-monger and believe that software engineering is dead.<br>In this post, I’ll try and make the counter argument (mostly to cheer myself up). Software engineering has been declared dead before, but it’s kept going and it’ll be with us a while yet.

Software Engineering is dead again<br>The computer

Roy Amara’s famous observation:<br>We tend to overestimate the effect of a technology in the short run and underestimate the effect in the long run

A decade later, economist Robert Solow made the same observation<br>You can see the computer age everywhere except in the productivity statistics.

Computers were supposed to transform the economy. Eventually they did, but “eventually” turned out to mean decades, not quarters. The productivity gains only showed up when organisations redesigned themselves around the technology, and organisational redesign is slow because changing human behaviour is slow.<br>We haven’t begun that redesign for AI yet. Most companies are chucking agents into processes designed for humans and finding out the hard way that it doesn’t really work. AI transformation is real, but if history is a guide, then the timescale is measured in years, not sprints.<br>Thanks for reading JoT! Subscribe for free to receive new posts and support my work.

Subscribe

English as a programming language

COBOL’s pitch was that it read like English so that managers would write the program themselves. No more pesky programmers.<br>Then came the 4GLs and CASE tools of the eighties and nineties. The promise was the same: business users describe exactly what they want, and the computer generates the code.<br>Sixty plus years of trying to eliminate the programmer by making programming look like English and yet the number of programmers has grown dramatically. Why?<br>The hard part has never been writing the code. I wrote recently about asking a colleague to put a case study on the web. A one-line request, perfectly clear in my head, and I got back my own email published as a downloadable EML file. If I can’t unambiguously transmit “put this on the web” to a fellow human, what hope does “build me a CRM” have as a prompt?<br>Requirements come from humans, and humans aren’t good at saying what they mean. Someone still has to wrangle the ambiguity, ask awkward questions and find the edge case. That’s the software engineers!<br>Cheap code

LLMs undoubtedly make writing code cheaper. Western developer salaries have dwarfed offshore rates since the nineties. If cranking out more code was the hard bit, then arbitrage would have hollowed out the profession years ago.<br>That hasn’t happened, and Ronald Coase (The Nature of the Firm) explained why. Companies exist because transacting across a boundary is expensive. You can’t write a contract for software without solving the problem yourself, and once you add the back-and-forth over edge cases and judgement calls, the total transaction cost often exceeds the salary you were trying to save.<br>The specification problem doesn’t disappear when the contractor (AI or outsourcer) is cheaper, it just becomes more of the job.<br>The silver bullet

Fred Brooks split software difficulty into two parts in his No Silver Bullet essay. Accidental complexity is the fiddly stuff: boilerplate, memory management, build systems. Essential complexity is the irreducible difficulty of the problem itself. His 1986 prediction was that no single technology would give a tenfold improvement, because tools only attack accidental complexity.<br>AI is the biggest attack on accidental complexity ever mounted, and we should be grateful for it. It is also the strongest test of Brooks’s claim ever run. As far as I can tell, essential complexity is still just as hard and still requires human judgement.<br>And now the AI arrives.

Now LLMs are writing the code, so who needs engineers?<br>Well, writing code was always easy. Knowing its right is the hard bit. My favourite illustration of this is a Google Research post from 2006.<br>A binary search written by Joshua Bloch, with countless eyes on it shipped to millions of developers and sat there for nine years with a bug triggered by a single line (low + high / 2).<br>Verifying that code...