AI Isn't Replacing Engineers. It's Changing What Engineering Feels Like.

This post started with a conversation. A client of mine, an engineer, was describing his workday, and what he said made me raise an eyebrow. The work was going fine. Better than fine, actually. And, somehow, he was coming home drained, irritable, and kind of discontent.

He said "I just want it to work and be done with it." No joy in the problem-solving like a few years ago. No excitement in figuring out a complex scenario. Just annoyance, and a vague sense that his brain isn't working the same anymore.

The loud fear about AI is that it takes jobs. But I think something quieter is happening first, and it's worth naming: AI isn't necessarily eliminating engineering jobs. It's changing what engineers do all day.

That might sound like a small distinction. It isn't. You can keep your title, your salary, your responsibilities, and your accountability for outcomes. Yet, you spend a lot less time doing the thing that made you an engineer in the first place. The work gets faster. It might even get more productive. And somewhere in there, it can quietly become less satisfying, less engaging and, strangely enough, more exhausting.

So the question isn't really whether AI can do engineering work. The more interesting question is what happens to engineers when AI starts doing the thinking that used to make them engineers.

The job is changing underneath the job title

Think about what solving a hard problem used to involve. You'd sit with something you didn't understand. Break it down. Form a hypothesis. Write the code. Watch it fail. Trace the failure, rebuild your model, and try again. Somewhere in that loop, you learned something, and not just about the problem. Every difficult problem added to your pattern recognition, your technical depth, your judgment, your sense for where a system was likely to break.

Now compare that to a workflow a lot of engineers are living in: prompt, generate, review, correct, test, approve. The engineer is still responsible for the result. But their relationship to the problem has changed. They're directing, evaluating, and correcting work produced by another system. One way to describe it: managing an extremely fast junior engineer who never sleeps — and who can produce hundreds of lines of code in seconds while being occasionally, confidently wrong.

That changes the cognitive demands of the job. And, possibly more importantly, it changes the psychological experience of the job, too.

Offloading isn't new. But what we're offloading might be.

There's nothing wrong with cognitive offloading. Humans have done it forever — calculators instead of arithmetic, GPS instead of memorized routes, spellcheck instead of spelling rules. Moving mental work outside your head frees you to spend limited cognitive resources elsewhere. That's just being smart.

The problem isn't offloading. The problem is what we're offloading. The cognitive activities that serve our identity aren't just tasks to complete. They're also how we develop and maintain expertise. Research on automation has flagged this concern for years: when external systems take over cognitive work, people get fewer opportunities to practice the underlying skills. Recent work on AI raises the same worry about skill acquisition and skill decay as offloading becomes extensive.

It the cognitive version of skipping the gym for weeks. The strongest man in the world only stays the strongest man if he is lifting every day.

And that's where engineering gets interesting.

What if we're offloading the practice, not just the work?

Imagine an engineer who uses AI to generate a routine function. Probably fine. She understands what the function needs to do, evaluates the output, tests it, moves on. That's augmentation.

Now imagine an engineer who routinely asks AI to decompose the problem, propose the architecture, write the implementation, find the bug, explain the bug, generate the tests, refactor, and document the system. She's still involved. But she's practicing a different set of skills: instruction, evaluation, oversight AND still practicing much less of the underlying cognitive work.

Technical expertise isn't providing an answer to your boss. It's knowing how to arrive at one. It's sensing that something is wrong before you can articulate why. It's reasoning from first principles, debugging something you don't understand yet, holding a complicated problem in your head long enough to see the structure underneath it.

Those abilities don't come from reading about problem-solving. They come from solving problems. And you can't repeatedly outsource the practice of a skill without at least asking what happens to that skill over time.

The competence paradox

Here's the strange part: AI can make an engineer more productive while making her less independently capable. Those aren't mutually exclusive. More tickets closed this month than ever. Faster completion. More code. And if the AI disappeared tomorrow, certain skills would turn out to be rusty.

This isn't hypothetical, and it isn't unique to AI. Automation research has long documented automation bias and complacency — people becoming overly reliant on automated systems and less attentive to their errors. Generative AI adds a new dimension, because the system isn't just making decisions for us. It generates the work itself.

Which means the thing being offloaded can be the very thing that builds competence.

Faster doesn't always mean better

There's real evidence that AI coding assistants increase productivity — a set of randomized field experiments with 4,867 developers at Microsoft, Accenture, and a Fortune 100 company found a substantial increase in completed tasks. That matters. AI is genuinely useful.

But productivity is one dimension of work. The other question is what kind of work gets left behind for the human: review it, validate it, debug it, integrate it, monitor it, fix what it misunderstood and, of course, take responsibility when it fails. One recent analysis of open-source projects found increased rework after Copilot adoption, with more of that review burden falling on experienced developers.

In other words, the work didn't disappear. It moved.

Moving the work changes the experience of the work

This is where the conversation about AI and burnout gets more complicated than we usually let it.

We tend to assume burnout comes from too much effort. Sometimes it does. But people also burn out when work is demanding without being rewarding, when accountability is high but autonomy is low, when effort stops producing a sense of mastery, or the work loses its connection to the reasons someone entered the profession in the first place.

Engineering always carried a powerful built-in reward: I solved something difficult. There's real satisfaction in wrestling with a problem that doesn't make sense until it suddenly does. In finding the bug. In realizing the mental model you built was right.

AI can make some of those things easier. But easier isn't the same as more satisfying. When the difficult, nourishing part of the work migrates to the machine, the human inherits what's left — supervision, correction, administration. The engineer becomes more productive and, quite possibly, less engaged.

There's a job title for that, by the way. It's called middle management, and plenty of people burn out in it.

The junior engineer problem

There's another issue that might be even more consequential: how do you become an expert at something when the struggle that builds expertise is increasingly automated?

Senior engineers have years of accumulated mental models. They know what "normal" looks like. They've watched systems fail, made mistakes, debugged bizarre problems at 2 a.m., designed things that turned out to be terrible — and learned from all of it. That experience gives them something AI can't simply hand over: judgment.

Junior engineers are still building those internal models. If AI consistently hands them the answer before they've had to struggle with the problem, they may get very good at using AI before they get very good at engineering. That's a fundamentally different apprenticeship. And it raises an uncomfortable question: what happens to the next generation of senior engineers if they never got enough practice being junior engineers?

Responsibility without mastery

This may be the part worth paying the most attention to.

Imagine being responsible for a system you didn't fully build. Approving code you didn't write. Debugging behavior produced by a system you don't completely understand. Maintaining software generated at a speed no human could inspect line by line — and remaining accountable when it fails.

That's high responsibility, reduced authorship, reduced mastery, and increased oversight, all at once. That's not a recipe for engagement. It's a recipe for a very particular kind of exhaustion — the kind my clients describe when they say they were busy all day and can't point to a single thing they actually *did*.

Recent research on GenAI adoption and developer burnout is starting to explore exactly this: AI adoption adds job demands even while it also provides job resources.

So the story isn't "AI good" or "AI bad." It's that AI changes the demands of the job but we haven't redesigned the job around those new demands.

So should engineers stop using AI?

No. That would be the wrong conclusion, and I'm not writing an anti-AI piece. AI removes tedious work, helps people get unstuck, accelerates experimentation, and can make engineers dramatically more productive in the right circumstances.

The question isn't whether to use it. The question is what you keep practicing yourself.

Maybe engineers don't need to write every line of code anymore. But they still need real opportunities to reason from first principles, debug without assistance, design systems, decompose ambiguous problems, predict failure, understand the architecture beneath the abstraction, and recognize when the AI is wrong. Those aren't merely tasks. They're cognitive muscles, and muscles respond to use or the loss of it.

The goal isn't to preserve the old job

Engineering is going to change. It should. Nobody needs humans doing work machines do better and faster.

But there's a difference between automating a task and automating the development of the person performing the task. That distinction is going to matter more and more. The future of engineering shouldn't be humans competing with AI at writing code — it should be a new division of labor, where AI handles what machines are good at and humans keep developing the judgment needed to supervise, challenge, and take responsibility for those systems.

Because the real risk isn't that AI makes engineers obsolete. It's that we make engineers less practiced at engineering — and then discover the humans responsible for the systems have come to depend on the systems to do the thinking.

The goal isn't to keep engineers doing work AI can do.

The goal is to make sure AI doesn't take away the work that makes engineers engineers.

If you are interested in exploring how neuroscience, stress physiology, and practical tools can help you build resilience without burning yourself out Learn more about Pulse Steady or schedule a consultation.

For the people who hold everything together and need a place to fall apart.— Coaching with Casey Becker