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.

AI Tools for Network Engineers: Practical Shortlist

The best AI tools for network engineers fall into three categories: local models that run on your own hardware, commercial chat interfaces that connect to cloud models, and AI-assisted coding environments. Here is what each contains and when to use it.

Local Models: Zero Cost, Maximum Privacy

Ollama, LM Studio, and Microsoft Foundry Local all let you run an open-source language model entirely on your own machine. No subscription, no data leaving your device. Ollama is particularly lightweight: it runs on a Mac, a Windows box, even a Raspberry Pi. When you open it, you choose a model to download.

Good starting options:

• Gemma 3 (Google, open source) – strong at reasoning and Q&A
  Phi-4 (Microsoft, open source) – performs well on code and structured tasks
• Llama 3.3 (Meta, open source) – the community favorite for general use
• Mistral – fast, efficient, strong at instruction-following

Ollama also exposes a local REST API, which means once you are comfortable chatting with a model, you can start calling it programmatically.

Commercial Chat Interfaces: Best Quality, Broadest Capability

Claude Desktop (Anthropic), ChatGPT (OpenAI), and Gemini (Google) are the three primary interfaces in use today. All three handle the tasks network engineers actually need: parsing logs, comparing configs, generating Ansible playbooks, explaining routing errors in plain English. The differentiator at this tier is not which one you pick – it is whether you stop using it as a smarter search bar and start connecting it to your tools via MCP.

Before choosing: check your corporate AI policy first. Most enterprises already hold licensing for Microsoft Copilot or have an enterprise agreement with Anthropic or Google. You may already have access.

AI-Assisted IDEs For Network Engineers

VS Code with GitHub Copilot offers a meaningful free tier – enough to start. Cursor and Windsurf are purpose-built AI coding environments that tend to perform better for longer agentic sessions.

AI Tools For Network Engineers – At a Glance

Using AI Tools: Getting Started Without Writing a Line of Code

The most common misconception about AI tools for network engineers is that they require programming knowledge to be useful. They do not. You do not need Python, VS Code, or JSON to start getting value today.

Here is what that looks like in practice.

Paste your logs into a chat window. Drop a show logging dump into Claude or ChatGPT and ask it to summarize what is happening and flag anything that looks wrong. Humans have never been good at parsing dense log output at volume – these models handle it well. No configuration required. Just paste.

Compare two configs. Paste your intended config alongside the running config and ask what is different and whether anything looks wrong. Text delta analysis is one of the clearest strengths these models have.

Ask it to explain what you are reading. Paste in an unfamiliar CLI output, a BGP table you inherited, or a routing policy left behind by someone who left the company.

Connecting Your First MCP Without Knowing JSON
The jump to connecting your first MCP – where you edit a JSON file and issue an API key – does require some patience. The shortcut: use the AI to install it. Paste the GitHub link for the MCP you want into Claude Desktop and say:

“Help me install this. I’m a network engineer, not a programmer. I’ve never worked with JSON before.”

The model will walk you through it step by step.

The goal is your first natural-language conversation with your source of truth – Netbox, Nautobot, InfraHub, whatever you use. Once you can ask “How many circuits do we have in Atlanta?” and get a real answer without opening a dashboard, something changes. That is the inflection point worth chasing.

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 →