We've Done This Before 

There's a panic running through software circles right now, and if you've been in the industry long enough, it has a familiar feel. AI agents can write working code, the reasoning goes, so this must be the end of the software engineer.

I've been in the software industry for twenty-five years. I run engineering at Lineate, and these days I build things with AI agents the way I used to build things with teams of engineers. So I'm not writing this as a skeptic who hasn't tried the tools. The tools are real. The speed is real. And the doomsday prediction is still wrong — for the same reason it's been wrong every other time we've lived through this.

Because we have lived through this. At least several times.

1957: The Automatic Coding System

When IBM shipped the first commercially successful high-level programming language, the official title on the manual cover was The FORTRAN Automatic Coding System. The word "automatic" was the whole sales pitch. Scientists and engineers would now write their own programs, and the specialist coder — the person who translated math into machine instructions by hand — would shrink to a small technical niche.

In a narrow sense, it came true. The hand-coders of 1955 did stop exist as a job. What replaced them was a profession several orders of magnitude larger because, once writing software became easier, vastly more people wanted software written.

1981: Application Development Without Programmers

James Martin was one of the most-cited consultants in computing when he published a book whose title needed no subtitle: Application Development Without Programmers. 

It wasn't a provocation, it was a forecast. The preface argued that "the number of programmers available per computer is shrinking so fast that most computers in the future must be put to work at least in part without programmers."

Here's the part I find genuinely interesting: his numbers were right. Computers multiplied far faster than programmers. The fourth-generation languages he championed did real work — report generators and database query tools took a whole class of tasks away from programmers. And demand for programmers grew anyway, because every tool that let an analyst build their own report generated ten new requests for things the tool couldn't do.

The late 80s and 90s: CASE tools

Computer-Aided Software Engineering promised that managers and analysts would draw flowcharts and entity-relationship diagrams, and working code would fall out the other side. This was not a fringe idea. The worldwide CASE market hit $4.8 billion in 1990 and passed $12 billion by 1995. Vendors openly promised tenfold productivity gains, and the US government spent millions buying in.

Then, in 1993, the GAO — the government's own audit office — reviewed the results and concluded that "little evidence yet exists that CASE tools can improve software quality or productivity." The category quietly dissolved. The useful pieces got absorbed into the IDEs we use today, and the programmers it was supposed to replace kept programming.

2010: The death of the sysadmin

When cloud computing arrived, Computerworld ran a piece titled "Cloud and the Death of the Sysadmin." The argument was perfectly reasonable: if the servers live in someone else's data center, who needs the person who racks and patches them?

The same publication now runs cloud-certification job-listing roundups every month. The sysadmin didn't die — the title did. The work moved up a level and got renamed: DevOps, SRE, platform engineering. More people are doing it today, at higher pay, than there ever were sysadmins.

Why does the prediction keep failing

Four predictions, four different decades, four very different stacks — the same outcome every time. That's not a coincidence, and it's not survivor bias. There's a simple economic reason for it.

Software has always been demand-constrained by how much we could build, not by how much was wanted. Every company I've ever worked with keeps an informal list of software they'd love to have and will never get — too expensive, too small, can't justify the team. In twenty-five years, I have never once seen that backlog reduced.

So when a new tool cuts the cost of building, the savings don't show up as fewer engineers. They show up as the backlog flooding in. A regional manager who would never have gotten a custom internal tool now gets one. A nonprofit that could never afford bespoke software now can. A workflow that was "just use the spreadsheet" for a decade finally becomes an app. Economists call the general version of this Jevons’ paradox: make a resource cheaper to use, and total consumption goes up, not down. Engineering hours work the same way. The pie expands faster than the productivity gain, every single time.

I'm watching it happen inside my own company right now. We recently built ourselves a full-time tracking and resource-allocation app — rate cards, audit logging, notifications, multi-role dashboards — in a small fraction of the time and budget it would have cost two years ago. Two years ago, we wouldn't have built it at all. That's the whole story in one anecdote: the cheaper it gets to build, the more things cross the line from "not worth it" to "let's obviously do that."

What's actually different this time

I'll try to be open about the counterargument as I understand it. Every previous tool automated one layer and stopped. FORTRAN automated machine code and then sat there. CASE tools drew diagrams and went no further. AI agents are more general than that — they kind of sort of learn. The new thing isn't that a tool got better; it's that the tool participates in its own improvement.

Fair. But notice that none of the four predictions above failed for technical reasons. They failed for economic ones. The tools mostly worked — FORTRAN worked brilliantly — and the profession grew anyway, because demand for software turned out to be effectively bottomless. For the doomsday version to finally come true this time, that would have to stop being true. Everything I see in front of me says the opposite: the list of things people want built is longer than it has ever been, and most of it still isn't economical. Yet.

There is one honest caveat, though. The profession survived every one of these transitions. Plenty of individual careers didn't. The hand-coders who refused to touch FORTRAN, the sysadmins who wouldn't learn cloud — the technology didn't replace them, they were replaced by colleagues who picked it up. The lesson of history isn't "relax, nothing changes." It's "the work survives, but it won't hold still for you."

The bet

So here's where I land on agentic AI: I believe it is the same bet history points to.

The companies that will struggle are the ones treating this as a cost-cutting exercise — same outputs, smaller team, pocket the difference. They're optimizing for a world where demand is fixed, but demand has never once been fixed.

The companies that will thrive are the ones treating it as a tool that lets them say yes to things they used to have to say no to. The internal tool that never made the cut. The client's request didn't justify the estimate. The experiment that wasn't worth a sprint. All of that just moved into a reasonable budget request. Probably, honestly, within your current quarterly budget limits.

We've done this before. The job changes, the title changes, the abstraction moves up a level — and the profession comes out the other side bigger than it went in. The panic at this point is expected. So is what comes after it.

Blog by Harrison Green-Fishback, CTO of Lineate