The ABCs of AI for Network Engineers: A Conversation Worth Having

I had the pleasure of joining Andy Lapteff and Michael Bushong again on the Art of Network Engineering podcast for what I’d call one of the most important conversations our industry needs to be having right now. The working title was “ABCs of AI,” and honestly, that’s exactly what it was – a ground-level, no-fluff breakdown of where artificial intelligence fits into the life of a network engineer in 2025.

Fair warning: I said some provocative things. I always do. But the intention, as always, is optimism – not doom.

The 70% Problem (& Why It’s Actually an Opportunity)

Let’s start with the number that shocked even me: according to the Network Automation Forum’s 2025 survey, roughly 70% of networks remain unautomated – meaningfully or otherwise. After more than a decade of Ansible, NAPALM, RESTCONF, and Python evangelism, we’re still here.

I used to look at that 70% as a teaching opportunity – a cohort waiting to be upskilled. But I’ve shifted my thinking. The 30% who are automating? They’re not waiting. They’re already layering AI on top of their automation foundations, and that gap is widening fast.

The uncomfortable truth I shared on the show: it’s not AI that will displace network engineers – it’s network engineers using AI who will displace those who aren’t.

That’s not a threat. It’s an invitation.

Why the Low Automation Take Rate? It’s Not Just the Tools.

I think the blame sits roughly in thirds:

1. The tooling itself – Domain-specific languages, multiple flavors of YANG models, the friction of learning NETCONF alongside everything else. We made it hard.
2. The cultural mindset – Asking a network engineer to become a proficient programmer and put production on the line with code they’re not comfortable writing is a big ask. It takes years to get comfortable with Git, VS Code, CI/CD pipelines.
3. Organizational will – How many enterprises have actually drawn a line in the sand and said “everything after this date gets automated”? Not enough.

Michael made a point I thought was spot-on: networks are fragile because we don’t touch them. It becomes a self-fulfilling prophecy. Draconian change windows, blackout periods running from Thanksgiving to February – that’s not a tool problem. That’s fear. And tools can’t fix fear.

But here’s the flip side: AI is what allows us to cope with the exponential growth in traffic, devices, and complexity.

The alternative – managing four times the infrastructure with the same headcount and no automation – sounds far worse to me than learning a new tool.

Where AI Actually Fits: Start with Read-Only

Here’s my honest advice for the 70% who feel like they’ve hit a wall:

Don’t start with configuration management. Start with read-only.

• Dump your show logging output into Claude or ChatGPT and ask it to summarize what’s happening. Humans have never been good at parsing logs – AI is exceptional at it.
• Ask it to compare your intended config against what’s actually deployed. It’s great at text deltas.
• Use it for compliance checks.
• Use it to generate and run BGP health tests dynamically – not handwritten deterministic tests, but tests the agent creates on the fly and then evaluates itself.

The key mental shift is this: start with the human in the loop. Have the AI prompt you – “Is this the config you want to deploy?” – before it touches anything. Build trust incrementally.

MCP: The Protocol That Changes Everything

I keep coming back to Model Context Protocol (MCP) because I genuinely believe it’s as significant to AI as SMTP was to email or HTTP was to the web.

MCP is a client-server protocol that lets you wrap anything – a REST API call, a Python script, a database query, a show command – and present it to an AI agent as a callable tool. It’s JSON-RPC under the hood. Simple, powerful, and growing fast. Last I checked, there were over 17,000 MCP servers in the wild.

Some examples I find compelling for network engineers:

• RFC MCP Server – Plug this into your agent and ask it to help you write OSPF configs. It will reference the actual RFC. No hallucination. No guessing. It literally reads the standard.
• PITS MCP – I built one of these. Ask the agent to test interface health, and it dynamically generates the right show commands, runs them, and evaluates the results. Truly autonomous.
• NetBox / Nautobot MCP – This is my recommended “Hello World” for anyone getting started. Connect it to Claude Desktop or Copilot, point it at the demo environment (not production!), issue yourself an API key, and start asking questions in plain English: “How many circuits do I have in Atlanta? What IPs are free in this subnet?” That moment – when you’re having a conversation with your source of truth – is when the bit flips.

The Hello World You Should Actually Do

Here’s the concrete starting point I gave on the show:

1. Get Claude Desktop, Copilot, or ChatGPT – Pick one. Claude Desktop is Anthropic’s chat interface, similar to ChatGPT or Gemini. If you’re worried about privacy or cost, start with Ollama locally – free, private, runs on your Mac or even a Raspberry Pi.
2. Go to demo.netbox.dev or the Nautobot sandbox – Don’t touch production. Ever.
3. Issue yourself an API key.
4. Use AI to help you install the MCP. Paste the GitHub link into Claude and say: “Help me install this. I’m a network engineer, not a programmer. I’ve never worked with JSON before.” Let the AI guide you through connecting your first MCP.
5. Start asking questions in natural language.

That’s it. You don’t need to be a programmer. You don’t need to know Python. You need curiosity and about an hour.

Once you’ve done that? Add a ServiceNow MCP. Pull a ticket, read it, address the issue via another MCP, send a Slack, fire off an email – all from a single natural language prompt. The compounding effect is remarkable.

The Agent Is an HR Problem, Not a Tech Problem

One reframe I offered that I think resonates: the AI agent question is fundamentally an HR problem.

How do we incorporate agents into an org chart with closed guardrails and defined permissions? At my company, we have 200 people. If every one of us builds five agents, we’ve effectively grown our workforce significantly – without adding headcount. That’s not replacement. That’s leverage.

The guardrails matter enormously, and this is where senior network engineering knowledge is irreplaceable. Who else knows to tell the agent: don’t update the enable secret, don’t add an ACL that locks me out, don’t touch the management interface? That institutional knowledge has to be encoded into how agents are built and constrained.

Expertise doesn’t become obsolete – it becomes the foundation on which good agents are built.

The Lottery Ticket Analogy

Michael used an analogy I want to close with because it’s exactly right. Early adopters of network programmability weren’t displaced – they were elevated. Every time I automated myself out of a job, my leadership asked: “What else can you automate?” I was never once shown the door for making the team more efficient.

The same dynamic applies here. Build Andy’s Agent. Make it the thing your team talks to for IP questions, circuit counts, site details. You just created value that can’t be outsourced. You purchased a lottery ticket – and unlike actual lottery tickets, the more of these you buy, the better your odds.

The train is moving. It’s easier to board now than later.

What’s Next

Andy and I are planning a follow-up session – a live “Hello World” demo where we build the NetBox MCP agent from scratch, on camera, and yes, we’ll use the WordPress MCP to auto-publish the blog post at the end. If you want to see it go from zero to running in real time, stay tuned.

In the meantime: pick up a tool. Start small. Stay curious.

The networks aren’t going to manage themselves – but with the right agents, they just might get a lot closer.

You can watch my full conversation with Andy and Mike below or on-demand here.

Not sure where to start? The VibeOps Forum is where we’re gathering right now: Jump into the conversation →