Every Software Engineer Is About to Lose Their Job. Again.

I’ve been in this field for over twenty years, and in that time I’ve watched a lot of technologies show up promising to revolutionize the industry. Some of them actually did. Most didn’t. Each time, people proclaim that every software engineer is about to lose their job. So even though I’ve been using chat-based AI for a while now, I was slow to touch the newer agentic coding tools. Call it stubbornness, call it healthy skepticism, call it whatever you want — I just wasn’t in a hurry.

Eventually I gave in and tried Claude Code on something low-stakes, just to see what the fuss was about. I built a small app to sync a couple of folders between Google Drive and OneDrive, so my personal and work accounts would stay in step without me babysitting them by hand. It took a couple of hours. Not a couple of days, not a sprint, a couple of hours, and at the end of it I had something that actually worked. I felt productive in a way I hadn’t expected, and it cracked the door open for me in a way years of chatbot small talk never had.

Introduction

That feeling is exactly why the current conversation about AI and software jobs deserves to be taken seriously. It’s also exactly why I think a lot of people are drawing the wrong conclusion from it.

Every software engineer is about to lose their job. Again. This time it’s AI. Large language models can write code. AI agents can work through entire tasks, fix bugs, write tests, review pull requests, and increasingly operate without someone carefully guiding every step along the way. Depending on who you listen to, the conclusion seems obvious: software engineering as a profession is on borrowed time.

Maybe. But the funny thing is, we’ve been here before. Many times. Software development has a long history of technologies promising to make programming so easy that ordinary people can do it themselves. Sometimes the claim is that programmers will disappear entirely. Other times we’ll just need dramatically fewer of them. The terminology changes, but the underlying promise stays remarkably consistent. Before we declare ourselves obsolete, I think it’s worth looking at what happened the other times we tried.

We’ve been automating programming almost as long as we’ve been programming

It’s easy to forget just how much programming has already been automated. Early programmers entered machine instructions directly. Assembly language gave those instructions names. Compilers let us write higher-level languages and had the computer translate them into machine instructions for us. That was a genuinely radical abstraction.

Imagine being a programmer accustomed to carefully manipulating registers and memory addresses when somebody comes along and says:

Don't worry about all that. Just tell the compiler what you want.

Sound familiar? The compiler was, in a very literal sense, automating part of the programmer’s job. And then we kept going. We built libraries so programmers didn’t have to implement everything themselves. We built operating systems. Garbage collectors. Database engines. Frameworks. Package managers. Cloud platforms. ORMs. APIs. We’ve spent the better part of the history of software engineering finding things programmers do and figuring out how to make them stop doing it. Oddly enough, we still have programmers.

COBOL and the English-language program

COBOL is an interesting early example. One of its goals was a programming language more understandable to people working with business problems — instead of requiring programmers to think primarily in terms of the machine, COBOL programs could look almost comically English-like:

ADD HOURS-WORKED TO TOTAL-HOURS.

Compared with machine code or assembly, this was an enormous step toward describing what should happen instead of precisely instructing the computer how to do it. The idea that programming languages could eventually become accessible enough for non-specialists was already taking shape.

COBOL did, in fact, make business software easier to create. What it didn’t do was eliminate programmers. It helped create an enormous amount of business software — so much, in fact, that decades later organizations are still running systems written in COBOL and looking for people who can maintain them. We made programming easier. Then we wrote more programs. Remember that pattern. We’re going to see it again.

BASIC: everybody really can program

If COBOL made programming more accessible to businesses, BASIC took the idea considerably further. It was built specifically to lower the barrier to entry, and when personal computers arrived, BASIC frequently came with them. For a while, the assumption that a computer owner might also write programs wasn’t particularly strange.

I got my own start tinkering with programming in BASIC. I certainly wasn’t a professional software engineer — I was a kid messing around with a computer, and that was exactly the point. BASIC lowered the barrier enough that people like me could make computers do things without first earning a computer science degree or convincing somebody to give us access to an expensive machine.

So what happened when programming became accessible to ordinary people? We got more programmers.

Fourth-generation languages: just tell the computer what you want

By the 1970s and 1980s another idea was gaining traction: fourth-generation programming languages, usually shortened to 4GL. Traditional programming languages told the computer how to accomplish something. A 4GL let you describe what you wanted instead. Rather than writing all the code necessary to search through data, you could write something like:

SELECT *
FROM Customers
WHERE IsActive = 1;

The database figures out the rest. SQL is probably the most successful example of this philosophy. Think about how much code that one statement replaces — index selection, traversal, filtering, memory management, disk access, concurrency. Somebody still has to solve those problems, but the person querying the database generally doesn’t.

We automated a giant chunk of programming. Naturally, programmers disappeared. Except they didn’t. Instead, nearly every application on Earth eventually wanted a database.

CASE: surely we can generate the software

Computer-Aided Software Engineering — CASE — may be one of the most interesting predecessors to our current AI moment. The idea was compelling: software development was difficult because programmers were working at too low a level, so give developers higher-level tools for describing systems, processes, data, and relationships, and let the computer generate more of the implementation. Instead of writing all that tedious code, you’d design the system and let the tool take care of the rest.

This wasn’t some fringe idea. CASE tools became a serious industry during the 1980s and 1990s, and the promised productivity gains mostly failed to materialize at the level people expected. It turns out that drawing a picture of a complicated system doesn’t make the system less complicated. Who knew? CASE tools didn’t eliminate programmers. Some of their ideas survived and became ordinary parts of development tooling. Others faded away. The programmers kept programming.

UML: boxes and arrows will save us

If you’ve been in the industry long enough, you’ve probably encountered UML. The Unified Modeling Language attempted to provide a standardized way to describe software systems — class diagrams, sequence diagrams, activity diagrams, state diagrams — modeling increasingly large portions of an application. And once we had sufficiently detailed models, an obvious question followed: why write the code at all? If the model describes the software precisely enough, couldn’t we just generate the implementation? This eventually fed into ideas like Model-Driven Architecture.

There’s nothing inherently ridiculous about the idea. We absolutely can generate code from models. The problem is that as the model becomes capable of describing every important detail of the application, something peculiar happens: the model becomes a programming language. Congratulations, we invented programming again.

UML survived — I still find diagrams useful when explaining architecture or working through complicated interactions. What largely didn’t survive was the idea that we’d replace conventional software development by drawing sufficiently elaborate diagrams.

Visual Basic, Delphi, and Rapid Application Development

Then came graphical development environments. Drag a button onto a form, double-click it, write a few lines of code, and congratulations, you have an application. Tools like Visual Basic and Delphi made it possible for one developer to build applications at a speed that would’ve been hard to imagine a generation earlier.

This absolutely eliminated work. Developers no longer needed to manually implement windows, buttons, event loops, drawing routines, and countless other details. A single developer could accomplish what previously might’ve required an entire team. That sounds suspiciously like a recipe for fewer developers. Instead, companies looked around and realized there were suddenly thousands of applications that were now economically feasible to build. So they built them.

Buy the software instead

Another supposed threat came from a slightly different direction: why employ programmers to build business software when you can simply buy it? Accounting software. Human resources. Inventory. Manufacturing. Customer relationship management. Companies like SAP and Oracle could sell businesses complete enterprise platforms. Problem solved, no programmers necessary.

Anyone who’s worked around enterprise software is probably laughing already. We bought configurable software so we wouldn’t have to write custom software. Then we needed people to configure it. And customize it. And migrate data into it. And integrate it with fourteen other systems. And build reports. And automate workflows. And upgrade it. And figure out why changing one field caused accounting in Germany to stop working. Instead of eliminating software engineers, we created entire industries around implementing software that companies purchased specifically so they wouldn’t have to build software. That’s impressive, in its own way.

Frameworks made development trivial

I’ve spent most of my professional career in the .NET ecosystem, and I’ve watched frameworks progressively eliminate enormous amounts of work. Web development is a particularly good example. Building a web application once required manually solving problems that modern frameworks simply handle for us: routing, authentication, serialization, database access, dependency injection, caching, session management.

Then Ruby on Rails came along with its famous demos showing developers creating functional applications in minutes. The message wasn’t necessarily “programmers are obsolete,” but the implication was familiar — look how little work this requires now. And they were right. Building a basic web application became dramatically easier. What followed was not the collapse of web development as a career. We put software on everything instead.

The cloud will take care of operations

Then we started abstracting the computers themselves. Why maintain servers? Rent virtual machines. Why maintain virtual machines? Use containers. Why maintain containers? Use Platform as a Service. Why manage servers at all? Use serverless. Every layer eliminated work someone previously had to do.

Some jobs genuinely changed as a result — the traditional system administrator role isn’t what it once was. But the complexity didn’t vanish. We got DevOps. Then Site Reliability Engineering, then cloud engineers, then platform engineers. Apparently, we’re very good at eliminating jobs and replacing them with jobs that have different titles.

No-code: this time we really mean it

More recently we’ve had low-code and no-code platforms, and this time the promise became explicit: citizen developers could build their own applications. And you know what? They can. Modern no-code tools are genuinely useful. Someone who couldn’t write a traditional application can build forms, workflows, dashboards, integrations, even complete business applications. That’s incredible.

Then the application becomes important. Someone asks whether it can authenticate using the company’s identity provider. Someone needs to integrate it with a system the platform doesn’t support. The dataset grows by a few million records. Security asks where customer information is stored. Legal wants an audit trail. Someone needs it deployed in Europe. The workflow built by Bob from Accounting is now business-critical, and Bob left the company six months ago. And somewhere along the way, we rediscover software engineering.

I had the pleasure of working at a company where the new CIO was deadset on no-code/low-code being the solution. Announced it in the first townhall. I took that as my cue to move on since he clearly had no idea what mess he was stepping into. Our systems had too much custom work necessary that any no/low-code solution would of necessity require hundreds of man-hours to customize around them. At that level of effort, it would save nothing.

Why does this keep happening?

There’s a flawed assumption buried inside many predictions about programmer productivity. Imagine a company needs 100 units of software. Ten developers can each produce ten units:

10 developers × 10 units = 100 units of software

Now somebody invents a tool that makes developers ten times more productive. Easy:

1 developer × 100 units = 100 units of software

Fire the other nine. The math checks out. The problem is the assumption that the company only wants 100 units of software. Historically, that’s not what happens. When software becomes cheaper to produce, we find more reasons to produce software. A restaurant today might have a website, mobile ordering, point-of-sale software, scheduling software, inventory management, payroll, loyalty programs, analytics, delivery integrations, accounting integrations, email marketing, and reservation systems. Nobody running a sandwich shop in 1985 was complaining about the lack of a customer loyalty mobile app — the economics didn’t make sense. Then software became cheaper. And cheaper. And cheaper. Each time it did, another category of software became worth building.

Economists have a name for this pattern, and it didn’t originate in software at all. In 1865, William Stanley Jevons noticed that making steam engines more fuel-efficient didn’t reduce Britain’s coal consumption, it exploded it, because cheaper power meant industrialists could justify using it everywhere they previously couldn’t afford to. We’ve apparently been running the software version of Jevons paradox for seventy years without bothering to name it.

Enter AI

Which brings us to our current existential crisis. AI can write code. Not toy code, useful code. It can write tests, debug problems, explain unfamiliar codebases, generate documentation, perform code reviews, build user interfaces, write database queries, create deployment configurations. The tools are getting better at an uncomfortable rate.

If your reaction is to dismiss all of this because you’ve seen technology hype before, I think you’re making a mistake. AI is useful. I use it. You probably should too — my two-hour sync-app experiment made that much obvious. But there’s an equally large mistake on the other side: assuming that because AI can produce code, software engineers are therefore unnecessary. Those two things aren’t equivalent.

AI may actually be different

There’s a temptation when looking at this history to conclude that AI is simply the latest CASE tool. I don’t think that’s true. Most previous abstractions automated a particular layer of software development. A compiler automated translation into machine instructions. SQL automated data access. Frameworks automated application plumbing. Cloud platforms automated infrastructure. No-code platforms automated certain categories of application development. AI potentially operates across all of them at once.

We can increasingly give an AI a requirement and have it reason about the task, inspect an existing codebase, implement a change, write tests, run those tests, diagnose failures, and modify its implementation. That’s materially different from dragging a button onto a Windows form. There’s a real possibility that AI changes the economics of software engineering more dramatically than previous abstractions did.

Pretending otherwise because “they said that about COBOL too” isn’t wisdom. It’s complacency.

But what exactly are we replacing?

This is where I think the discussion frequently goes sideways. What is a software engineer? If the answer is:

A person who translates a detailed specification into C#, JavaScript, Python, or Java.

Then yes, I’d be nervous. That particular skill is becoming dramatically cheaper. But I’ve been doing this professionally for more than twenty years, and typing code has never been the hardest part of the job. The difficult parts look more like:

• What are we actually trying to build?
• Does the person asking for it know what they need?
• What requirement did everyone forget?
• How does this fit into the existing architecture?
• What happens when a dependency fails?
• What happens when we have ten million users instead of ten thousand?
• What happens when someone does something we didn’t expect?
• How do we know this is correct?
• How do we deploy it without breaking something else?
• What tradeoff are we making?
• Who owns this thing five years from now?

Most importantly:

Should we build this at all?

AI can help answer those questions too. That’s why I don’t dismiss the threat. But generating an answer and being accountable for the answer are different things.

Accidental complexity versus essential complexity

Fred Brooks wrote about this distinction decades ago in No Silver Bullet. Some complexity in software is accidental — it exists because of the tools and processes we use to build software. Memory management is a good example. For most applications, I don’t want to manually allocate and release memory, and garbage collection removed a category of problems I used to have to care about. Wonderful. Please automate more of that.

But other complexity is essential. The business operates in twelve countries with twelve sets of regulations. Customers can cancel a reservation after making a partial payment using three different payment methods. Two systems disagree about which one owns a piece of data. Nobody knows what should happen when someone cancels the reservation after the flight departs but before the hotel stay begins. No programming language fixes that. No framework fixes that. Drawing more UML diagrams doesn’t fix it. And asking an AI to write the implementation doesn’t eliminate the need to decide what the implementation should actually do. The syntax was never the hardest part.

We keep moving up the ladder

Imagine showing this to a programmer from the 1960s:

users = db.query(User).filter(User.active == True).all()

They might reasonably ask where the programming is. Where are the instructions for accessing the disk? Where’s the memory allocation? Where’s the traversal? Where are the machine instructions? The answer is that someone else solved those problems and put the solution underneath our abstraction.

Now imagine a developer saying:

Get all active users from the database and display them in a sortable table.

AI generates the query, API endpoint, UI, and tests. Today’s developer might look at that and say, “that’s not programming.” Maybe not. But the programmer writing Python wasn’t programming by the standards of 1965 either. We’ve spent decades climbing the abstraction ladder and complaining that the people on the rung above us aren’t doing real programming. AI may simply be the next rung.

Some jobs probably will disappear

I don’t want to sugarcoat this. Every abstraction creates winners and losers. There aren’t many companies hiring assembly programmers to build ordinary business applications anymore. Some categories of system administration have shrunk. Building simple websites isn’t the career it once was. Basic CRUD development is increasingly commoditized. Technologies eliminate tasks, and when enough tasks disappear, roles disappear with them. AI will almost certainly do the same.

If your primary value to an organization is “give me an exact specification and I’ll turn it into code,” I think you’re exposed — AI is becoming exceptionally good at that. But that’s also not where I would’ve recommended an engineer build their career ten years ago either.

Follow the hype

I’m generally skeptical of technology hype. I’ve been around long enough to watch enough “revolutionary” technologies become another tool in the toolbox. But skepticism can become its own form of stupidity. AI-assisted development is useful today. Not theoretically, not someday. Today. I didn’t believe that until I sat down and built something with it myself, and it took a couple of hours to change my mind.

Ignoring it because you don’t like what it might mean for our profession isn’t going to stop it from improving. Learn the tools. Use them. Figure out where they’re good, and more importantly, figure out where they’re bad. Understand what happens when they confidently produce something subtly wrong. Learn how to give them useful context, how to review their work, where they save you time and where they create more work than they eliminate. Follow the hype.

But don’t lose your head

At the same time, we’ve been automating programming almost as long as programming has existed. Every generation has removed work the previous generation considered essential to the craft, and every generation of engineers has moved up another level of abstraction. The result has not historically been less software. It’s been an almost incomprehensible amount more software.

Maybe AI finally breaks that pattern. Maybe one engineer with AI really will accomplish what ten engineers accomplish today, and organizations will decide they only need the one. I can’t tell you that won’t happen. Neither can the person on LinkedIn confidently telling you your career will be gone in eighteen months. What history can tell us is that making software easier to build has repeatedly increased the number of things we consider worth building.

The important question isn’t whether AI will eliminate coding work. It will. The question is whether demand for software has finally reached a ceiling. So far, we’ve spent roughly seventy years discovering that the ceiling was much higher than we thought.

Learn the new tools. Let them automate the boring parts. Keep learning the parts that aren’t so easily automated. And whatever happens next, don’t confuse writing code with engineering software. We’ve been eliminating the former for decades. We’re still figuring out how to do the latter.

Additional Resources

• No Silver Bullet — Essence and Accidents of Software Engineering – Fred Brooks’ original 1986 paper, full text
• No Silver Bullet, summarized – a much shorter walkthrough of Brooks’ argument if you don’t want the whole paper
• Jevons paradox – the economics behind why cheaper production tends to increase total demand instead of shrinking it

Credits

Photo by Verena Yunita Yapi on Unsplash