Automation Changes When You Need Expertise. It Doesn’t Eliminate It

Yesterday cost me an entire day, and it got me thinking about something that may become a much bigger problem over the next ten years.

I have a developer working on a Dynamics 365 Finance & Supply Chain Management (F&SCM) project. He needed fresh data in his development box. In newer environments, that’s easy. You push a button, wait a bit, and you’re back to work. He’s never had to do it any other way.

Unfortunately, we’re not on that version. So we did it the old way.

Since the developer was still actively working, I didn’t want to stop what he was doing. Instead, I pulled a BACPAC down to my development box so I could investigate the issue without interrupting his work.

I pruned out a bunch of archive tables, ran SQLPackage, took a SQL backup from that, uploaded it to the LCS Asset Library, had him pull it down, restore it, shut down the existing database, rename everything, and get the environment pointed at the new database.

Then he opened Visual Studio and ran database sync. It failed. And that’s where things stopped. Not because he’s not good. He’s very good.

The problem was that he’d never had to go underneath the abstraction before. The button had always worked. When it didn’t, there wasn’t a mental model to fall back on.

I ended up tracing the issue and getting it fixed. The only reason I could do that was because I’ve spent the better part of twenty years doing this stuff the hard way.

One lost day. Good project. Good developer. Nobody did anything wrong.

The Part That Nagged at Me

Driving home, I kept thinking that I’d seen this idea before. Not in a blog post. Not in a YouTube video. In college.

After a little digging, I found it again.

*Ironies of Automation* by Lisanne Bainbridge, published in *Automatica* in 1983.

Five pages. I remember reading it sometime in the late eighties, and I probably hadn’t thought about it in thirty years. Her argument was simple.

When you automate a process, you don’t eliminate the human operator. You leave them with the parts that couldn’t be automated, which tend to be the hardest parts of the job. At the same time, the automation takes over the routine work that used to build experience and intuition.

So when the system finally breaks, two things are true at once.

1. The problem is difficult because that’s why the automation failed.
2. And the person being asked to fix it has had fewer opportunities to develop the skills needed to solve it.

What stuck with me all these years was Bainbridge’s conclusion:

 **The operator of an automated system needs more skill, not less.**

Read that again and tell me it doesn’t describe what happened yesterday.

Now Stop and Think About This

What struck me later is that the paper itself actually proves the point. I couldn’t remember the title. I couldn’t remember the author.

I couldn’t even remember where I had read it. What I remembered was that a paper like that existed. That was enough. A few searches later, I found it. AI probably would have found it even faster.

But I had to know there was something worth looking for in the first place.

That’s what education, experience, and years in the industry give you. Not necessarily the answer. They give you the category. They tell you:

 *”I’ve seen something like this before. Somebody has probably studied it.”*

My developer never would have searched for that paper. Not because he’s incapable, but because nothing in his experience suggested this was a known phenomenon rather than just an annoying afternoon.

That’s the part of the AI conversation I think gets missed. AI is amazing at retrieval. It’s very good at answering questions. What it doesn’t do, at least not yet, is tell you which questions are worth asking. Most of the time, that still comes from experience.

The Ten-Year Question

Here’s the part I keep coming back to. The people who know how to go underneath the abstraction are mostly somewhere between 45 and 65 years old. We learned this stuff because we had no choice. The plumbing wasn’t hidden from us. It was the job.

Today’s developers aren’t getting the same exposure. They’re using better tools, faster platforms, and higher-level abstractions. Honestly, that’s a good thing most of the time. But it does create a problem. When the abstraction breaks, who’s left that knows what’s underneath?

In ERP consulting, I see this everywhere. The user experience gets smoother every year. The infrastructure underneath often hasn’t changed nearly as much. Six inches below a modern interface is frequently the same database engine, integration pattern, or platform behavior that’s been there for over a decade.

When something goes wrong, experience still matters.

So when my generation retires, who’s doing that work?

Maybe AI fills some of the gap. Maybe it becomes good enough to walk people through every failure scenario. It might. But that’s a bet, not a strategy. And a lot of companies are making that bet without realizing they’re making it. The real question isn’t whether AI can replace expertise.

The question is where the next generation is going to get that expertise if the systems they’re working on rarely force them to build it in the first place.

For those interested, the paper is **Ironies of Automation** by Lisanne Bainbridge. It was published in 1983, and it’s remarkable how relevant it still feels today.