Richard Teachout // Teachout.com
← All writing

The Developer Is Dead. Long Live the Developer.

The 7 Stages of Developer Grief in the Age of AI

Richard Teachout
Richard Teachout CTO at Ashley Furniture Industries - Executive Tech Leader, Entrepreneur, AI leader, Architect, Problem Solver, Ex-Developer. August 10, 2026
AI Leadership
The Developer Is Dead. Long Live the Developer.

Why you ask? Because every developer I know is going through something right now. It's not the same thing for all of them, but it rhymes.

Some are angry. Some are quiet in a way that worries me. Some are pretending nothing changed, and a few have come out the other side and won't stop telling you how good it is.

Here's the thing: they're all describing the same event. The event is that the thing you spent years learning how to do is now something a machine can do a lot of. Not all of it. But enough of it that "I'm the person who writes the code" is no longer a complete answer to the question "what do you do?"

I've watched this play out across teams, and it follows a pattern closely enough to be predictable. I call it the seven stages of grief for a developer over AI. Not the clinical stages. The professional ones. You can probably find yourself in here, and knowing which stage you're in matters — because the industry is not waiting for you to finish grieving.

Stage 1: Denial — "It's a Fancy Autocomplete."

Denial is the comfortable stage. It's easier to believe the outputs are garbage than to engage with what they mean. So you don't try it. You skim a few bad examples and file the whole category under "toy."

The tell is that you have strong opinions about a tool you haven't run on real work. You're not evaluating it; you're defending a position.

Denial costs nothing until it costs a lot. The first team that gets genuinely comfortable with these tools gets faster, and you'll notice. That's the moment denial breaks — not because you were convinced, but because the evidence got too loud to ignore.

Stage 2: Anger — "This Is a Race to the Bottom."

Anger is usually justified, which is what makes it dangerous.

You're angry at the tool for being good at the wrong things. At the vendors for overhyping. At leadership for believing the demos. At the junior who pastes code they can't explain. At yourself, a little, for feeling obsolete.

Some of that anger is legitimate grievance. The tools are oversold. The demos are cherry-picked. There's real craft in what you do that the marketing doesn't acknowledge. None of that is wrong.

The trap is that anger feels productive and isn't. It's the stage where developers get loud on the internet and quiet at work. It's also the stage where the learning stops — and the gap between you and the tool starts compounding in the wrong direction.

Stage 3: Bargaining — "I'll Use It for the Boring Stuff Only."

The negotiation phase.

I'll only use it for boilerplate. I'll never let it touch the core system. I'll keep my real work offline. If I learn prompt engineering, I'll be one of the ones who survives.

The bargain always fails for the same reason: the tool doesn't respect your boundary, and the market doesn't either. The line you drew — "here, but not there" — is invisible to everyone except you. Your team doesn't see it. Your manager doesn't. The tool certainly doesn't.

Bargaining isn't wrong. It's how most people start using the thing, and starting is good. It just isn't a strategy. It's a way of letting the tool in while telling yourself you stayed in control. Eventually the distinction stops holding.

Stage 4: Depression — "What Was the Point of Twenty Years of Learning?"

This is the one nobody writes about, and it's the stage most developers are actually in.

Not clinical depression. Professional grief. Your identity was built on "I'm someone who writes code." If code can be generated, the question becomes: who are you, exactly? And that question has no comfortable answer in the first month of asking it.

This is where developers get stuck. They stop shipping. They stop learning. They quietly disengage, and nobody notices for a while because the code they would have written still gets written — by the tool, badly, without them.

From the outside it looks like laziness. From the inside it feels like grief. If you manage people, this is what you should be watching for, because it's the stage that costs you your best people.

And one more thing: the pep talk doesn't work here. Telling someone in this stage "AI is just a tool" is technically true and emotionally useless. That's stage-five medicine delivered to a stage-four person.

Stage 5: Acceptance — "OK. It's a Tool. Some of It Is Genuinely Good."

Acceptance isn't surrender. It's the first stage where you're working with reality instead of against it.

You find where it genuinely helps, and it's almost always the code you never enjoyed writing. Glue code. Tests. Migrations. Refactors. The eighty percent of the job that was always someone else's idea of fun.

And you find where it's a liability: architecture, invariants, production judgment — anywhere that being confidently wrong is expensive. The bug isn't usually that the tool wrote bad code. It's that it wrote confident code, and confidence is not the same as correctness.

Acceptance is where you get honest about what you actually do all day. The surprising part is that the honest answer was never "type code." It was always "make sure the right thing gets built and keeps working." The typing was just the delivery mechanism.

Stage 6: Reinvention — From "I Write Code" to "I Decide What Gets Built and How It's Verified."

This is where the evolution of the developer actually happens.

The unit of work stops being lines of code and becomes decisions made and verified. You become the person who specifies intent, reviews machine output, and catches the confidently wrong. You become the person who knows what the system is supposed to do and holds it to that.

This stage is uncomfortable for a different reason: the old metrics stop applying. Lines of code. Commits. Pull requests. All of it measures the thing that just got cheap. The new job is measured by outcomes — uptime, correctness, how fast the business can move — and outcomes are harder to show off in a standup.

Some developers never make it here. They keep defining themselves by the old unit of work and feel the value drain out of it in real time.

Stage 7: The New Craft — "The Job Didn't Die. It Moved Up the Stack."

The final stage isn't acceptance. It's a new identity.

One engineer with good judgment and capable tooling can now do the work that used to take a team. That sounds like a threat. It's actually the definition of leverage — and leverage has always been the real career strategy in this profession.

The scarce resource is no longer typing. It's taste, context, and judgment. Knowing what's worth building. Knowing what could break. Knowing when the confident answer is wrong. Those are the things a model doesn't have, and they're exactly the things you've been accumulating for years without realizing they were the point.

Software development is turning into software stewardship. The production of code is becoming a commodity. The production of certainty — deciding what gets built, verifying it, owning what happens when it's wrong — is becoming the job.

The developers who walk through all six stages before this one are the ones who get to define what the profession becomes. The ones who don't get defined by it.

The Industry Is Not Waiting

Every month the boundary moves. I'm not going to tell you that's good news, because the grief part of it is real, and pretending otherwise insults everyone going through it.

But here's what I've watched: the developers who are thriving didn't skip the stages. They went through them — sometimes in order, sometimes faster than they expected. They let the old identity die, and they built a new one that didn't depend on being the person who types the code.

The part of you that's grieving is the part that was attached to the old definition of the job. That's not weakness. It's the price of having cared about the craft.

The new definition of the job is better. It pays more, it's harder to automate, and it needs the judgment you've been building your whole career — the judgment that was never really about the code at all.

Let the old one go. There's work to do.

Think this argument fits your event? Tell me about the room — the calendar is selective.

Start a conversation