Software Engineering is dead (again)

For real this time. It’s died N times already.

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.

As AI grew more capable, the time to implement my ideas collapsed to near zero. The fun went with it, so I stopped.

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.

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.

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

The computer

Roy Amara’s famous observation:

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

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.

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.

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.

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.

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?

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?

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!

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.

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.

The specification problem doesn’t disappear when the contractor (AI or outsourcer) is cheaper, it just becomes more of the job.

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.

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.

And now the AI arrives.

Now LLMs are writing the code, so who needs engineers?

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.

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).

Verifying that code is correct is hard. Nothing about generating code faster closes that gap. If anything, it makes it worse. More code, produced quicker, reviewed by people who didn’t write it (and increasingly didn’t write code at all!). The conclusion of the Google post was that it’s hard to write even the smallest bit of code correctly. We’re still going to need engineers to help close the verification gap.

The wake

What do each of these job-killing examples have in common? They all make the assumption that the activity is the job. Typing is visible, syntax is visible and (of course) salaries are visible. The invisible parts (extracting intent from ambiguous humans, making judgement calls about edge cases, verifying that plausible code is correct) were never the things being automated. They were the bits left over and still are.

Which takes me back to where I started, feeling miserable about my dead hobby projects. I’d concluded the fun had gone because the making was gone. But the making was really just me fighting accidental complexity. The learning was actually me falsifying my idea, which is exactly the thing AI won’t do.

AI is going to change how we build software, but it’s going to take longer than folks believe, and us software engineers have plenty of time to adapt.