This post is to voice my concern about two sides of this war: developers and users/customers!

Concern

I have heard “wartime” used so many times in the past year that, at times, it has become annoying. There are two factors that clearly distinguish these two “eras”: pressure and quality. With the whole AI train rocket, the pressure and speed in the industry have never been higher; therefore, we are in “wartime”.

“Wartime” is nothing new to us; it has been around for years, but the very important difference is the “length” of the war we are in. In my career, I have been in many wartime scenarios, or what we usually call Sev0 issues. Whether it is security or reliability, you pick. People who know me know that I love when the pressure is on. When the shit hits the fan, I like to be the one in the front row with an umbrella. All those “war” instances were just that: instances that lasted from a couple of hours to a couple of days. The lesson we can take from these instances is that we humans are not great at wars, or at least most of us are not. For these cases, we have built processes over the years, like incident handbooks, and we have dedicated roles like incident managers, commanders, and responders. If your workplace is mature enough, you even do drills and planned restores to be ready for “wartime”.

Hopefully, you see where I am going with this. As the trend has been to use parallels, examples, and quotes when trying to explain AI, I will lean into that. Let me use the same language that top-level people do. So, let’s start with this:

"There is no instance of a country having benefited from prolonged warfare."

Sun Tzu

My concern that resonates with the quote above is how long people are able to keep up with this ~war~ pressure. It looks like everyone has forgotten the most talked-about subject in our industry, “burnout”. Well, let’s get this straight: AI and wartime aren’t helping. On the contrary, they are heavily impacting people, including people I know and work with.

We need to think about how to protect ourselves but also stop losing core skills! I will try to talk about this below.

At work, I optimize purely for people (the team) and customers. Everything I do, every idea I have, I project through the customer experience: how would this improve their experience? What would our customers want?

AI can be helpful in gathering this evidence, helping you understand the common UX practices that you might not be aware of. Most people don’t regularly follow NN/Group. Well, AI can summarize things for you; it can push you in the right direction. But remember, we are in wartime, so speeeeeddddddd…

This leads us to the beautiful term “enshittification,” coined by Cory Doctorow, which perfectly fits the direction we are headed.

A few months back, Spotify VP of Engineering Niklas Gustavsson was talking to Boris Cherny, head of Claude Code, and the highlight of that talk was:

Spotify ships 4,500 production deploys a day, and 73% of PRs are now AI-assisted.

You can read the thread on X yourself: https://xcancel.com/ClaudeDevs/status/2071671418245492926

But the more interesting part is that, if you analyze the replies, you will get one very clear signal: “What user value did you ship?”

Deploying for the sake of a metric, or simply speeding up and amplifying the number of things that get released, is useless if it is not built on a proper foundation, and speed isn’t allowing that.

Finally, to end this section with a comparison example:

You can’t have everything; you must compromise. Sports cars are fast, low to the ground, and can corner unrealistically, but they come with a compromise in comfort. Take a sports car as your daily driver on roads with bumps, and you will throw your back out.

De-skilling

So what do you do? You offload the PR review to AI, you offload the code writing to AI, and you offload the decision making to AI, all for the sake of being able to keep up with whatever metric you have at work. This is what I call AI de-skilling!

Interestingly, I found this term in a very recent podcast I listened to. As people who know me know, I love psychology and people, so I listen to the Speaking of Psychology podcast. Recently, there was this awesome episode, AI ‘de-skilling’: What happens when we offload our work to AI? With Brooke Macnamara, PhD. I love this podcast because it is very data- and scientifically driven. It is not an angry developer behind a keyboard mashing away their frustration.

What you will hear in that podcast is what I already knew and had personally felt, but I loved seeing the studies behind it:

• Skills Can Decay With Over-Reliance on AI
  • Evidence from endoscopists and medical professionals: skills decline when AI is heavily relied upon
  • Medical skills decay by ~50% after just 6 months of disuse
  • Workers may not notice their own skill decline due to AI compensating for them
• Novices vs. Experts Affected Differently
  • Novices: Most vulnerable; using AI while learning new skills significantly reduces learning depth
  • Experts: More resilient; established skills decay more slowly, but are still at risk with prolonged disuse
• Broader Societal Concerns
  • People give up faster on difficult tasks when AI is available (reduced persistence)
  • Potential shift toward expecting immediate results, reducing tolerance for struggle
  • Risk of reduced critical thinking if AI does synthesis work for us
• How You Use AI Matters More Than Using It

I encourage you to watch this episode of the podcast :)

Where to now

We are where we are. We were put into a war. The question is: how do we make the best of it and hopefully not burn out in the process? What I found very interesting and funny is that you can read a lot of different books about peacetime management and productivity, but not about wartime. One rare example is The Hard Thing About Hard Things, published in 2014 by Ben Horowitz, co-founder of the venture capital firm Andreessen Horowitz, but again, books like it are rare.

As always, there isn’t a formula or a clear checklist of things, but let me try to guide you on how to stay relevant and not get sucked into enshittification.

I like to reflect on the past as a learning opportunity. I think that people did a lot of things correctly, and we can learn from them, but we can also learn from the mistakes. In this case, I remember when I was starting out about 15 years ago. Books were the way to learn, but you would have to buy new editions every single year to stay up to date. Then open source became this very great thing that everyone started using; you could go and read code written by multiple experts and learn. I remember reading and learning about PHP by looking at Symfony. The question is: would this be a practical time investment? I would say yes, if you are able to understand the reasoning behind it, because you start to build patterns for how to solve certain types of problems.

Nowadays, people don’t have time for that. I am very sad about new people coming into the industry or junior folks already in this war, as today’s expectation is to read and evaluate a lot more code as fast as possible. The even scarier part is that the code:

• might be hallucinating
• might be using patterns (you don’t know about)
• might be using anti-patterns (you don’t know about)
• might be relying on runtime-specific behavior

There are two options here:

• Expensive: Try to understand everything, but again, if you are new, that is going to be hard. It will take time, and you will be overwhelmed.
• Cheap: Just YOLO and push the code. This is how we get AI slop and create problems for users and other developers.

I would say the ideal solution is finding the middle ground, and that comes with answering a few important questions: “What matters to me?” and “What skills do I want to build?” Another way to think about this is to think about your career as an RPG game, where you have a certain number of tokens to spend on certain skills and decide how you invest them.

Build your engineering class

10 skill + 5 AI tokens

Skill 2 left

AI 5 left

Skill

AI

Retained skill AI leverage

Technical judgment Architecture, debugging, trade-offs

Skill

−

2

+

AI

−

0

+

Product judgment Discovery, UX, customer value

Skill

−

2

+

AI

−

0

+

Security & reliability Threats, resilience, operations

Skill

−

2

+

AI

−

0

+

Delivery automation Tooling, workflows, leverage

Skill

−

2

+

AI

−

0

+

Engineering generalist Keeps several skills active without making one the entire identity.

Reset build

With that in mind, prioritize skill maintenance for tasks that matter to your career. If you don’t care about building a select-search component, offload it to AI, but learn from it. If you care about security, build the upload feature and try to protect it from XSS, CSRF, RCE, DoS, or any other attacks.

Don’t rely on AI for every routine task. Engage. You lead; let it follow. Another way I like to put it, which is very simple, is to treat it as an intern. Imagine you have 10, 50, or 100 interns at your fingertips, but remember, they are interns. You ask the next questions; don’t let it guide you on what to ask. The main takeaway is: don’t lose critical thinking or offload it to AI. AI can code faster than you, but it can’t think better.

When you get an output, literally interrogate it: why did it do it that way? What did it take into consideration? What other alternatives did it consider? Make it guide you through the code the same way an intern or interview candidate would.

In the end, AI should be a support system, not a substitution. Use it as a rubber duck; let it prototype things for you so you can come to the right answers faster. In the last year, I have built 50+ prototypes for educational or scientific purposes because it is super easy and simple. I love it.

This is an important chapter I want to cover and one of the inspirations for this post. After talking to a lot of people, “fatigue” is the word that comes up a lot. Remember, AI brings an insane level of capability. As I framed it above, it is like having a bunch of interns, but it comes with the same strain as managing them. Can you manage 100 interns? Likely not.

Our everyday lives are changing, meaning that we have to parallelize a lot because AI is not instant. It thinks, and it takes time to produce results. I am fortunate enough to have unlimited AI usage, so I have five or six instances running on multiple development machines. This is great: I am fast, but keeping track of the context and “fighting them” drains my energy. Remember, fighting them is key, as I am trying to understand what they did while also challenging their reasoning and usually explaining why it isn’t right or the best approach.

What I have noticed, both from talking to people and reading online, is that no one is finishing their workday sooner, and no one is less stressed because their job suddenly became easy. Most of us feel exhausted. We feel the fatigue.

Leadership

AI fatigue is not an individual resilience problem. Leadership creates the conditions that turn AI into leverage or overload. For this final and hardest chapter, talk to your leadership or send them this blog post if what I wrote resonates with you.

The message that should get to leadership is that being in wartime will take a toll on the product and the people. You cannot control the pressure across the industry, but you can control whether every sprint inside your company feels like an incident. The way the war is fought can mitigate some of its effects.

AI adoption cannot be measured by commits, LOC, PRs, deployments, features, or tasks alone. Those are activity metrics. They need to be considered alongside customer outcomes, defects and incidents, rework and review time, developer satisfaction, fatigue, and retained skills.

Leadership should use AI to:

• Offload bounded and verifiable toil, especially maintenance, legacy work, and repetitive tasks.
• Avoid turning every saved hour into additional workload.
• Invest reclaimed capacity in product discovery, proofs of concept, learning, quality, and work outside people’s usual areas.
• Keep people accountable for decisions and outcomes, even when AI produced the work.

Speed by itself creates no value. Offloading work that drains people so they can do their best with the support of AI is a much more meaningful goal.

My personal example is this: with AI, I was able to onboard more quickly as a consultant on a bigger project. I could ask it questions like, “Where is this functionality?” and get to work faster. I don’t care or want to spend my time digging through the legacy code if I don’t have to. I want to focus on solving the problem.

Another example: AI has enabled me to automate things for which I was always too lazy to write a script or research how to do something in Power Automate or Automator on macOS. Now I can have a chat with AI, and it can do it in a few minutes.

Final example: recently, I wanted to play GTA IV again but kept delaying it because I wanted to install a bunch of mods first. Then I remembered I have AI. I downloaded the mods, told it to install them, launch the game, check whether it crashed, and iterate until it worked. I went to have breakfast and returned to a working game. It was the smallest and stupidest use, but it meant a lot to me because I did not have to go through that annoyance.

These examples have something in common: the work was annoying, bounded, and easy to verify. That is where AI gives me the most value.

The leadership question should not be, “How much faster did AI make us?” It should be, “What valuable work did AI remove, and what did we do with the capacity it returned?” If the answer is simply “more work,” we have not reduced the burden. We have only increased the pace.

What is AI?

Finally, to end this with an analogy, as that seems to be the trend:

AI is a flamethrower; you can burn through a lot of stuff, but you can’t control the outcome.