"Do I Belong in Tech Anymore?" — AI, Vibe Coding, and the Developer Identity Crisis
The community data is in. Developers aren't just worried about their jobs — they're having an existential crisis about who they even are.
Three separate posts hit the front page of Lobsters in a single 24-hour window last week. All three were about the same thing: whether human coding still matters in 2026. The top one scored 146. The comment sections were a warzone.
Meanwhile, OpenMythos — a GitHub repo where developers are collaboratively reverse-engineering Claude's architecture from public artifacts — hit 10,458 stars in eight days. Eight days.
These two data points tell you everything you need to know about where we are. Developers aren't passively accepting the AI future being handed to them. They're anxious, they're angry, they're fascinated, and they're dissecting the systems being deployed against them with their own bare hands.
This is the developer identity crisis of 2026. And it's real.
What "Vibe Coding" Actually Means (And Why It Stings)
The term "vibe coding" started as a half-jokey description of prompting AI agents to write code while you mostly steer direction and vibe out. Karpathy popularized it. The discourse exploded.
Here's why it landed so hard: it perfectly captures the ambiguity of what a lot of developers are actually doing now.
Are you engineering when you write a system prompt, review the output, and ship it? Are you coding when you describe what you want to a coding agent, approve its diffs, and merge? The old answer was obvious. Now it isn't.
And the community hates not having a clean answer.
The Lobsters thread with score 84 and 49 comments was headlined something like "The People Do Not Yearn For Automation." It wasn't about AI replacing jobs in the abstract — it was about whether the Mac App Store is now flooded with AI-slop apps nobody wanted, built by people who wanted the output of development without the craft of it. The replies were split almost perfectly in half.
Half the developers: "This is democratization. More people making things is good."
Half: "This is dilution. It devalues what we spent years learning."
Both sides are right. That's the problem.
The Three Kinds of Developers Right Now
After watching these community threads for months, I think there are roughly three camps:
1. The Accelerationists
These are the developers who have genuinely integrated AI into their workflow and feel more productive than ever. They've internalized the new stack: agent + spec + review loop. They're shipping faster. They think the identity crisis discourse is cope from people who are bad at adapting.
They have a point. If you're building products and getting things done, the methodology is secondary. Results matter.
2. The Preservationists
These are the developers who believe the craft of writing code — actually thinking in code — produces qualitatively better outcomes that you cannot get from steering an AI. They're not Luddites. They use AI tools. But they believe there's something being lost when the primary skill becomes prompt engineering instead of algorithmic thinking.
They also have a point. There's a reason OpenMythos exists and has 10k stars. Developers want to understand the systems they're working with at a deep level. That instinct doesn't go away just because the tooling changed.
3. The Confused Majority
This is most developers. They're using Copilot or Claude Code. Sometimes it feels like cheating. Sometimes it feels like the future. They're not sure if they should be learning Rust or learning prompt engineering. They applied for three jobs last month and two of the listings had "AI-native" in the requirements without defining what that means.
They're not having an identity crisis in a dramatic sense. They're just... uncertain. And uncertainty at scale looks a lot like a crisis.
The Burnout Angle Nobody Is Talking About
Here's the thing that's getting buried under the philosophical debates: AI-assisted development is tiring in a different way than regular development.
When you write code yourself, the cognitive load is high but the feedback loop is intimate. You understand what you built. You can hold it in your head.
When you're managing an AI coding agent across a large codebase, you're doing something more like... editing and fact-checking and architectural review, simultaneously, at speed. You're trusting outputs you didn't produce. You're reading diffs you didn't write. You're context-switching between "does this do what I asked?" and "is this the right thing to ask for?"
It's a different kind of exhaustion. And the tooling hasn't caught up with the cognitive demands.
Traditional dev fatigue:
→ Deep focus → flow state → solution → satisfaction
AI-assisted dev fatigue:
→ Brief prompt → review → correction → re-prompt → review
→ trust gap → review again → merge with mild unease → repeat
The trust gap is the thing. Every experienced developer I've talked to who works heavily with AI agents describes some version of it: a low-level background hum of "did I actually understand what just got shipped?" You can minimize it with good practices, but you can't eliminate it entirely. Not yet.
OpenMythos and the Developer Counter-Response
The OpenMythos repo is the most interesting signal in all of this, and it's not getting enough coverage.
If developers were truly comfortable with AI as a black box, nobody would spend their spare time reverse-engineering its architecture from conference papers, blog posts, and behavioral tests. But 10,000+ developers starred a collaborative project to do exactly that.
This is what developer culture does when it feels disempowered: it investigates. It builds. It makes the opaque legible.
The old guard did this with operating systems. They did it with compilers. They did it with browsers. Now they're doing it with the AI systems that are reshaping their work.
That's not cope. That's craft. And it's a good sign.
The Practical Question: What Should You Actually Do?
If you're in the confused majority and looking for something actionable, here's my honest take:
Stop trying to decide if AI coding is "real" coding. The question is philosophically interesting and practically useless. What matters is whether you can build things that work and maintain them over time.
Get opinionated about your AI usage. The developers who seem least burned out are the ones who have clear personal policies: "I use AI for boilerplate and tests, I write core logic myself" or "I always read every line before merging, no exceptions." Ambiguity about your own process is cognitively expensive.
Learn something AI is bad at. Right now that includes: deeply understanding existing large codebases, debugging weird emergent system behavior, making good architectural decisions with incomplete information, and interpersonal engineering work (design reviews, technical mentorship, stakeholder communication). These are all durable skills.
The fundamentals still compound. Understanding how memory allocation works, how the network stack behaves, how databases make query plans — this knowledge makes you better at using AI tools, not worse. The developers who use AI most effectively tend to have strong fundamentals. That's not a coincidence.
Stop doom-scrolling the discourse. The Lobsters and HN threads are useful data about community sentiment but they're a terrible guide to career decisions. The people who are most vocal about the end of developer jobs are rarely the ones who'd be hired over you anyway.
What "Belonging in Tech" Actually Means in 2026
The developers asking "do I belong in tech anymore?" are almost always asking a subtler question: does the thing I'm good at still matter?
For most of them, the honest answer is yes — but the way it matters is shifting. Systems thinking, debugging intuition, architectural judgment, clear technical communication: none of that is going away. What's going away is the premium on typing syntax quickly and knowing library APIs from memory.
That's a real change. It's okay to grieve it a little. The feeling that you spent years mastering something and the rules just changed — that's legitimate. Don't let anyone tell you it isn't.
But here's what the OpenMythos crowd already figured out: the rules changed, so now we study the new rules. We understand the new systems. We build literacy around the new tools the same way we built it around the old ones.
The developers who thrive in the next five years won't be the ones who were earliest to embrace AI or the ones who resisted it longest. They'll be the ones who stayed curious enough to actually understand what these systems do — and skeptical enough to know when not to trust them.
That's always been the job.
One More Thing
The dev identity crisis isn't unique to this moment. Every major platform shift — web, mobile, cloud — triggered the same questions. "Is this still real programming?" "Does my expertise still count?" The developers who asked those questions and kept building are still here. The ones who stopped building while waiting for a definitive answer mostly aren't.
The question "do I belong in tech?" has always had the same answer: if you keep showing up and making things, yes. The tools change. The belonging is up to you.
Got a take on this? Drop it in the comments — I'm genuinely curious where other developers are landing on the burnout question specifically.
Top comments (0)