The Five Stages of Developer Grief

I have talked to a lot of developers over the past two years. Some are excited about AI coding tools. Most are not. A few are outright hostile.

When I listen carefully to what they are saying, I hear something familiar. They are grieving.

That is not a criticism. Grief is a reasonable response to losing something you care about. For many developers, the craft of writing software by hand, the skill they spent years building, feels like it is slipping away.

So let’s talk about it. I think developers are moving through the five stages of grief that Elisabeth Kübler-Ross described in her 1969 book On Death and Dying. And I think the ending is better than most of us expect.

Stage 1: Denial

“AI can’t write production code.”

“It’s just fancy autocomplete.”

“It makes too many mistakes to be useful.”

I said some of these things myself two years ago. I was wrong. The tools have gotten better, and they are going to keep getting better. Denial feels safe because it lets us avoid the harder questions. But it does not make the tools go away.

Stage 2: Anger

“This is going to destroy the craft.”

“Junior developers will never learn the basics.”

“Companies are just using this to justify layoffs.”

There is legitimate concern in every one of these statements. But anger, by itself, does not produce better outcomes. It just makes us harder to work with while the industry changes around us.

The developers who stay angry are going to have a rough few years.

Stage 3: Bargaining

“Maybe if I only use it for boilerplate, I’ll still be a true engineer.”

“If I become a prompt engineering specialist, I’ll be safe.”

“I’ll focus on the areas AI can’t touch.”

Bargaining feels productive because it looks like a plan. But most bargaining strategies are just denial wearing a different hat. You cannot carve out a small, protected corner of software engineering and expect it to stay protected.

Stage 4: Depression

“Why did I spend ten years learning this?”

“I’m becoming obsolete.”

“What is even the point of writing code anymore?”

This is the stage I worry about most. Developers in this stage often stop growing. They show up, do the minimum, and wait for the end. Their skills atrophy right when they should be growing the fastest.

If you are here, I want to say two things directly. First, what you learned is not wasted. The foundations of software engineering, like how to decompose problems, reason about systems, and make design tradeoffs, are worth more now, not less. Second, please do not stay here. Talk to someone. Find a developer who is excited about what is changing and ask them what they are learning.

Stage 5: Acceptance

This is where the good stuff happens.

Acceptance is not surrender. It is the moment you stop fighting what is happening and start working with it. The developers I see thriving right now are the ones who have accepted three things:

• AI is a tool, not a replacement. It makes good developers faster and bad developers worse.
• The foundations still matter. Maybe more than ever.
• The job is changing, but the discipline is not disappearing.

Making Products Is Not Dead

I want to say this plainly, because I think some developers need to hear it: Making software products is not dead.

Building products that solve problems for humans has never been about typing characters into an editor. Typing was always the least interesting part of the job. The interesting parts, understanding what to build, deciding how to build it, managing complexity over time, and communicating with partners and team members, have not been automated. They have been amplified.

If you are a developer who understands systems, who can decompose problems, who can make good design tradeoffs, and who can work well with other people, you have more opportunity in front of you right now than at any point in the last twenty years. The tools available today mean one developer can do what used to take five. That is not bad news for good developers. That is great news.

What to Do About It

If you are stuck somewhere in stages one through four, here is my practical advice.

• Use the tools. Daily. Not to evaluate them, but to build with them. You cannot reason about something you have not used.
• Keep studying the foundations. Read Fowler. Read Evans. Read Uncle Bob. The developers who will thrive are the ones who can direct these tools with good judgment.
• Get reps in on the parts of the job that are harder to automate: architecture, design, communication with partners, and mentoring.
• Talk to other developers about what they are seeing. Grief is easier to work through with company.

The people who built software ten years ago are not the same people who built it thirty years ago. The tools changed. The discipline adapted. It is happening again.

We are not at the end of something. We are in the middle of an adaptation. Those have always been uncomfortable. They have also always been where the best engineers got made.

Don’t panic, adapt.