I recently joined Jim Kunkle on The Digital Revolution podcast to talk about something I’ve been living for the past four years: the evolution of the network engineer into an AI orchestrator – what’s driving it, what it means for your career, and how to actually get started without a PhD in machine learning. If you haven’t listened yet, I’d encourage you to. But if you want the core of what we covered, keep reading.

It starts with a moment from late 2022.

I remember the first time I connected Cisco pyATS to the ChatGPT 3.5 API. I was testing network interfaces the way I always had, writing brittle, bespoke Python tests. Hundreds of lines of handcrafted code, one test per use case, fragile as glass.

Then I just… sent the payload from a show interface command to the AI and asked it to tell me if everything looked healthy.

It came back and said: “Yes, these three interfaces have problems. Here’s why. Here’s what you can do about it.”

It felt like Gandalf touching the One Ring. I was sitting by the fire, muttering to myself – precious pyATS, precious artificial intelligence – and everything changed. Not because the output was perfect. Because I understood what was now possible.

That moment set the trajectory for everything I’ve done since, and it’s a big part of why I’m now at Itential, building AI-augmented network automation tools and helping infrastructure teams move from operator to orchestrator. It’s what I want to walk you through here.

I don’t use the word “revolution” lightly. But I think 2026 is going to be looked back at historically the same way we look at the agricultural revolution, the industrial revolution.

Generative AI is less than four years old as a concept most of us have touched. And yet Gartner pegs 70% of IT-related activities as AI-augmented by 2030. That’s four years from now. There are 1.8 million open-source agents deployed on the internet today. People from all walks of life, not just network engineers, are spinning up agents by following a README.

The train is moving. And I’d rather help you get on it than watch it leave.

If you’ve been in networking for any length of time, you know the life. Notepad files per device. Configuration commands drafted up per device per file. Some operator logs in, applies the config, and then testing happens after the fact – separately, manually, slowly.

Multi-vendor environments meant memorizing the nuances of each platform’s command set. Change windows were small. The stakes were high. Everything had friction.

I spent nine years as the Senior Network Architect for the Parliament of Canada before Cisco, before Itential. The network I helped build was a greenfield success. But operating it was a completely different challenge. We were stretched thin. Velocity was slow. And the old model – one human, one device, one command at a time – wasn’t going to scale.

That’s when Ansible entered the picture. Then Python. Then pyATS.

Here’s how I think about the new role: imagine you had unlimited budget to build a team of specialists. You’d have someone focused on compliance. Someone on security. Someone on config management. Each with their own tools, their own skills, their own domain expertise.

Now imagine that team never sleeps, never gets paged, never has to be onboarded.

That’s the agentic model. A supervisor agent interfaces with you – the human – while a fleet of specialized workers handles the actual execution. Configuration agents. Compliance agents. Security agents. Each autonomous within defined boundaries, each with the right guardrails in place.

The deterministic execution is still there. The guardrails are still there. But now you have agents that can reason, triage, and act on top of that foundation.

I recently demoed exactly this: a ServiceNow ticket opens, it triggers an agent, the agent connects to the device, runs the tests, and comes back with enriched results and remediation recommendations – all inside the ticket, within minutes, without a human being paged. It’s read-only. It’s safe. It’s human-on-the-loop.

That’s where we start. Triage. Safe, read-only, high-value triage.

One thing I see overlooked constantly: the quality of your AI output is directly tied to the quality of your input.

Don’t copy and paste raw CLI output into an LLM. Parse it first.

Tools like pyATS parsers are multi-vendor and will turn show command output into structured JSON. And here’s the key insight: as far as the LLM is concerned, it doesn’t matter that the JSON represents network key-value pairs. It just reads it as structured data. It understands it universally. Which means your inference quality goes up dramatically.

It sounds simple because it is.

When network automation started gaining traction, there was an immediate backlash: you’re going to automate yourself out of a job.

That fear has hovered over our profession for a long time. And here’s what I can tell you from personal experience: every time I automated something, even big, meaningful things, I was not let go. I was asked what else I could automate. I became more valuable because I was the one who understood the new codebase. I became the person the organization leaned on to push further.

If it’s your agent people are talking to, you are still the most important person in the room. You built it. You maintain it. You understand its limitations and its capabilities. That’s leverage, not redundancy.

I think less and less we need to worry about memorizing Python syntax or CLI commands. What we need to develop is something called spec-driven development, SDD.

It sounds technical, but it’s not. Spec files are natural language markdown files. There’s structure to them, borrowed from test-driven development, but the specs themselves are written in plain English. And this is how I believe AI-augmented systems are going to be built going forward.

Network engineers are actually well-positioned for this. We’ve always been spec-driven. Architecture diagrams, design documents, requirement specs – we’ve been doing this for decades. Now we just turn those specifications into something that generates configs, builds agents, or spins up infrastructure using an LLM.

You’re not just a builder anymore. You’re a translator between human intent and machine execution.

I want to say this directly, because it held me back and I don’t want it to hold you back.

I spent a long time believing there was a glass ceiling in AI, that you needed a mathematical background, a computer science degree, some mythical credential I didn’t have. I knew automation. I knew networks. But AI felt like someone else’s domain.

It isn’t. If you can make a REST API call, you can build something meaningful with AI today. The tools – Claude Desktop, Cursor, MCP, the major APIs – have never been more accessible. You don’t need to understand the algorithms. You need to understand your domain and be willing to experiment.

So find that use case. The health check you run every Monday. The ticket triage you’re always behind on. The config audit that takes four hours. Start there.

If I’m honest, I think the next five years look less like incremental change and more like a different world.

I think infrastructure equipment ships with purpose-built AI silicon. I think vendor-tuned models give us natural language interfaces directly on devices. I think agent-to-agent communication becomes a standard pattern, where your BGP neighbor might be an AI agent. Where agents participate in routing protocols and have better real-time insight into the network than any human ever could.

The CLI was an incredible tool. I cut my teeth on it. But we started at the CLI, and I think we’ll leave it behind.

My bet: faster than any of us expect.

You don’t need a five-year plan to start. You need one workflow, one thing you do every week that an agent could do better, faster, or safer than you can alone.

Write it down. Build toward it. Share what you learn.

That’s how we got from notepad files and 300-line Python scripts to agent fleets that triage production tickets in real time.

The evolution is already happening. The only question is where you want to be in it.

If this resonated, I want to invite you into a space where we’re actively doing this work together.

The VibeOps Forum is a community for engineers who are serious about bringing AI into infrastructure – sharing ideas, sharing code, and doing it without judgment. No one calls your work slop. It’s a safe, inclusive space where people from all over the world are building real things and showing their work.

We’re not waiting for AI to become mainstream. We’re the ones making it mainstream.

Join the VibeOps Forum →