Software Engineering Is a Dying Career

I started learning to code when I was in kindergarten. Coding has been part of my life for much longer than it has been my job.

I've worked as a software development engineer (SDE) since 2008. Now, most of my building is delegated to AI agents, both at work and in my spare time. After seeing how quickly my own work has changed, I expect software engineering to become a much smaller profession over the next five years.

The same work with different tools

Around 2021 or 2022, I started feeling that SDE work was becoming similar to industrial work.

New languages and frameworks kept coming out. They were exciting to learn, but in a lot of companies, those choices didn't matter that much. We kept building CRUD code and similar APIs and services.

Those systems could still be difficult to get right. But much of the implementation followed familiar patterns, and I was becoming less convinced that it would always need to be done by people.

I expected the work to be automated eventually. I didn't expect it to happen this fast.

I used GPT-4 and still didn't believe it could do my job

In 2023, I built an app that used GPT-4 to generate text. The app made me a little money, but I rejected the idea that AI could build the whole application.

The text didn't have to be very accurate or creative. It needed to be good enough for the purpose of the app.

My understanding was that AI was guessing the next possible word. That seemed sufficient for generating a blob of text. Coding and designing a service felt like something much more than that. The requirements had to make sense together, and the implementation had to actually work.

Looking back, I think I treated my understanding of how the model worked as a limit on what it could do.

What changed with Opus 4.5

Anthropic released Claude Opus 4.5 on November 24, 2025. It was the turning point for me.

In late 2025 and early 2026, I started giving it small, low-risk tasks. It usually took a few exchanges to get things right. I would inspect the result, explain what was wrong, and ask it to try again.

Through 2026, newer models got better, along with the tooling and agent loops around them. Tasks that had needed several rounds of correction started working on the first attempt. I needed to intervene less, so I handed over larger tasks.

Eventually, I set up cron tasks and groups of agents. I asked one agent to review another's work. I relied on CI/CD to catch problems, then asked agents to fix the failures and continue. With that setup, I don't look too deeply into the generated code anymore.

I still define tasks and constraints, check the behavior, and decide whether the result is acceptable. Automated checks and agent reviews can miss things. There is work left for me.

But I can do much more of it now, with multiple threads running at the same time. That is part of why I expect companies to need fewer engineers for the same amount of work.

It also comes with something I feel deeply: "AI brain fry." I keep switching between threads, trying to remember the context of each task and deciding what needs my attention. The agents can work in parallel, but I still have to follow what they are doing. That constant context switching is painful.

Being able to deliver more doesn't necessarily make the workday easier.

I have never written assembly at work

I learned assembly language at university. I've forgotten it all, and I haven't written a single line of it in my professional career.

The languages and tools I use let me work above that layer. AI increasingly feels like another abstraction: I describe the behavior I want, and the agent handles more of the implementation.

Will the coding I've done throughout my career eventually become something like assembly? Still useful, sometimes necessary, but something fewer people building software need to write themselves?

An agent interpreting a request can misunderstand it in ways a compiler doesn't. I still need to check the result. But I can already build software while spending much less time writing its code.

There is a problem with using this analogy to predict fewer jobs, though. Earlier abstractions made software development accessible to more people. AI could do the same. The question is how much of that additional building will require paid engineers.

What happens to junior engineers?

All the junior SDEs on my team, with roughly one to three years of experience, have expressed concern about their future. They ask agents to do the work, but don't necessarily feel they are learning much. They also worry about being replaced.

I have years of experience to draw on when I decide what to ask an agent, or when its output looks suspicious. Much of that came from writing code myself and figuring out why it didn't work.

How does someone starting now get that experience?

Reading generated code and investigating failures can help. But companies also have to make time for learning, and expectations for development speed are much higher now.

A task that would have been given a month in the past may now come with a deadline of one or two days. The explanation from a manager can be as simple as "Just ask AI to do it."

If the agent gets stuck or produces something wrong, the deadline is still yours. If you cannot deliver, it becomes your failure to use AI effectively. You remain responsible while having less time to understand and check the work.

For someone who already feels they aren't learning enough, that leaves even less room to figure things out.

How many SDEs will companies need?

I expect big companies to act on this early. Engineering payroll is a large cost for companies with big software teams. If they can get the same work done with AI at a lower total cost, there is a financial reason to replace that work wherever they can. That is how I expect capitalism to work here.

AI isn't free. Someone pays for the chips, data centers, and electricity. Supervision and checking the work cost money too. But those costs become the alternative against which companies judge hiring an engineer.

For work that AI can reliably take over, I expect the price companies will pay a human to move closer to the cost of having AI do it. That could mean fewer positions, lower wages, or both.

Existing systems and organizational constraints will slow adoption in some companies. Even so, a company doesn't need a big round of layoffs to reduce its engineering team. It can hire fewer people or stop replacing those who leave.

Cheaper software could create enough demand to support more jobs. My own spare-time building has increased because the work is easier. But some of that demand may be met by people asking agents to build what they need, without hiring engineers.

My bet is that agents' capacity will grow faster than the demand for human engineers.

Coding for fun, not for a living

My wife goes to a pottery workshop once or twice a week, making mugs and bowls by hand. We can buy those things from IKEA for very little money, but it feels different when you make something yourself.

I can imagine coding becoming something people do for the same reason. Understanding a program and writing it yourself can be satisfying, even if asking an agent would have been faster. Professional programmers will remain, but I expect fewer people to make a career out of it.

I'll take this bet: by 2031, software engineering will have become a much harder career to enter, and many of the people considering it today will decide it isn't worth pursuing.

I've spent eighteen years doing this work. I enjoyed learning how things worked, getting stuck, and eventually figuring them out. The junior engineers on my team are only getting started. I wonder how much time they will get to learn before a company decides it needs fewer of them.

I can enjoy what these tools let me build and still feel sad about the career I expect us to lose.

The wheel of time keeps turning, and each of us is just a speck of dust in its path.

I hope I lose this bet.