In 2019, comedian Gary Gulman released an HBO special called The Great Depresh. The title puns on the 1930s collapse, but the special is about Gulman’s own clinical depression — the hospitalization, the electroconvulsive therapy, the long climb back. He calls it “depresh” throughout. The diminutive is the point: “depression” was too heavy to say out loud for years, so he found a smaller word that let him talk about it at all. The special ends on a line he delivers like a weather report: “My depresh is in remish.”
Something adjacent is moving through the developer community, and most people don’t have a name for it yet. It isn’t burnout, and it isn’t fear of replacement, though that gets blamed for it. It’s a specific malaise in senior engineers who, by outward measures, are doing fine — shipping more, faster, with tools that work. They feel worse anyway. Call it the Coding Depresh.
The Depresh is real, it’s documented, and there’s a path out that doesn’t require pretending the loss isn’t a loss. I write from an unusual position. I spent eight years as CTO of TripAdvisor managing more than 560 engineers, mostly not writing code, and I missed it. I came back to hands-on coding in March 2025, entirely through AI tools — my re-entry and AI-assisted development are inseparable. I never had to grieve a pre-AI coding identity, because I didn’t have one to defend. That gives me a strange vantage point on the engineers who did.
TL;DR
The Coding Depresh is identity disconfirmation, not job-loss fear: when the thing you built your professional self around gets automated, “who am I as a developer?” stops having an easy answer.
It’s documented. A 15-year veteran describes shipping an AI-built pipeline and feeling grief “for an identity.” Stack Overflow’s 2025 survey shows distrust in AI accuracy (46%) outrunning trust (33%) for the first time, even as usage climbed to 84%.
The most-cited evidence that AI slows experienced developers — METR’s 2025 trial showing them ~19% slower — has been retired by the same researchers, whose redesigned data now points the other way. Even the skeptics’ own number moved.
A different camp — the Energesh — reports feeling more capable, not less. The fault line isn’t seniority or skill. It’s your answer to “who are you as a developer.”
The most useful question I’ve seen comes from an Anthropic engineer: “I thought that I really enjoyed writing code, and I think instead I actually just enjoy what I get out of writing code.” Where you land tells you where you live.
For engineers in the Depresh, and the CTOs managing them: the craft instinct that makes the tools feel wrong is the most valuable thing you own. It doesn’t have to die for you to adopt the tools.
The Depresh is real, and it’s documented
Start with the most precise account I’ve found. George Violaris, a developer with fifteen years’ experience, wrote in March 2026 about shipping a data pipeline with AI assistance in an afternoon — work that would have taken him three days by hand. He expected pride. He got this instead:
“That evening, I felt something I can only describe as grief. Not for a person. For an identity.”
He goes on: “Three years ago, writing code wasn’t just what I did. It was who I was.” Then: “The ego death was real. ‘I am a person who writes excellent code’ had to die.”
This is not a man worried about his next paycheck. He shipped the thing. The pipeline is in production. What broke wasn’t his employment; it was the relationship between his sense of self and the work. Most of the public conversation treats developer anxiety as a labor-market story — real, severe for junior developers, but separate, and not the one I’m writing about.
The Depresh I’m describing hits a different person: the experienced developer whose answer to “who are you?” was “I am the person who writes excellent code.” For that person, the tools don’t threaten the job first. They threaten the identity first.
The numbers underneath the mood are strange. Stack Overflow’s 2025 Developer Survey, the largest census of working developers we have, shows two lines crossing. Favorable sentiment toward AI tools fell from 77% in 2023 to 60% in 2025, while usage or intent to use rose from 70% to 84%. People are adopting tools they feel worse about. Trust in AI accuracy dropped to 33% against 46% who distrust it — the first year distrust outran trust — and the top frustration, cited by 66%, was “AI solutions that are almost right, but not quite.” The most experienced developers are the most skeptical: only 2.5% “highly trust” the output, and use it all day anyway. Working with something you don’t trust, that demands verification you can’t delegate — that’s the exhaustion of vigilance without resolution.
Then there’s the METR study — less for the number most people quoted than for what happened to it. In 2025 the nonprofit METR ran a controlled trial with experienced open-source developers and found them 19% slower with AI assistants while they believed they’d been roughly 20% faster. That became the most-cited evidence that the tools don’t pay off. Then in February 2026 the same team retired it, writing that the original no longer reflects “the current impact of AI models on open-source developer productivity”; their redesigned measurement runs the other way, an estimated 18% speedup for the same returning developers. The intervals are wide, so the magnitude is soft — but the direction reversed, and why it had to be rebuilt is the tell: 30 to 50% of developers refused to submit tasks they expected AI to speed up, and many refused to work without AI at all. The measurement broke down because people won’t give up the tools. I read the original not as “the tools are bad” but as disorientation: when your instincts and the stopwatch disagree, then a year later the stopwatch reverses, your competence comes unmoored.
There is another camp, and it’s also documented
Here is what keeps the Depresh from being the whole story. A different group of engineers is having close to the opposite experience, and they’re not naive optimists or vendors.
Andrej Karpathy named the moment in February 2025: “a new kind of coding I call vibe coding, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.” He was describing a feeling, not a methodology. Simon Willison later coined “vibe engineering” for the responsible professional version — engineers using these tools deliberately to accelerate real work.
The output side is loud. Pieter Levels built a browser flight simulator with no game-development background and reached around $1M in annualized revenue in 17 days. Boris Cherny, who leads Claude Code at Anthropic, runs five parallel instances and ships 20 to 30 pull requests a day: “once there is a good plan, it will one-shot the implementation almost every time.”
This is where my own story sits. When I came back, the mechanics of typing code line by line weren’t part of my working identity — I’d been away from the keyboard for years. What I found waiting was the part I’d missed: building things, deciding what should exist, watching it take shape, fixing what’s wrong with it. The joy of building and the mechanics of writing code were never the same thing.
I can be concrete, because I’ve done it in the open. Since March 2025 I’ve shipped real, full-cycle software through these tools — not snippets, complete projects. The flagship is claude-mpm, a multi-agent orchestration platform for Claude with a real user base. Most of 2025 was Python; then in 2026 I taught myself Rust to build the trusty-* ecosystem — code search, memory, PR review, orchestration — something I wouldn’t have attempted by hand while running an org. Architecture, review, releases, the full loop, at a volume I couldn’t reach typing every line. Most of it is public on GitHub under bobmatnyc, so the claim is checkable. I’m not theorizing about the Energesh. I’m living in it.
What actually separates the two camps
Not seniority. Not raw skill. Not the domain you work in, though each shades the experience. The fault line is the answer you’d have given, before any of this started, to a single question: who are you as a developer? There’s an older version of the same split.
In the early nineteenth century the canuts were the silk weavers of Lyon, clustered in the Croix-Rousse district, working intricate patterns by hand. It was master-craft work, identity-defining — the skill lived in the fingers. Then Joseph Marie Jacquard demonstrated a loom that wove those same complex patterns automatically, driven by punched cards, doing in a single pass what had taken the weaver and an assistant by hand. The canut whose sense of self lived in the act of weaving, in the tight and skilled handwork itself, was displaced at the identity layer. The canut whose relationship was with the silk itself, the finished cloth, still had somewhere to stand. The fabric still got made. More of it, in fact. If your identity comes from the tight weaving rather than from seeing the cloth made, you are a Canut.
Coding has the same shape. If your answer to “who are you” was inseparable from “I am the person who writes the code” — the line-by-line authorship, the mechanical understanding of every decision, the craft of it — then AI arrives at the identity layer, not the job layer. Violaris’s grief is the correct, proportional response; it scales with how much of himself he invested. If your answer was closer to “I am the person who builds the thing that exists at the end,” the same tools feel like a gain. You were always pointed at the cloth, not the weave. The result just got cheaper to make.
There’s a quiet irony in the comparison. Jacquard’s punched cards are a direct ancestor of the computer — they ran on into Babbage’s Analytical Engine and later Hollerith’s tabulators and the IBM punch card. The mechanism that displaced the weaver became the machine the coder works on, now automating a layer of the coder’s craft too. Same lineage, one more turn.
The cleanest articulation comes from an Anthropic engineer, quoted in Anthropic’s own internal research on AI-assisted work:
“I thought that I really enjoyed writing code, and I think instead I actually just enjoy what I get out of writing code.”
That is the skeleton key. Most developers in the Depresh believe they love writing code, and they’re not wrong, exactly — but the two halves of that sentence always came bundled. You couldn’t get the output without the authorship. AI unbundles them. Do you love the writing, or what the writing gets you? Where you land tells you which camp you’re in, and it’s not always where you assumed.
Kent Beck’s vocabulary dissolves a false worry. He distinguishes augmented coding from vibe coding. In vibe coding you don’t care about the code, only the behavior. In augmented coding you care deeply about the code, its complexity, its tests — “it’s just that I don’t type much of that code.” The Energesh isn’t about lowering your standards: the taste and architectural judgment that took decades to build are still doing the real work.
David Heinemeier Hansson gives the sharpest version of the craft objection. DHH spent most of 2025 resisting agent-first coding, and his reason was a craft reason. On Lex Fridman’s podcast he said the joy is to type the code himself; he keeps AI in a separate window because letting it drive made him “feel competence draining out of [his] fingers.” He has since switched to an agent-first workflow, on the logic that the tools finally met his standard, not that his standard moved. His values stayed put; what changed was his assessment of whether the tools honored them. That’s the template: the resister and the convert are the same man with the same principles.
Which is why the craft instinct deserves defending, not demolishing. The tools feel wrong partly because you’re judging them against that instinct, not just against output. Its firing isn’t a malfunction — it’s the sharpest instrument you own, calibrated over years, telling you when something is almost right but not quite, the same complaint 66% named in the Stack Overflow data. The mistake is concluding it has to be put down for the tools to be picked up. It doesn’t.
The path from Depresh to Energesh
This part is for the reader sitting in the Depresh right now. It isn’t a pep talk, and I’m not going to tell you the feeling is irrational, because it isn’t.
Grieve first. The ego death Violaris describes is real, and you’re allowed to mourn it. The craft identity you spent years building had value — it shipped real systems and earned you a career. Skipping the grief doesn’t work. The developers I’ve watched leap straight to enthusiasm tend to adopt the tools resentfully and use them badly, half-hoping they’ll fail. Let the loss be a loss before you look for what’s on the other side.
Then ask the real question. The Anthropic engineer’s version: do I love writing code, or what I get from writing code? You’ve probably never had to answer it, because the two were never separable before. They are now. The answer isn’t a verdict on your worth as an engineer. It’s a map of where you actually live, and either answer is fine — but you can’t find the path until you know which is true for you.
Learn harness engineering. The on-ramp for a senior engineer goes up a level, not down. Vibe coding pulls you toward the model’s altitude; this pulls you above it. The harness is the tooling layer around the model — orchestration, context management, verification scaffolding, the agent configuration that decides what the model sees and whether you can trust what comes back. Engineering that layer rewards the judgment you spent years building: systems thinking, architecture, the discipline of making an unreliable component dependable. My own claude-mpm and trusty-* tools are harness engineering and nothing else. So skip the vibe-coded toy app. Pick something real, build the harness that drives it, and watch how it feels — whether you feel more like yourself, or less.
Reframe from author of code to author of outcomes. Your craft instinct — what good architecture looks like, what breaks at scale, when a design is quietly wrong — isn’t going away, and the model doesn’t have it. The model is fast, capable, judgment-free. You are slow by comparison and you have taste. The job becomes directing the thing and knowing whether what came back is right. Not a demotion from engineer to button-pusher. It’s the part of the work that was always hardest to teach, now occupying most of your day.
A word for the CTOs reading this: you have a version of this problem you may not have named. The Depresh shows up in your metrics before your one-on-ones: review cycles stretching out, code-quality variance widening, your most experienced engineers going quiet in design reviews. The path for them is the path for an individual — don’t push adoption before you’ve made room for the grief. And understand who you’re dealing with: the engineers who feel the Depresh most sharply are frequently your best ones, who invested most in the craft. Their standards are the feature, not the bug. Burn that instinct down to force faster adoption and you’ll get the adoption and lose the standards.
Where this leaves you
Gulman didn’t end his special by announcing he was cured. He said his depresh was in remish — smaller word, smaller claim, a thing managed rather than defeated. That’s about the right register for where the industry is.
The craft you built was real, and so is the grief if you’re feeling it. But the thing you actually loved — if it turns out to be the building, the deciding, the watching something work that didn’t exist this morning — that part never depended on you typing every character yourself. The canut whose love was the cloth still had cloth to make. You can find out which one you are. Most developers go a whole career without having to ask. You get to.
Your depresh can be in remish. The energesh is on the other side of one unsparing question, and you already know how to ask those. You’ve been debugging your own assumptions for years.
Bob Matsuoka is CTO of Duetto and writes about AI business trends at AI Power Ranking.
Related reading:
The Tide Has Turned: Senior Developers Are Finally Adopting AI Tools — Why the holdouts changed their minds, and what shifted to make it happen
The Era of the Leader/Practitioner — How AI tools made the hybrid leader-who-builds role viable again
We’ve Turned a Corner — On the shift from skepticism to working practice
AI Power Ranking — Tool comparisons and benchmarks for AI practitioners
LinkedIn Newsletter — Strategic AI insights for CTOs and engineering leaders