Suddenly everyone online was talking about “vibe coding.” Just describe what you want and the AI builds it. Nobody needs to learn syntax anymore. You get the idea.

I won’t pretend I didn’t have a small crisis about it. I sat there one evening, deep in a Netmiko exception-handling rabbit hole, and asked myself a fairly uncomfortable question: was I spending hundreds of hours learning something AI was about to do in five minutes?

It wasn’t paranoia pulled out of nowhere either. Every networking vendor at the time had some version of “AI-powered operations” plastered on their homepage. It genuinely felt like I’d signed up to learn how to ride a bicycle right as everyone else started buying self-driving cars.

I sat with that thought for a while. And eventually I landed somewhere I didn’t expect: the journey was still worth it, just not for the reasons I assumed when I started.

AI is great at answers. It’s still bad at filling in what you didn’t say.

Here’s what became obvious pretty fast: AI produces excellent output when you ask a sharp, well-formed question. It produces mediocre output when the question is vague — and the gap between those two is almost entirely domain knowledge.

If I don’t actually understand routing behavior, API design, or what idempotency means in an Ansible playbook, my prompts end up sounding like “make my network automated,” which is roughly as useful as telling a mechanic to “make the car better.” You get something. It’s just not what you needed.

Studying automation properly didn’t just teach me tools — it taught me how to break a problem down into something specific enough to hand off, whether the thing I’m handing it off to is a colleague or a language model. Turns out that skill is exactly what makes AI useful instead of frustrating.

You still have to read what it gives you

AI writes surprisingly clean code. It also writes confidently wrong code, and the two look identical at first glance.

In network automation specifically, whether a script “runs” was never the bar. The real questions are the boring ones: what happens if this fails halfway through a config push across forty devices? Is the rollback actually safe, or does it assume nothing went wrong? Are credentials handled properly, or hardcoded somewhere they shouldn’t be? Will this scale past the three devices I tested it on?

AI can help answer all of that. But I still need enough understanding to know which questions to even ask, and to catch the moment when an answer sounds right but isn’t. Maybe that changes eventually. For now, my job shifted less toward writing every line and more toward reviewing, pressure-testing, and steering what gets produced.

The good questions come from experience, not from nowhere

I remember reading something from Aravind Srinivas, Perplexity’s CEO, about how the next competitive edge might be asking better questions rather than just retrieving answers faster. That stuck with me longer than I expected it to.

Good questions aren’t random. They come from having done the thing badly a few times first. The more I actually understood about network design and automation trade-offs, the less generic my questions to AI became.

Early on I’d ask something like “how do I automate VLAN configuration.” Now the question looks more like: how would you design this so it works across multiple vendors, stays idempotent, plugs into a GitOps workflow, and doesn’t fall over if one device in the batch is unreachable. Same topic, completely different conversation — and a completely different quality of answer.

Memorizing syntax stopped feeling like the point

Somewhere along the way I stopped caring about memorizing exact command syntax or API parameters. Those are searchable. AI generates them on request. The documentation exists and isn’t going anywhere.

What started mattering more was understanding why something works, when to reach for it, when specifically not to, and what trade-off is quietly hiding underneath a clean-looking solution. Honestly, it was the CCIE prep itself that pushed me toward that realization — it made the difference between “studying for recall” and “studying for intuition” pretty obvious once I noticed it.

Automation was never really about the script

People hear “automation” and picture a folder of Python scripts. In practice, most of the actual work is risk reduction. It’s recognizing repetitive, error-prone manual work and figuring out how to remove the human from the loop without removing accountability. It’s thinking about what breaks, how you’d notice, and how you’d recover.

None of that disappears just because a model wrote the script for you. If anything, it matters more, because now there’s an extra layer between you and the code that you didn’t personally type.

Experience is still the tiebreaker

AI is fast, and it’s generous — it’ll happily hand you three or four reasonable-looking approaches to the same problem. Picking the right one is still the hard part, and that choice comes from having been burned by the wrong one before.

I’ve thrown out AI suggestions that looked fine on paper but didn’t match how our environment actually behaved. I’ve also taken suggestions that were genuinely better than what I would have written myself. Either way, making that call required actually understanding the technology well enough to judge it — not just accept or reject it on vibes.

So would I do it again?

If someone asked me today whether I’d still start the CCIE Automation track knowing what I know now about how fast AI moved, the answer is yes.

Not because I think I’ll be hand-writing every automation script for the rest of my career. But because the process changed how I think about problems — how to structure them, how different pieces of infrastructure connect, and honestly, how to have a more useful conversation, whether the other party is a colleague or a model.

And if none of that convinces you, there’s a simpler reason. Learning something genuinely difficult is just good exercise for the brain. Some people do crosswords. I apparently chose BGP, REST APIs, and Python exception handling. Questionable life choices aside, the brain workout was real.

AI didn’t make this journey pointless. It just changed what I actually got out of it. I don’t think of the certification as proof I can recall commands anymore — I think of it as proof I can reason through a complex system and work alongside AI instead of getting replaced by it.

That feels like a better outcome than the one I was originally chasing.

Installation

1
pip install netmiko

Basic Connection

1
2
3
4
5
6
7
8
9
10
11
12
from netmiko import ConnectHandler

device = {
    "device_type": "cisco_ios",
    "host":        "192.168.1.1",
    "username":    "admin",
    "password":    "cisco123",
}

with ConnectHandler(**device) as conn:
    output = conn.send_command("show ip interface brief")
    print(output)

Always use the with statement — it ensures the connection is properly closed even if an exception occurs.

Supported Platforms

Robust Error Handling

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
from netmiko import ConnectHandler
from netmiko.exceptions import (
    NetmikoTimeoutException,
    NetmikoAuthenticationException,
)
import logging

log = logging.getLogger(__name__)

def connect(params: dict):
    try:
        conn = ConnectHandler(**params)
        log.info(f"Connected to {params['host']}")
        return conn
    except NetmikoTimeoutException:
        log.error(f"Timeout: {params['host']} unreachable")
    except NetmikoAuthenticationException:
        log.error(f"Auth failed: {params['host']}")
    except Exception as e:
        log.error(f"Unexpected: {e}")
    return None

Multi-Device with ThreadPoolExecutor

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
from concurrent.futures import ThreadPoolExecutor, as_completed

INVENTORY = [
    {"device_type": "cisco_ios", "host": "10.0.0.1", "username": "admin", "password": "cisco"},
    {"device_type": "arista_eos","host": "10.0.0.2", "username": "admin", "password": "arista"},
]

def run_cmd(device, cmd):
    result = {"host": device["host"], "output": None, "error": None}
    try:
        with ConnectHandler(**device) as conn:
            result["output"] = conn.send_command(cmd)
    except Exception as e:
        result["error"] = str(e)
    return result

def run_all(inventory, cmd, workers=10):
    results = []
    with ThreadPoolExecutor(max_workers=workers) as ex:
        futures = {ex.submit(run_cmd, d, cmd): d["host"] for d in inventory}
        for f in as_completed(futures):
            results.append(f.result())
    return results

for r in run_all(INVENTORY, "show version"):
    status = "OK" if r["output"] else f"ERR: {r['error']}"
    print(f"{r['host']:15} {status}")

TextFSM Structured Output

1
2
3
4
5
6
7
8
with ConnectHandler(**device) as conn:
    interfaces = conn.send_command(
        "show ip interface brief",
        use_textfsm=True        # returns list of dicts
    )

for i in interfaces:
    print(f"{i['intf']:25} {i['ipaddr']:18} [{i['status'].upper()}]")

Key Takeaways

• Always use with ConnectHandler(...) for automatic cleanup
• Handle NetmikoTimeoutException and NetmikoAuthenticationException explicitly
• Use ThreadPoolExecutor for multi-device — never loop serially in production
• use_textfsm=True gives you structured output for free

Next up: Nornir — a framework that adds proper inventory management and task runners on top of Netmiko’s connection model.