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

Coinbase Engineer: How to Determine Whether an AI Agent Can Operate Unattended
Coinbase engineer Evan Kormos shares an engineering method for judging whether an AI agent can run unattended: model processes with DAG/DCG, replace output comparison with statistical evaluation, and hand over control in three phases—supervision, sampling, and exception handling.

WorkBuddy Beginner's Guide: How AI Agents Automate Office Tasks
WorkBuddy tutorial: learn how this desktop AI agent workbench automates files, organizes data, and generates documents, compared with LLMs and Codex, plus a beginner path and cost analysis.

Doubao Work in Practice: Three Modes That Let AI Actually Get Work Done
Doubao Work practical tutorial: from chat mode to Work Mode Lite and Pro, explaining the logic for choosing among three modes with real office task demonstrations. Even complete beginners can learn to use an AI agent to handle local files, organize materials, and generate documents.