Beyond AI Anxiety: How Developers Can Redefine Their Value

AI replaces code translation, not engineering judgment — experienced developers gain leverage, not obsolescence.
Developer Simon Willison argues that the existential anxiety engineers feel when AI outpaces them is a shared transitional phase, not a personal crisis. AI truly replaces only the act of translating precise specs into code — core skills like requirements understanding, architectural judgment, and systems thinking remain. More importantly, deep experience is a lever that amplifies AI output rather than a liability. Willison also notes that software has always demanded adaptation to constant change, and the path forward is shifting focus from "will I be replaced?" to "what can I now build that I couldn't before?"
When an AI coding assistant completes in an hour what would have taken you a week — and does it remarkably well — the sense of loss is real and widespread. Developer Simon Willison's comment on a Hacker News thread titled "Feeling sad about AI" cuts to the heart of an existential anxiety gripping countless software engineers today. What reads like a brief response actually offers a clear path through this emotional crisis.
That Sense of Loss Is Universal — and Temporary
Willison candidly acknowledges that many people, including himself, went through exactly these kinds of "existential crisis moments" a few years ago, and have since come out the other side. That statement alone carries real comfort — it reframes what feels like an isolated, personal struggle into a shared inflection point for an entire professional community.
The initial reaction is almost instinctive: when a coding agent produces high-quality work at speeds no human can match, it's deeply demoralizing. The root of that demoralization isn't simply the work being taken over — it's the shaking of an identity. The skills you once took pride in suddenly seem less scarce.
What's worth reflecting on is that this feeling isn't unique to software. Any profession built on a "scarce skill" goes through a similar psychological process when technology shifts the ground beneath it. Acknowledging the emotion, living through it, and moving past it is itself the first step in navigating change.
What's Being Replaced Is Just One Link in the Chain
Willison's core insight is a precise dissection of the skill set involved. He notes that what's truly unsettling about AI is the proof it offers that "translating a precise specification into decent code" is no longer a distinctive skill.
This is a crucial distinction. A software engineer's value was never — and never should have been — reducible to the single act of turning clear requirements into code. Once you accept that premise — that code translation has been commoditized — you can lift your eyes and see the far larger set of problems software engineers actually contend with.
In Willison's words: "there is so much left." Ambiguous requirements, system complexity, architectural trade-offs, team coordination, business understanding — these are precisely the areas where AI currently struggles to operate independently, and where experienced engineers deliver the most value.
Experience Is a Lever, Not a Liability
One of the most powerful arguments in the post is this: existing skills and experience haven't lost their value — they've become the key advantage in wielding new tools.
Willison makes this explicit: an engineer with deep accumulated experience can truly harness these new tools, create value, and operate at a level far beyond someone who has no foundational knowledge and is trying to build software from scratch using agents alone.
This point is worth sitting with. AI tools have lowered the barrier to entry — but they've simultaneously amplified the value of judgment. When code generation becomes cheap, the decisions about what to generate, whether what was generated is correct, and where the systemic risks lie become more valuable, not less. Experienced engineers holding AI as a lever see the ceiling of their output raised significantly, not lowered. Put another way, AI widens the capability gap between the knowledgeable and the novice — it doesn't close it.
Those Who Refuse to Change Will Truly Struggle
Willison doesn't shy away from the other side of this conversation. He says plainly: if you genuinely don't want your career to change in any way, you're going to have a hard time.
But he immediately follows with a sharp counter-question: when has software engineering ever been stable? Which of the tools and languages we use has managed to go more than roughly five years without dramatic upheaval?
This is a historical observation that's nearly impossible to argue with. From language transitions to framework cycles, from local development to cloud-native architectures, software developers have implicitly accepted "frequent and dramatic change" as a given from day one of their careers.
The change AI is bringing may be arriving faster, but it doesn't fundamentally deviate from the industry's operating logic. Willison's conclusion borders on philosophical: if you chose software development as a passion, you chose from the start to embrace constant upheaval. This isn't an unexpected shock — it's part of the inherent contract of the profession.
Turning Emotion Into Action
Taken together, the value of this brief comment lies in completing a reframe: it neither denies the disruption AI brings, nor offers empty reassurances that everything will be fine. Instead, it provides a set of actionable cognitive adjustments — acknowledging that the loss is normal, identifying what is actually being replaced, rediscovering the leverage of experience, and ultimately returning to the historical norm of industry-wide change.
For developers living through this anxiety, the real way forward may not be resistance to change, but rather a shift in focus — from "will I be replaced?" to "how do I use these tools to do things I couldn't do before?" The definition of skill is evolving, but the space for creating value has never disappeared. If anything, it's been opened further by the very tools causing the unease.
Related articles

A New Paradigm for Text Editing in Compose: TextFieldState Replaces the Old API
Jetpack Compose introduces the TextFieldState API to fix dropped characters and cursor jumps from async input. The old value/onValueChange callbacks will be deprecated in 1.13. This article covers InputTransformation, OutputTransformation, four state hoisting patterns, and new formatted text editing capabilities.

Remote Compose: A New Document-Driven Paradigm for Cross-Platform UI on Android
Remote Compose transmits compact binary documents instead of screen pixels, enabling efficient UI rendering on remote surfaces like Wear OS and widgets. This article covers its document creation API, expression animations, size optimization techniques, and Wear OS progress.

How Crashlytics Eliminates Android Memory and Responsiveness Issues
Through the Chroma Clip case study, this article explains how Firebase Crashlytics uses Application Exit Info, Profiling Manager, GWP ASAN, and ARM MTE to pinpoint ANRs, OOMs, memory limit terminations, and native memory corruption—solving the challenge of stack traces that don't point to the real culprit.