Engineers grieve a job that no longer exists

Estimated reading time: 7 minutes

Key takeaways:

• Engineers are resigning over identity, not workload.
• The “craftsmen” struggling most are early adopters.
• Standard metrics miss the hardest, least visible work entirely.

---

Something is happening in engineering teams that doesn’t show up in sprint velocity or deployment frequency. It shows up in resignation letters.

Annie Vella, an engineering leader and researcher who recently completed a Master’s thesis on AI-coding assistants’ impact on software engineering, says she’s had multiple conversations with engineers questioning their career choice altogether.

At one company, several engineers resigned at the same time: some hoping the role would eventually return to what it was, others leaving the industry entirely.

“I’ve seen a sharp rise in the number of very honest, personal accounts of how engineers are feeling on social media,” Vella says. “For many, the shift towards more managerial and verification-focused activities, like orchestrating agents and code review, is turning the role into something they simply don’t enjoy as much.”

The identity problem

Engineers are turning to Vella because she recognized the problem in her widely discussed essay, The Software Engineering Identity Crisis. Software engineers have historically defined themselves through the act of building, she wrote.

“Many of us became software engineers because we found our identity in building things. Not managing things. Not overseeing things. Building things. With our own hands, our own minds, our own code.”

AI-coding assistants aren’t just changing how engineers write software – they’re fundamentally transforming who they are, she adds. “We’re shifting from creators to orchestrators, from builders to overseers. From engineers to something that looks suspiciously like… managers.”

Vella’s research found that 77% of engineers report spending less time writing code, with nearly half concerned that their core skills might become secondary to prompting AI tools. She calls that the transition from crafting solutions to crafting prompts.

For years, the industry pushed engineers toward ever-narrower specialization, delegating requirements, design, and testing to separate roles so that engineers could focus on code. Now AI threatens that very specialization. Engineers who were told to be expert coders are being asked to become expert reviewers, agent orchestrators, and AI supervisors.

“I’m moving fast, but losing my passion”

Those who chose software engineering because they found joy in solving problems themselves, reasoning it out, and writing the code by hand are having the hardest time adjusting.

A recent study by researchers at Oregon State University surveyed 442 professional developers across 56 organizations and modeled how generative AI adoption affects burnout using the Job Demands–Resources framework. Their findings show that AI-related job demands, particularly workload intensification and organizational pressure, significantly increase burnout.

One developer in the study expressed the paradox: “I move fast with AI and move mountains of work, but I am losing my passion for the work.”

The study found no significant correlation between burnout and role, seniority, or company size, suggesting that the phenomenon is widespread rather than concentrated among a particular group.

Why leaders hesitate to address the problem

Engineering leaders recognize the problem but are hesitant to address it. Nearly a quarter of the study participants reported receiving no meaningful organizational support for learning how to work with AI tools, despite being expected to use them daily.

Vella says introducing AI tools into engineering organizations without addressing their impact is  one of the most common patterns she encounters in her conversations with leaders.

“Many leaders I’ve spoken to are hesitant to start the conversation because they don’t know what the work is becoming yet,” she tells LeadDev. “My argument is that we may not ‘know’ for a long time until things settle down a bit, but our people are already feeling the impacts today.”

Her case for acting now rather than waiting is practical. If leaders and their teams talk about how the work is evolving while it’s still changing, they stand a chance of steering the direction it goes. The alternative is having the change done to them by people who don’t understand the work at all, whether that’s executives chasing productivity metrics, vendors selling tool adoption, or consultants who’ve never shipped production code.

“I believe strongly that this is actually what good leadership demands,” Vella says. “The courage to have the hard conversation, even when it’s ambiguous or uncomfortable. We don’t need to have all the answers, but we do need to create the space to ask difficult questions and discuss options.”

The Oregon State study found that resources and support, specifically autonomy over how AI is used and genuine learning opportunities, significantly reduce burnout. Mandating adoption without giving engineers a say in how it’s integrated into their workflow is one of the fastest ways to accelerate burnout.

There is no single fix

Vella warns leaders against looking for a single, team-wide solution. AI burnout is not one problem; it is several distinct problems that happen to produce the same visible outcome of disengagement and attrition.

“Try to uncover what specifically it is making engineers feel that way,” she advises. “Is it the pressure to deliver faster, the loss of comprehension of what they’re building, being made to feel accountable for something they barely understand, spending more time reviewing than creating, the anxiety of layoffs, wondering what their value is now? Each of these has a different solution.”

When leaders are hearing this from several people on their teams, the signal is systemic. Vella suggests they think about how to change their system of work to provide better support. 

For engineers who are already past the point of adjustment, those actively looking for a way out, Vella recommends more deliberate, one-on-one conversations. The goal isn’t to convince anyone to stay. It’s to diagnose the specific source of frustration and, where possible, address it. Sometimes it means helping someone find a better fit, inside or outside the organization.

The craftsmen are not resisting AI

It’s worth noting that the engineers struggling most with this transition are not, by and large, opposed to AI tools. Many of them were early adopters. These are not engineers clinging to the old ways. These are engineers who care deeply about the quality of the work and are watching the standards shift underneath them.

Deedy Das, former engineer and tech lead at Google and Meta turned VC, described them as the craftsmen.

“The lazy push code. They don’t write it. They don’t manually test it. They don’t even read it. They’re on autopilot.”

“The craftsmen are tired. Very tired. 15 PRs in queue. Slack blowing up. The entire burden of review falls on the craftsman. The burden of understanding. They try. They work their way through the code, thoughtfully commenting to improve what ships. The response? A lazy: ‘That’s a clever idea! You’re absolutely right.’ with an incorrect change. It’s fine, the craftsman says. I can fix them. They write a doc urging their colleagues to be better. The next day? 20,000 line PR to review. Day after day, their workload grows. Bugs seep into production. No one seems to care. Another round of AI is thrown at it. Their animosity to their colleagues rises. Eventually, they give up. It’s just not what it used to be. The craft they loved is dead.” 

The people burning out are not worried about being replaced. They’re exhausted from being the last line of defense for standards that the rest of the organization has stopped prioritizing.

The hidden labor problem

One reason AI burnout blindsides leaders is that standard engineering metrics don’t capture it. Teams appear to be shipping faster, but the Oregon State researchers point out that performance metrics typically measure speed of output but ignore verification workload. The time engineers spend reviewing, debugging, and validating AI-generated code is invisible labor that doesn’t show up in dashboards but absolutely shows up in how people feel about their jobs.

The more AI-generated code a team produces, the more review work lands on the engineers who care most about quality, often the most experienced people on the team. The volume of output rises while the nature of the work shifts from creation to inspection, and the engineers doing the hardest cognitive labor appear, by the metrics, to be less productive than the ones generating code with AI.

Leaders who want to understand what’s happening on their teams need to start measuring the work that has emerged alongside AI adoption: time spent reviewing AI-generated pull requests, time spent debugging code the engineer didn’t write, time spent verifying behavior they can’t fully trace. Until that labor is visible, it’s impossible to manage fairly.

Leaders, start that conversation!

The question Vella raises is not whether engineering should evolve; it’s whether the evolution is being designed with engineers in mind or merely imposed on them.

“AI offers engineers a chance to return to holistic problem-solving,” she writes, “understanding user needs, business impact, system design, and operations, making them master builders rather than mere code writers.”

However, that optimistic vision only materializes if leaders make space for it. Left unmanaged, the default trajectory is toward a verification-heavy, review-centric role that talented engineers will continue to leave. For engineering leaders, this is not the burnout caused by long hours, tight deadlines, or on-call rotations that they’re used to managing. It is about the nature of the work itself changing faster than people can adapt. 

The engineers who are burning out right now are sending a signal. They’re not saying that change is bad. They’re saying that no one asked them how they wanted the change to go, and no one is asking them now how they’re handling it.

For engineering leaders, the first step is as simple, and as hard, as asking.

Get articles like this in your inbox

Choose your LeadDev newsletters to subscribe to.