Developers Are Having an Identity Crisis

James Phoenix
James Phoenix

Deedy Das named it: most software engineers are facing an identity crisis bordering on depression. He is right that it is happening, and right about how it looks. He is wrong about what it is. The crisis is not that you turned out to be lazy, or that the craft you loved is dying. It is that the one thing your identity was built on, understanding the code you ship, just got decoupled from shipping it. The way out is not to cling harder to the old identity. It is to find the one worth having now.

Date: June 2026 | Riffs on: Deedy Das, “Most software engineers are facing an identity crisis”


The crisis is real

Deedy splits the profession in two. The lazy see a Jira ticket, prompt for the task, and submit code they never read or tested. A comment on the PR? Ask AI. A Slack message? Ask AI. Standup prep? Ask AI. As long as the autopilot sounds enough like them and goes undetected, the smart lazy ones get rewarded, and some are quietly overemployed across several jobs. The craftsmen carry the other half: fifteen PRs in the queue, the whole burden of understanding on them, a thoughtful review answered with a cheerful “You’re absolutely right” and a wrong change, then a 20,000-line PR the next morning. The load grows, bugs reach production, nobody seems to care, and one day the craftsman gives up.

It is vivid and it is true, and the dread underneath it is real. For most of us the job was the identity: I am the person who understands this system, who can be trusted with it, who reads the code and knows why it is shaped the way it is. AI did not just change the workflow, it came for that. When understanding stops being the thing that ships the code, the identity built on understanding starts to wobble. That is the crisis. The only question worth asking is whether it is a crisis about you, or about the system you work inside.

It is a pricing problem, not a personal one

Pull quote from Edgar Kussberg in the comments:
Pull quote from Edgar Kussberg in the comments: “Every unverified diff is a tax you quietly charge to your best people until they leave.”

The honest answer is that the crisis is structural, and it has a boring cause. For thirty years, writing code was the expensive step and review was a cheap side effect of a human being slow enough to understand what they typed. AI inverted that cost curve and nobody repriced the ledger. Generation fell to roughly zero. Verification stayed exactly as expensive as it always was, because it is still bottlenecked on a tired person reading a diff. The gap between those two numbers does not vanish. It gets posted, every single day, to the account of whoever still bothers to read the code.

Edgar Kussberg said the rest of it in the thread better than I could: the companies that stay productive did not hire better humans, they moved correctness into automated gates so review becomes a shared asset rather than the craftsman’s unpaid second job. Your identity did not fail. The ledger did. Call the person absorbing the tax a craftsman if you like. The org has a more honest name for them, which is the uncompensated insurance policy.

The lazy and the craftsman are the same crisis

This is where I get off Deedy’s bus. He frames the lazy and the craftsman as two kinds of people, two identities you get to pick between. They are two outputs of one function.

The lazy were not born lazy. Most are doing exactly what their CTO evangelised when he stood up and told everyone to tokenmaxx, optimising the metric that is actually graded: PRs merged, tickets closed, velocity up and to the right. A scoreboard that counts shipped diffs and prices review at zero will manufacture people who ship unread diffs. That is not a character flaw. It is the scoreboard working as designed.

Leanpub Book

Read The Meta-Engineer

A practical book on building autonomous AI systems with Claude Code, context engineering, verification loops, and production harnesses.

Continuously updated
Claude Code + agentic systems
View Book

The craftsman is the same crisis seen from the other side, the variable the org gets to leave unpriced, and Deedy’s own ending proves it: the craftsman does not give up out of weakness, he gives up because rational people stop paying a tax that buys them nothing but more tax. The slide is quiet. You adopt AI to keep up, you start spending your days reading its output, then you let the AI review the AI, and one stacked hallucination later you have stopped reading code at all. You become lazy without ever deciding to. Neither identity is a personality, both are what the system does to you.

So when someone asks me which camp I am in, I think the question is wrong. Both camps are weather. The pricing bug is the climate.

You cannot out-discipline your way back

The reason the crisis feels personal is that the obvious cure looks personal: try harder, be more noble, review more, write a better doc, hold more of the system in your head, reclaim the old identity by sheer will.

I made this same argument against Addy Osmani in Comprehension Debt Is Refinanceable. If the complaint is “code arrives faster than I can understand it,” then “understand more of it” is a footrace against a counterparty that just got ten times faster and gets faster again next quarter. You cannot out-discipline a generator running at machine speed, and asking the craftsman to be the heroic last line of defence is asking him to win that race with his bare hands. He loses, and then you lose him. The old identity, the one that ran on reading every line, is not coming back. Grieving it is reasonable. Brute-forcing it is not.

The identity actually worth having

Pull quote from Erik Rekola in the comments:
Pull quote from Erik Rekola in the comments: “Make the result verifiable by something other than a tired human. The craftsman stops being the last line of defense.”

There is an identity on the other side of this crisis, and it is a better one than the one you are mourning. Every durable answer in that comment section is a variant of one principle: move correctness out of the reviewer’s head and into the system around the code. This is the shift I keep returning to in Code Stewardship Over Authorship. When you cannot review every line, reliability has to become a property of the infrastructure, not of one heroic person’s attention. You stop being the person who reads the code and become the person who builds the system that reads it for you.

Erik Rekola’s own example is the template. He rebuilt a project with an agent and trusted it only because two independent checks read the result before and after. The agent did the typing, the measurement did the judging. That division is exactly what the four instruments in comprehension debt are for: types as the executable spec, tests as behavioural documentation, observability as runtime truth, and the agent as an on-demand explainer, all so a gate can judge a diff and a human does not have to. The governance underneath is mundane and it works: a real definition of done, tests the code must pass, and merge gates that do not hinge on one tired person’s goodwill at 6pm. And the sharpest lever is almost rude in its simplicity. Make whoever shipped the unread diff own its uptime and its pages, and the tax stops flowing downhill and lands on the desk that created it.

None of this is anti-AI. It is the substrate that lets you run more AI safely, by pinning behaviour in a spec and a typed contract before generation so review collapses from “read 20,000 lines and pray” into “check the diff against the contract.” That is the whole thesis of the spec-driven camp and of evals over vibes: you constrain the noisy channel instead of pushing more tired humans through it.

Who you are now is who pays for verification

There is a real divide here. It is just not the one Deedy drew, and the word “lazy” actively hides it. The best engineers I know use AI more than the so-called lazy, not less. I argued the full case in AI Leverage Without Skill Atrophy: the variable that matters was never how much AI you use. It is whether you ship onto a verified substrate or an unverified one, and therefore who pays for verification.

The genuinely high-leverage engineer ships a large volume of AI-written code onto types, tests, evals, and telemetry that catch the model when it lies, so verification is paid by the machinery, in advance, once. The “lazy” engineer ships the same volume onto nothing, so verification is paid by a colleague, later, forever. Same tools, same throughput, opposite externality. That, not how much of the code you personally read, is the identity line worth drawing.

I feel this acutely as a team of one. Across roughly 350K lines of production code there is no colleague downstream to absorb my unverified diffs, so the tax does not land on a craftsman two desks over. It lands on future-me, at 2am, on the parts I merely approved instead of understood. Being solo just makes the pricing visible, because the externality has nowhere to hide. It always lands on you.

One sentence

The identity crisis is real, but it is not about whether you turned out to be lazy or a craftsman. It is that understanding got decoupled from shipping, and the engineers who come out of it whole are the ones who rebuild the link in the system instead of in their own exhausted heads.

Related

Topics
CareerDeveloper ExperienceSoftware Architecture

Newsletter

Become a better AI engineer

Weekly deep dives on production AI systems, context engineering, and the patterns that compound. No fluff, no tutorials. Just what works.

Join 306K+ developers. No spam. Unsubscribe anytime.


More Insights

Cover Image for Why a Pure Reducer Beat MailerLite for Lifecycle Email

Why a Pure Reducer Beat MailerLite for Lifecycle Email

How a pure reducer plus Resend collapsed the cost of running lifecycle email, and why the automation-SaaS calculus flipped.

James Phoenix
James Phoenix
Cover Image for The Evolution of AI Coding up to 2026

The Evolution of AI Coding up to 2026

Software was always written in a loop: change something, run it, check the result, repeat. The last five years did not replace that loop. They kept widening the thing inside one turn of it, from a single line to a recurring workflow, and moved me one rung up the stack each time.

James Phoenix
James Phoenix