Here We Go Again

Tonight at dinner, two worlds collided, and I had an insight.

For years, I resisted network automation.
Not because I thought it was useless. Not because I couldn’t learn it. And not because I believed networks should never evolve.

I resisted network automation because I loved building networks by hand.

I loved crafting configurations line by line. I loved the feeling of expressing intent directly in the CLI. There is an art to artisanally crafting configs by hand. You aren’t just configuring a router; you’re bringing an entire system to life. Routing protocols, redundancy, policy, traffic engineering, security boundaries, and service delivery. It feels like craftsmanship.

Then automation arrived and told us, “Stop doing the fun part manually.” Instead of crafting configurations, we abstracted them away into templates, variables, YAML files, Python scripts, and pipelines.

I understood the argument.
Consistency.
Scale.
Repeatability.
Reduction of human error.
Infrastructure as code.
Intent-based everything.

Cognitively, I understood the benefits.
But emotionally?
It felt like someone was taking my craft away from me.
A craft I worked long and hard to get good at.

Tonight, sitting with a group of network automation practitioners, the conversation shifted toward large language models and AI-generated code. I asked if they were using LLMs to generate code for their automation platforms.

They tensed up.
Their faces grimaced.
They looked at each other, seemingly for permission to be candid, before opening up to me.

“No, we don’t like coding with AI.”

Not because the tools were bad.
Not because the output wasn’t useful.
Not because some are still spooked about hallucinations.
They said, “Writing the code is the fun part.”

They talked about creativity.
About solving problems with their own hard-earned knowledge.
About the satisfaction of building something by hand.
About how generating code with AI removes the most satisfying part of coding.

Then it hit me.
The same reasons I resisted network automation for years are the same reasons developers (and other knowledge workers) resist AI-assisted coding. 

The traditional network engineer says:
“Automation steals the craft of networking.”
The traditional developer says:
“LLMs steal the craft of coding.”

Different professions.
Different tools.
Identical emotional response.

That got me thinking that maybe resistance to technological change isn’t technical at all. Maybe it’s cognitive.

We Don’t Just Protect Jobs. We Protect Identity.

One of the most uncomfortable truths about professional change is that people resist it because their identity is attached to mastery.
A veteran network engineer doesn’t just know BGP.
They became someone through years of learning BGP.

A developer doesn’t just write code.
They derive meaning from the act of problem-solving.

When a new abstraction layer appears, it doesn’t merely threaten workflow efficiency. It threatens the source of competence, pride, creativity, and identity. That’s a much deeper psychological event than most technology conversations acknowledge.

The Endowment Effect of Expertise

Daniel Kahneman’s work on cognitive bias helps explain this. One of his findings is the endowment effect: humans assign more value to things simply because they own them. But ownership is not limited to physical objects.

We become psychologically attached to:
- workflows
- methods
- tools
- expertise
- mental models
- professional rituals

A CLI artisan values manual configuration because years of effort created emotional ownership. A developer values handwritten code because it represents hard-earned capability.

The resistance is not logical. It’s an emotional attachment disguised as a technical preference.

Status Quo Bias Disguised As “Professional Standards”

Another powerful force is status quo bias; our tendency to prefer existing systems simply because they are familiar. What’s fascinating is how often we rationalize this bias as wisdom.

We say:
- “People need to understand fundamentals first.”
- “Automation creates dangerous abstraction.”
- “AI-generated code will create bad engineers.”
- “Nobody should trust black boxes.”

Sometimes those concerns are valid. But sometimes they’re defensive reactions from professionals whose brains associate familiarity with safety.

Humans confuse: “this feels uncomfortable” with “this is wrong.”

From Our Cold, Dead Hands

What struck me most tonight was that both groups, traditional network engineers and automation developers, fear the same thing: The loss of creativity. 

Network engineers fear losing the creativity of designing and crafting networks manually. Developers fear losing the creativity of building software manually.

This common fear reveals something important about people.
We don’t prefer efficiency.
We want agency.
Expression.
Mastery.
Creation.
Identity.

The act of building things by hand matters psychologically.
There is joy in craftsmanship.
There is pride in “I am the expert of the thing.”

Every Generation Thinks Their Layer Was the “Real” Work

History repeats itself.
At one point:
- Assemblers resisted higher-level programming languages.
- Server admins resisted virtualization.
- Virtualization engineers resisted cloud abstractions.
- Network engineers resisted automation.
- Developers resist AI-generated code.

Every generation believes the abstraction layer beneath them was the “real engineering.” I think that’s because every abstraction removes proximity to the underlying craft people originally fell in love with.

The Brain Prefers Familiar Pain Over Unfamiliar Possibility

Cognitive science suggests something more confounding.
Humans are loss-averse. We feel the pain of losing something more intensely than the pleasure of gaining something new.

When new paradigms emerge, we don’t instinctively think “What new possibilities does this create for me?”

We think, “What part of my identity does this take from me?”
That’s not ignorance.
That’s loss aversion, and it keeps us stuck.

The Irony of Technologists Resisting Technology

The funniest part of tonight’s realization was this. I spent years being challenged by automation engineers who believed I was resisting the future. Now, many of those same developers are resisting AI-assisted development for identical psychological reasons.

I’m not here to cast judgment. I get it. I lived it. I still do.

This was never about networking.
Or Python.
Or Ansible.
Or LLMs.

It was always about identity.

Technology changes faster than human psychology does.
Always has.
Always will.

Here’s my ask of you, dear reader. When the next paradigm shift arrives, instead of taking sides, existing in the binary, and arguing about who is right and which path is better, let’s share a knowing smile and say, “Here we go again.”