Software Engineering Isn't Changing. It's Over.

Dario Amodei says software engineering is going away. Other people running AI labs say engineering hiring is going up, not down. They are looking at the same industry, at the same moment, and they are both right. That sounds impossible until you notice they are not talking about the same job.

That gap, between the job that is disappearing and the job that is growing, is the whole story. So let me try to close it.

Here is the frame I keep coming back to. The first programmers wrote machine code and punched cards. If you had told one of them that software jobs would explode over the next sixty years, you would have been right by a margin they could not have imagined. You would also have been describing a job that none of them held. Each wave of abstraction, assembly then C then Python then frameworks, kept the demand for programmers climbing while quietly retiring the specific thing a programmer did all day. The title survived. The work underneath it got swapped out, over and over, and most people only noticed in hindsight.

What I want to argue is that this is happening again, except faster than it ever has, and this time it cuts deeper than any previous layer. Not just the typing. The thinking too.

It is already over at the frontier

When people hear "software engineering is going away," they picture a future date. It is not a future date. At the companies that adopt these tools first, it has already happened, and you can watch the shape of it in how Anthropic talks about its own work.

Notice first how the claim itself has moved. The earlier version of the argument was tidy: coding goes away, but software engineering, the real work of designing systems, stays. Dario has stopped drawing that line. He now says coding goes first, the models are already doing that, and the broader job of software engineering follows, end to end, and that it happens soon if not today. The thing that was supposed to be safe is no longer being described as safe.

You can see why he believes it by looking at how building with these models has changed in about a year:

Era	What you get	What you still have to do
The API	text in, text out	everything: the loop, the context, the tools, hosting, state
The Agent SDK	the loop and context management, handled	hosting, session state, observability
Managed agents	basically all of it	hand it a task and the skills or MCP servers it needs

We started at text in, text out, where you wired up everything yourself. Then the Agent SDK took over the loop and the context management, and you only had to worry about hosting and observability. Now we are in the managed agent era, where the provider does the hosting too and you just hand over a task and whatever tools it should reach for. The agent does the rest.

This is the part worth sitting with. Anthropic has been saying their engineers do not really touch code anymore. When I first read that I assumed they meant some elaborate internal orchestration system, agent loops stitched together inside something like Hermes or a homegrown harness. It is none of that. They orchestrate the task at a high level and run agents in loops, and the agent does not just play the role of the software engineer. It runs the whole pipeline:

product → design → engineering → QA → security → ship

All of it, inside one loop. The brief goes in at the top and the product comes out the bottom, and the human sits above it as a conductor rather than a contributor. What used to be five or six teams becomes one person pointing a fleet of agents at a goal. Some kind of super product manager who owns the entire stack that used to be spread across engineering, design, QA, and the rest. That is what the role is starting to look like, and it is barely recognizable as the thing we have been calling software engineering.

So when Dario says software engineering is going away, "soon if not today," I would go a step further. At the frontier it is already gone in the sense that matters. The person who took a brief from the product manager and the design team and turned it into code, that role is the one being absorbed first. That is the part Dario is pointing at.

Why both things can be true at once

If the job is being absorbed, how is hiring going up? The answer is leverage, and it is the bridge between the two camps.

There is a point about comparative advantage that is surprisingly powerful here. Even if a human is only doing five percent of the task, that five percent gets amplified, because the AI does the other ninety-five. You become something like twenty times more productive, not because you do more, but because the slice you still own is levered against everything the machine does around it. The catch is built into the same math. As the models get better, your slice shrinks, ninety-five becomes ninety-nine, then ninety-nine point nine, and the human contribution keeps thinning out even as the output per person explodes.

That is how you get more engineers than ever and a dissolving job in the same breath. The economy can absorb a lot of people each doing a thin, highly levered sliver of work that looks nothing like writing code. "Hiring is up" and "the job is over" are not contradictions. They are two readings of the same curve, one counting heads and the other watching what those heads actually do.

This is not the jobs apocalypse

Before anyone spirals, I want to make the optimistic case honestly, because I think it is mostly right.

There are two ways people talk about where this goes. The doomsday version is simple: AI does the work, people lose their jobs, wealth pools into a tiny number of hands, everyone else gets left behind. The other version, which Marc Andreessen laid out well a while back, says the opposite happens, and it is grounded in actual economic theory rather than vibes.

The mistake the doomers keep making is what economists call the lump of labor fallacy, the assumption that there is a fixed amount of work in the world and that if machines do it, there is none left for people. That intuition feels right and is wrong. When you apply technology to production, you get more output for less input. From there it can break two ways. Either prices fall, because the thing is cheaper to make and companies pass that on to reach more customers, or companies hold prices and pocket the difference as profit. For the purpose of the argument both roads lead to a similar place on jobs. In the first, people keep more of their money, which becomes spending power, which becomes new demand. In the second, that capital sits with companies who reinvest it into building more things to sell. Usually you get both at once, capital in people's pockets and capital in the companies', and the cycle feeds itself: more demand, new products, new industries, new jobs for the people the machines displaced.

Wages tend to rise too, and this part gets skipped. Compensation tracks the marginal productivity of a worker, and a worker paired with better technology is more productive, so either their employer pays them more or a competitor will, purely out of self interest. Historically, technology dropped into an industry has tended to raise both the number of jobs and the wages in it.

Push it all the way to the limit, AI replacing essentially all current labor, and you do not get a frozen economy. You get a productivity takeoff with no historical precedent, prices collapsing toward zero, demand exploding, and entrepreneurs racing to build new things to soak up all that new spending power. Then the cycle repeats. The engine underneath it is that human want is basically infinite. Give people more capital and they find new things to want, and companies find new things to sell them.

I think this is true. We have lived through this exact panic before, the outsourcing scare of the 2000s and the automation scare of the 2010s, with talking heads insisting each time that this time is different. By late 2019 the world had more jobs at higher wages than ever in history. So no, I do not think AI ends work. If anything it could drive the largest and most sustained economic boom we have ever seen.

But software engineering is a moving target

Here is where I think the optimistic case gets waved through too quickly.

"We are hiring more engineers than ever" can be perfectly true while telling you almost nothing, because the word "engineer" is doing a lot of quiet work in that sentence. More engineers doing what? At Anthropic the answer is: managing agents, not writing code. Is that what you would have called software engineering even six months ago? Is it what schools and universities are teaching right now?

Tom from YC put it cleanly. The software engineering jobs of today will not exist in five or ten years. There will be strong demand for smart people who know how to wrangle these AI coding machines, and if we want to keep calling those people software engineers, so be it, but the job is dramatically different. Boris, who created Claude Code, said something similar earlier this year: the software engineering title itself starts to go away in 2026. The demand is real and it is going up. It is just not demand for what was in demand one or two years ago, and the target is moving fast.

The comfortable response to all this is "it is just another layer of abstraction, like assembly to C to Python, calm down." I do not buy it, and the reason matters. Every previous abstraction made writing the syntax easier while leaving the actual job intact. You still designed the logic. You still engineered the system. What got more accessible was the typing, not the thinking. This time is the break in that pattern. You are no longer engineering the logic. You describe what you want and the model builds the system. The skill that survived every prior abstraction, owning the design of the thing, is exactly the one now on the table.

And notice that even within the old story, standing still was never safe. The programmer punching cards who refused to learn the next layer was out of a job long before the layer after that arrived. Upskilling was always the price of staying in the field. The only thing that has changed is the clock. The next layer used to take a decade. Now it shows up in months.

The comfortable take, and why I don't buy it

There is a widely shared post from a tech CEO making the rounds, roughly titled around software engineers freaking out, and the message is: relax, the people telling you to worry are wrong, including the companies selling you the tools. I get the appeal, and I think it is too comfortable.

The load-bearing arguments are always the same handful, and they sound reasonable one at a time. You still have to tell the machine what to build. You still have to understand what it is doing well enough to check its work. The tools still make mistakes, so you still need an experienced engineer to fix them. And the reassuring one, the job just shifts from typing to thinking, which is the part we liked anyway.

Take them in order. "You still tell it what to build" is true and is also the smallest part of the job, and it is not software engineering, it is product and taste. "You still have to check its work" assumes the gap between its output and correct stays wide enough to need an expert in the loop, and Dario's entire point is that this gap closes fast. We are heading toward models good enough that people just accept you can prompt things into existence and they work out of the box. "It still makes mistakes" is true today and is a snapshot, not a trend. Anthropic already barely needs that safety net in how they operate. And "typing to thinking, you become an architect" is the most seductive one, because it lets you keep your identity, but it is incomplete. The job did not just move from typing to thinking. We now have thinking machines, and soon you will not need to think about the systems either. The model does that part too.

I am not saying understanding software engineering is worthless right now. I can ship better work with these tools precisely because I understand what is underneath them. I just think that edge is shrinking quickly, and betting a career on it shrinking slowly is a bad bet.

The part that actually worries me

So if the economics work out and the doom is overblown, what is left to worry about? Speed.

Marc Andreessen flags this himself, and it is the piece that gets dropped from the optimistic summary. The industrial revolution and every transition like it played out over decades, sometimes centuries. The mechanical loom, outsourcing, automation, all of it gave people time to retrain, to move, to absorb the change across a generation. AI changes every day. The long run is fine. The long run was never the problem. The problem is the in-between, and if the transition happens faster than people can process it and reskill into it, that stretch can get genuinely ugly even on the way to a better destination.

This is the bit I wish more of the optimists would say out loud. The end state being good is not a guarantee that the road there is gentle, and the speed is exactly what makes this wave different from the looms and the calculators. We should be honest about that instead of hand-waving it with a chart that only shows the destination.

What the models still can't do

It is not all dissolving, though, and the parts that hold up tell you where to stand.

Models are great at anything you can score. If you can reduce a task to correct equals one and wrong equals zero and feed that signal back in, the model will climb it relentlessly. The trouble is everything you cannot score that way. A model struggles to optimize for taste unless you hand it examples to copy, which is precisely why so much AI design looks the same. It is averaging the references it was given instead of having a point of view. Taste lives in that gap, and I have not seen the models close it yet.

Knowing what to build sits in the same gap. That inherently human read on what other people actually want is not something AI has taken over, and I am genuinely not sure it will. And it matters more now, not less, because building is no longer the bottleneck. There are more vibe-coded apps out there than ever. Most of them are bad, but the build quality gap is closing, which means shipping something that runs is about to be worth almost nothing on its own. Building a product is not the same as selling it, and it is not even the same as knowing whether a single person wants it. YC's oldest line, make something people want, suddenly carries the whole weight. Distribution carries the rest. Those two, understanding humans and getting the thing in front of them, are the areas I expect to absorb what used to be the software engineer.

So what do you actually do

A year ago Andrew Ng was saying that telling people not to learn to code is some of the worst career advice you can give, because everyone is about to code, so coding skills would only get more valuable. A year of evidence has flipped that for me. You do not need to learn to code, because everyone is prompting in plain English and the models are getting good enough to abstract the rest away. What you need to learn is how to manage agents, because thinking about the code is becoming optional and interacting with agents is getting easier and more accessible by the month.

Beyond that, the most useful thing I can tell you is to live at the bleeding edge. Watch what Anthropic and the best software companies are actually doing right now, today, and make sure you understand it. If you do, you can see the next step before it becomes common, and the people who see the next step early are the ones who get picked up immediately when it arrives. The skill is not any particular tool. It is staying current with a target that refuses to sit still.

It is also worth noting where Dario points people when he is asked what to learn. Ride AI as a tailwind, yes, but in something with a physical-world element. Semiconductors, hardware, traditional engineering. Notably not software, and he is explicit about that, because software is trending toward one person conducting a fleet of agents that does the rest. When the person telling you software engineering is over is also telling you to go learn hardware, it is worth listening to both halves of the sentence.

The verdict

The software engineer is becoming a conductor of agents, someone who no longer concerns themselves with the intricacies of building the system, and increasingly not even with thinking it through. Taste, knowing what people want, and distribution are the adjacent ground that absorbs what used to be the job. That is where I would put my time.

I will not pretend I know the exact shape of what comes next, because I do not think anyone does. It moves too fast for that. What I am confident about is the negative space. It is not writing code, that has been obvious for a while. And it is increasingly not thinking about the systems either, which is the part still sinking in for most people. Traditional software engineering is over the same way punch cards were over, and the worst move you can make is to spend the next two years defending the old definition. Stop defending it. Watch the frontier instead, because the definition is going to keep moving, and it is going to move fast.