Back to Blog

AI Stress: The Human Cost of Efficiency

Developer stress in the face of the promise of Artificial Intelligence

March 17, 2026

professional ai humman written ai assited
AI Stress: The Human Cost of Efficiency

We’ve heard it all before: AI is coming to take our jobs, especially software engineers. Whether that’s true or not, the industry is under pressure due to this speculation. I’m not an expert on the subject, nor do I pretend to be, but I’ll try to empirically explain what I call “AI Stress.”

Profit Promises

Maybe it’s just me and the algorithm I’m assigned, but I constantly see posts on Twitter from CEOs and experts predicting that white collar jobs will disappear in 6 to 12 months or that AGI will arrive in less than a year. While many of these posts tend to be sensationalist, or come from top executives often prioritizing shareholder value over workforce stability. This profit at all costs mentality is what fuels the speculation that our roles are obsolete.

The narrative of replacing humans is already appearing in headlines where they mention that a certain percentage of the company was laid off thanks to AI. Although some these cases could be related to bad financial decisions rather than AI efficiency, is easier to blame the AI than admit a failure in the organization. In any case, mass layoffs are a reality.

On the horns of a dilemma

This external pressure traps us in a paradox, as operational workers(SWEs). On the one hand, refusing to use AI is bad, since not meeting efficiency metrics (usually through lines of code generated or open pull requests) makes us look like low performers and therefore candidates for the next round of layoffs.

On the other hand, using AI is also counterproductive. Even if the promise of replacing us is true, the more we use this technology, the more replaceable we become.

AI Guilt: Emotional cost

In less than five years, we’ve gone from fancy autocomplete to agents that can reduce hours of work to minutes. Before AI, implementing a feature, fixing a bug, or refactoring involved hours of understanding the problem, often through reading, sometimes through experimentation, and sometimes through trial and error. And despite the difficulty, there were long moments of zen, moments of focus, what we called “the zone.”

What we used to be proud of doing, these tools now do in a matter of minutes. This leads us to think that perhaps those voices we hear are true: we are replaceable, our value has been reduced to a few tokens. Ultimately, it comes down to guilt: using a tool justifies our future dismissal.

Result: Invisible Burnout

The cumulative result of these factors combined with the inherent stress already existing in the industry due to the high responsibility placed on engineering departments is creating unhappy employees with heavier workloads and less job satisfaction. In the long run: burnout.

Beyond coders: The Strategy

Regardless of the future, we must always adapt. For years we have done so by learning new technologies and new paradigms; however, we have been merely focused on the code. This has to change. Practicing engineering involves much more than just writing code; it implies an understanding of business, human relations, and leadership.

Look at your mentors from years ago, and see where they are now. In the vast majority of cases, they evolved to do more than code, whether they climbed the ladder in management or, even better, in the technical managment area, becoming staff engineers, tech leads, architects, or even CTOs. While these roles involve some technical knowledge, it is not their primary focus. Let’s shift our focus from seeing the trees to seeing the forest.

But how do we apply this mindset to our daily work?

To deal with the guilt dilemma, we must admit it: AI can write decent code, and it can analyze complex codebases. Let’s use it with no remorse, especially since our companies are already pushing us to adopt this tool for efficiency.

So, ask yourself: Where are you less efficient? Where do you feel most drained? We must protect our “zen” moments. By definition, “the zone” occurs when a task is not too easy (boring) and not too complex (overwhelming).

  • If a task is easy or boring: Delegate it entirely to AI. Let the model handle the repetition, you can even use a “dumb” model
  • If a task is too complex: Use the AI to analyze the problem and help you plan the approach.

By mastering this balance, we ensure that we remain engineers, not just coders. We are defining value through judgment and architecture, not just token churn.