Menlo’s Deedy Das says AI coding creates an identity crisis bordering on depression

Menlo Ventures partner Deedy Das is warning that AI coding tools are doing more than speed up software development. In an X post over the weekend, Das said “Most software engineers are facing an identity crisis bordering on depression,” and he pinned the problem on a new split inside teams. He describes some engineers as “lazy,” relying heavily on AI to write code and answer questions, while “craftsmen” are the ones who must review and fix the flood of AI-generated work.

Why this matters right now: as companies push developers to use AI coding tools to boost productivity, the bottleneck often does not move. Das’s core claim is that review, understanding, and maintenance become the job, and the people doing that work are burning out. In his words, “The craft they loved is dead,” and “The entire burden of review falls on the craftsman. The burden of understanding.”

This is part of a bigger conversation Business Insider has framed as “AI sprawl.” The idea is straightforward: workers may end up juggling multiple AI tools, duplicating effort, and generating ever-increasing volumes of output without clear evidence that companies are becoming substantially more effective. In engineering terms, more generated code is not the same as better software. If AI spawns more pull requests, more suggested changes, and more variations, then the process that turns “suggestions” into reliable production systems gets heavier. Das’s comments point to review capacity as the choke point, not code-writing throughput.

The “botsitting” angle he references is also telling. If AI makes it easier to generate code, teams still need humans to supervise it: validate it, debug it, and confirm it behaves correctly in the real world. Das says that as AI-generated output rises faster than teams can evaluate it, some engineers end up buried under pull requests while bugs slip into production. That is the second-order trap. Even if AI reduces the time to draft code, it can increase the total volume of work that must be checked, because the marginal cost of generating another attempt is low.

Das also ties the dynamic to where talent variance is highest. He said this tension is common at large organizations that are 10+ years old with a higher talent variance, but that “it happens. A lot.” The organizational implication is that AI integration is not just a tooling decision. It changes team roles and risk distribution. When some engineers lean harder on AI generation, the review and accountability often concentrate elsewhere. That means the process can quietly reassign who carries the burden of correctness. In a healthy system, review is about ensuring quality, learning, and shared standards. In a stressed system, review becomes a backlog tax that drains the people least responsible for the code volume.

To be fair to the other side of the debate, Das also says many companies are successfully integrating AI into software development. His point is narrower: the conflict is especially common where AI-generated output grows faster than evaluation capacity. Put differently, the promise of AI is that it accelerates work. The threat, in his telling, is that it accelerates work that still requires human judgment at scale. If teams do not redesign review processes, staffing, and workflows accordingly, they can create a situation where “productivity gains” are really just output inflation.

For boards, investors, and operating leaders, the strategic stakes are bigger than one team’s morale. This is about how software companies measure productivity, how engineering work gets valued, and how AI investment translates into business outcomes. If review becomes the new bottleneck, companies may find that the limiting factor is not developer headcount but senior judgment capacity and process throughput. Meanwhile, engineers who feel their “life’s skill is no longer useful” may disengage, churn, or push back on adoption, which can undermine the very productivity story leadership is trying to sell. Das’s warning is essentially a risk statement: without careful implementation, AI coding can turn into a quality and workforce strain problem, not just a speed upgrade.

Das’s description ends up being a governance question as much as a technology question. When AI generates more code, who owns correctness? Who has time to understand changes deeply? How do companies prevent “lazy” habits from externalizing risk onto “craftsmen”? Those are the questions that determine whether AI coding tools improve outcomes or just reorder the suffering across an organization.