AI Burnout: "Do I Still Belong in Tech?"
A developer's honest reckoning with the identity crisis no one wants to admit they're having
Something shifted recently, and developers are finally saying it out loud.
"Do I belong in tech anymore?"
That question — raw, exhausted, a little desperate — hit the front page of Lobsters recently with 198 points and 63 comments. Meanwhile, Hacker News surfaced its own version: "AI should elevate your thinking, not replace it," which pulled 414 points and hundreds of replies. Two posts, same wound.
This isn't imposter syndrome. It's something newer and harder to name: the quiet grief of watching a skill you spent years building become a prompt.
The Old Bargain
There used to be an unspoken deal in software development: learn the hard stuff, do the time, and you'd earn both a livelihood and a kind of craftsman's pride. You'd know things. You'd be good at things. The expertise was yours.
That deal isn't gone — but it's wobbling.
When you can type "build me a REST API with authentication, error handling, and tests" and get 80% of the way there in thirty seconds, something changes. Not just the workflow. The feeling of doing the work. The thing you were proud of knowing how to do from scratch? Increasingly a prompt away for anyone with a laptop.
A lot of developers are reacting to this with a very human emotion: grief. And then they feel embarrassed about the grief, because it sounds like complaining that things are getting easier. So they don't say it. Until now, apparently.
What the Burnout Actually Feels Like
Let me name the specific flavors, because "AI burnout" is a catch-all for a few distinct experiences:
The Deskilling Anxiety: You stop writing certain types of code by hand, then one day realize you've forgotten how. Not retired the knowledge — forgotten it. This one hits differently for people who built their confidence on depth.
The Prompt-Engineering Treadmill: You spend your day doing this new kind of work — wrangling AI output, writing better prompts, reviewing generated code, fixing the subtle bugs the model introduced. It's cognitively demanding. But it doesn't feel like the work you signed up for. Some people find it engaging. Many find it draining in a way they can't quite articulate.
The Expertise Deprecation Shock: You spent three years getting really good at, say, CSS grid layout, or Kubernetes configuration, or writing clean state management logic. The models are now competent at all of it. That competence isn't worthless — but it's less differentiating. The moat you dug feels shallower.
The Identity Collapse: This is the deepest one. "I'm a developer" used to mean something specific about what you could do. That identity is now in flux. If a model can generate the code, what does it mean to be the developer?
The Psychology of Craft and Identity
Here's something worth naming plainly: developer identity is unusually tied to technical capability. More so than most professions.
A project manager doesn't typically define themselves by their ability to manually write Gantt charts. But developers often define themselves by their ability to write code — specific kinds of code, in specific ways. It's a craft identity, in the old guild-artisan sense. That's not a weakness; it's what makes good developers care so much about quality.
When that craft gets automated — even partially — it attacks something psychological, not just professional.
Research on creativity and human flourishing suggests this isn't irrational. Autonomy, mastery, and purpose are among the core drivers of intrinsic motivation. AI tools can cut directly into all three: autonomy (the AI decides structure), mastery (the skill gap closes overnight), purpose (am I doing meaningful work, or just reviewing AI output?).
This is real. It's not a failure of attitude or adaptability. It's a genuine identity threat that the industry is handling with a lot of denial and a lot of blog posts about "prompt engineering as the new programming."
What Actually Helps (and What Doesn't)
Let's get concrete. I've talked to developers across the spectrum — those thriving in the transition and those genuinely struggling.
What doesn't help:
"Just learn to use AI tools better" — True but dismissive. This treats the burnout as a skills gap when it's often an identity gap.
"Focus on the high-level work" — Also true, but for many developers, the "low-level work" was the high-level work they cared about. Systems programming, performance optimization, careful algorithm design — these don't feel like grunt work to the people who love them.
"AI will create new jobs" — Probably true in aggregate over a decade. Unhelpful if you're 35 and burning out right now.
What actually helps:
Distinguish replacement from amplification deliberately. Not "AI does this now" but "what is AI doing to this specific type of work I do?" Some things are genuinely being automated away. Others are being amplified — you can go deeper, move faster, tackle harder problems. Knowing which is which matters.
A useful heuristic I've seen work:
If the value was in PRODUCING the artifact → AI threat
If the value was in UNDERSTANDING the domain → AI amplifier
Writing CRUD boilerplate: production value. Understanding the data model it represents: domain value. The first is largely automated. The second is not.
Build work that requires judgment over time. AI models are excellent at well-defined, bounded tasks. They struggle with problems that require accumulated context, fuzzy organizational knowledge, and judgment calls that only make sense if you've seen how this specific system breaks. That's where experienced developers still have enormous leverage.
Let yourself grieve. Seriously. The industry wants everyone to immediately pivot to "and here's what's exciting!" If you're mourning the loss of a kind of work you loved, you're allowed to sit in that for a minute. The developers I've seen transition best are often the ones who acknowledged the loss instead of skipping past it.
The Harder Question
There's a version of this where we say "AI will elevate your thinking" and move on. It sounds right. It might even be true for many developers. But it sidesteps the genuine class question underneath:
Not all developers are in the same position.
A senior engineer at a well-funded company, with leverage and specialized knowledge and a team that values depth? Probably fine. The transition is uncomfortable but manageable.
A mid-level developer in a commoditizing market, doing the kind of work that models are now very good at, at a company looking to cut costs? The math looks different.
AI optimism that doesn't reckon with this is selective optimism. And developers can smell it.
The industry tends to generate advice aimed at the first group and pretend it applies to everyone. It doesn't.
What I Actually Believe
After sitting with this for a while: the developers asking "do I still belong in tech?" are not weak or behind or failing to adapt. They're having a reasonable reaction to a genuinely disruptive transition that's happening faster than most people expected.
Some of them will thrive in the new landscape. Some will find that the parts of software development they actually loved have been narrowed, and they'll need to decide whether the remaining work is worth it to them. Some will pivot. Some will double down on the craft work and find there's still room for it.
All of those are valid outcomes. What's not helpful is pretending the transition is costless, or that discomfort is just a skills gap.
The developers who are thriving aren't the ones who suppressed the discomfort — they're the ones who took it seriously enough to figure out what they actually valued about the work, then found ways to protect or rebuild that value in a changed landscape.
That's not a simple process. It takes time. It deserves more honest conversation than the industry is currently having.
A Framework for Moving Forward
If you're in the thick of this, here's a rough framework I've found useful:
1. Audit what you actually value about your work.
Not what you're supposed to value. What actually makes you feel good at the end of a day? Is it the problem-solving? The craft of the code itself? The systems thinking? The collaboration? Be honest.
2. Check whether AI competes with or amplifies that thing.
Sometimes it's not either/or — it competes with the boring parts and amplifies the interesting ones. But you need to look clearly at this, not assume it works out fine.
3. Make deliberate choices about what to protect.
Some people decide they still want to write certain code by hand, even when they don't have to, because the act matters to them. That's a legitimate choice. So is going all-in on AI tooling. What's not sustainable is passive drift in either direction.
4. Find your tribe.
The people having this conversation honestly are out there. The denial-and-positivity crowd is louder, but there are developers sitting with the same questions you are. Finding them matters more than it sounds like it would.
The question "do I belong in tech anymore?" deserves a real answer, not a pep talk.
The honest answer is: that depends on what your tech is, what it means to you, and what you're willing to build from here.
That's harder than "yes of course you do" — but it's more useful.
Have you navigated AI-driven burnout? I'd genuinely like to hear how. Drop it in the comments.
Top comments (0)