A. C. on Unsplash
400 developers split into two camps — both are right
A 60-year-old developer named shannoncc posted on Hacker News that Claude Code had reignited the passion they felt decades ago. “I’m ready to retire,” they wrote. “In my younger days, I remember a few pivotal moments for me as a young nerd. Active Server Pages. COM components. VB6.” Technologies laughable by today’s standards, but transformative then.
“Fast forward decades and Claude Code is giving me that same energy and drive. I love it. It feels like it did back then. I’m chasing the midnight hour and not getting any sleep.”
The thread exploded. Over 900 comments from nearly 400 distinct voices. Developers in their fifties and sixties described breaking free from what burnstek, a 50-year-old developer, called
“the never ending rat race of keeping up with the latest bizarre web stacks, frameworks for everything, node for this, npm for that, Angular, React, Vue, whatever.”
For burnstek, AI coding tools were “the ultimate cheat code” — not because they replaced knowledge, but because they made architectural expertise actionable again without requiring fluency in this quarter’s framework idiom.
jitbit, turning 50, put the time pressure bluntly:
“I only have 10–20 active years ahead of me, so this is really, really important. Young ppl don’t get it.”
On the other side, samiv, a principal engineer, described feeling
“completely let down. I’ve spent decades building up and accumulating expert knowledge and now that has been massively devalued. Any idiot can now prompt their way to the same software.”
And then the line that crystallizes the wound: “People who weren’t very good at writing software are the ones now ‘most excited’ to ‘create’ with a LLM.”
kitd, also in their 60s and retiring that summer, offered the other face of loss: “Agents have removed most of the satisfaction and fulfilment from designing, building, testing and completing a feature or component.” They invoked the Luddites — not as insult, but as historical mirror. “Maybe it’s a question of expectations. I suspect weavers felt the same with the arrival of mechanised looms.”
Both camps are telling the truth. They’re just experiencing two fundamentally different things, and the distinction between those things is the single most important design question in AI right now.
The distinction nobody is naming
There are two kinds of tools. The first kind does things for you — it replaces your capacity with its own. The second kind rebuilds your capacity to do things yourself. Call them prosthetic and therapeutic.
A prosthetic tool substitutes. It takes a task you used to perform and performs it instead. The user becomes dependent on the tool for that function, and if the tool disappears, so does the capability. A therapeutic tool restores. It removes a barrier that was preventing you from exercising the capacity you already had, and once that barrier is gone, you’re more capable than you were before — with or without the tool.
This isn’t an abstract taxonomy. It’s what’s happening in real time across those 900 comments.
What the joyful developers are actually experiencing
The 60-year-old who can’t sleep isn’t excited because an AI writes code for them. They’re excited because, after decades of building architectural knowledge — understanding what systems should do, how components should relate, where failure modes hide — they were increasingly blocked by accidental complexity. Not the hard problems. The incidental ones. Which package manager? Which bundler config? Which framework’s idiom for something they’ve conceptually solved hundreds of times?
bartread, the same age as kitd and facing the same career twilight, described the opposite reaction to the same moment:
“I got completely fed up of continually having to learn new incantations to do the same shit I’ve been doing for decades.”
For bartread, Claude amounted to “the ultimate in declarative programming” — describing what you want rather than memorizing how to ask for it in this year’s syntax.
LogicFailsMe, another veteran, framed it differently: “I have more ideas than I have time to code up prototypes. Claude code has changed all that.” They called it “a never tiring eager junior engineer” — not a replacement for expertise, but an executor of it. And then the reveal: “I find no joy in frameworks and APIs. I find it entirely in doing the impossible out-of-sample things.”
These developers didn’t lose their capacity. It was buried under layers of toolchain churn that had nothing to do with the actual craft of building software. The AI tool isn’t replacing their judgment; it’s removing the silt that was covering it. That’s therapeutic. And it explains the emotional signature — not convenience, but reunion. They’re reuniting with a version of themselves that was always there but couldn’t get through.
What the grieving developers are actually experiencing
The principal engineer who feels devalued isn’t wrong either. When a tool flattens the skill gradient — when someone with shallow understanding can produce output that looks identical to expert output — the market signal for expertise degrades. That’s real, and it’s not irrational to mourn it.
But notice what’s being mourned. It’s not the loss of problem-solving capacity. It’s the loss of legibility — the ability for expertise to be recognized through its artifacts. When the artifact (working code) can be produced without the expertise (deep architectural understanding), the expertise doesn’t vanish, but its visibility does. And in a market that prices visibility, that’s an economic wound.
kitd’s grief is different from samiv’s, and the distinction matters. kitd lost satisfaction — the felt experience of building. samiv lost status — the market recognition of having built. Both are real losses, but they have different structures and different implications for design.
ACCount37 offered the clearest articulation of this divide:
“Do you enjoy the ‘micro’ of getting bits of code to work and fit together neatly, or the ‘macro’ of building systems that work? If it’s the former, you hate AI agents. If it’s the latter, you love AI agents.”
AI tools amplify the macro and compress the micro. If your identity lives in the micro, compression feels like erasure.
Why this distinction is a design imperative
Here’s what makes this more than a cultural observation: the same tool can be prosthetic or therapeutic depending on who’s using it and what it’s pointed at.
For the 60-year-old with deep architectural knowledge and declining patience for toolchain churn, Claude Code is therapeutic. It removes a barrier and restores capacity. For a junior developer who uses it to generate code they can’t evaluate, debug, or maintain, the same tool is prosthetic — and dangerously so, because it creates an illusion of competence without the substrate to support it.
The thread surfaces this worry too. switchbak pushed back directly on burnstek’s claim of not needing implementation details:
“Implementation details can very much matter though. I see this attitude from my managers that now submit huge PRs, and it is becoming a big problem.”
The same tool that liberates an expert creates blind spots for a novice. And latexr challenged the “democratization” framing entirely:
“There’s no democracy in being mostly beholden to a few companies which own the largest and most powerful models, who can cut you off at any time, jack up the prices to inaccessibility, or unilaterally change the terms of the deal.”
This means the question AI builders should be asking isn’t “how do we make the tool more capable?” It’s “how do we ensure the tool restores capacity rather than replacing it?” The answer depends on the user’s existing knowledge, the task’s complexity, and whether the tool’s design encourages the user to understand what it produces or merely accept it.
The time variable nobody is weighting correctly
There’s a third dimension that the thread reveals that neither camp fully articulates. The developers most enthusiastic about AI tools are overwhelmingly those with finite time horizons — people in their fifties and sixties who know they have 10 or 20 productive years left.
This isn’t incidental. It changes the entire optimization function. If you have 40 years ahead of you, building deep expertise has compounding returns — the investment pays off over a long career. If you have 10 years, the same investment has diminishing returns, and anything that lets you deploy existing expertise faster becomes enormously valuable. The tool hasn’t changed. The time horizon has. And it shifts the same artifact from prosthetic to therapeutic depending on where you stand in your own career arc.
This is why the two camps talk past each other. They’re not disagreeing about what the tool does. They’re disagreeing about what matters, and what matters is downstream from how much time they have left to do it.
The question that should keep AI builders up at night
Nearly 400 developers walked into the same thread and came out with opposite experiences of the same tool. That’s not a bug in the discourse. That’s a naturalistic experiment, and the results are exactly what a prosthetic/therapeutic framework would predict: restoration for those with blocked capacity, displacement for those whose value was legibility, and grief for those whose identity was process.
If you’re building AI tools and you aren’t asking “does this restore capacity or replace it?” at every design decision, you’re building something that will feel magical to some users and devastating to others — and you’ll never understand why, because you didn’t name the distinction.
The 60-year-old staying up past midnight isn’t excited about AI. They’re excited about being themselves again. That’s the design target. Everything else is a side effect.
Leave a Reply