From CLI to NetDevOps: a 90-day plan for a CCNP-level engineer

What should a CCNP-level engineer learn next?

Not more networking. Learn to treat the network as data: Python applied to the show output and configs you already read fluently, then Netmiko, then the device APIs (RESTCONF, NETCONF, gNMI), then Git and CI for network change, and then AI assistants used with a check on every output.

You already have the hard part. A CCNP knows what a healthy OSPF adjacency looks like, what a config should contain, and what “broken” smells like at 2 a.m. That judgment took years and no bootcamp grad has it. What you are missing is mechanical by comparison. You need to express that judgment in code so it runs on 400 devices instead of one screen at a time.

That is why the plan below starts with Python on network data instead of “hello world”, and why every phase ends in something you can demonstrate. Watching videos feels like progress, but it will not show up as something you can demonstrate on day 30.

Do network engineers really need Python in 2026, or does AI make it unnecessary?

Python skill matters more with AI in the loop. Here is the position, stated plainly so you can disagree with it: the model writes the first draft now, which means the engineer’s job moved from writing code to verifying code. Verification is itself code: an oracle you wrote by hand, a diff against it, a check for values the model invented, a test suite that runs before anything touches a device. An engineer who cannot read Python has no way to verify what the model wrote, and an unchecked script against production devices is how you end up explaining an outage to your director.

Below is a transcript from one of our labs where an AI assistant drafts a verification tool, the lab’s test suite catches a real bug in the draft, and the fix takes one function. This is what “AI-assisted” should mean in practice.

AI drafts a tool, tests catch the bug

This is lesson 4 of our paid course (“Vibe-code a tool with AI, and verify it”). The lab asks you to build the scaffold that stands between an AI’s output and your trust: an oracle function you write yourself, a diff against it, a hallucination check for invented IPs, a shape check, and a function that folds those findings into accept, revise, or reject. The grading suite is pytest, it runs in the browser, and it never needs a live AI call to grade you.

For this note we ran the loop the lesson teaches, for real: Claude drafted all five functions from the lab’s docstrings, and we ran the actual grader on the draft, unedited. Round 1:

$ pytest -q
.....F......                                                             [100%]
=================================== FAILURES ===================================
_______________ test_hallucinated_ips_flags_substring_of_real_ip _______________

    def test_hallucinated_ips_flags_substring_of_real_ip():
        # The raw output has only 10.0.0.99; reported 10.0.0.9 is a different
        # address even though it is a substring of it.
>       assert hallucinated_ips("Eth9  10.0.0.99  up    up", ["10.0.0.9"]) == ["10.0.0.9"]
E       AssertionError: assert [] == ['10.0.0.9']
E
E         Right contains one more item: '10.0.0.9'

FAILED test_lesson04.py::test_hallucinated_ips_flags_substring_of_real_ip
1 failed, 11 passed in 0.02s

The bug is worth staring at, because it is exactly the kind AI produces. The drafted hallucination check was one clean, readable line:

def hallucinated_ips(raw_text, reported_ips):
    return sorted(ip for ip in reported_ips if ip not in raw_text)

It looks right. It passes the obvious cases. And it uses substring matching, so the invented address 10.0.0.9 sails through whenever the real capture contains 10.0.0.99. A check that misses a hallucinated IP is worse than no check at all, because you trust it. The fix is to extract the actual IPs from the raw text and check membership:

def hallucinated_ips(raw_text, reported_ips):
    import re
    real = set(re.findall(r"\b(?:\d{1,3}\.){3}\d{1,3}\b", raw_text))
    return sorted(ip for ip in reported_ips if ip not in real)

Round 2:

$ pytest -q
............                                                             [100%]
12 passed in 0.01s

That loop, draft with AI, run the tests, read the failure, fix it yourself, is the whole discipline. Someone still had to read the draft closely enough to see why substring matching would let a hallucinated IP slip through, and that reading caught the bug before it reached a device.

The 90-day plan

Three phases, thirty days each, assuming roughly an hour a day on weekdays. Each phase ends in a checkpoint you can grade.

Days 1 to 30: Python, practiced on network data

Skip the generic Python courses that make you build a to-do app. Learn the core language on the material you already understand: show output, configs, inventories, JSON from an API.

• Week 1: strings and the REPL. Slice interface names and IPs out of real show output by hand.
• Week 2: files, lists, conditionals, loops. Read a config from disk, walk it, pull the lines you care about.
• Week 3: dictionaries, sets, exceptions. This is the week networking knowledge starts paying off, because parsed network state is a dictionary and you already know what shape it should have.
• Week 4: regular expressions against show output, then functions to package your parsers so you can reuse them.

Day 30 checkpoint: given a raw show ip interface brief you have never seen, write a function from scratch that returns structured data (name, IP, status), and handle the malformed line without crashing. If you cannot do this cold, repeat week 3 and 4 before moving on. Our free Python foundation track is these exact 30 days: 10 lessons, every one ending in a graded, in-browser lab, no email address required.

Days 31 to 60: talk to devices

Now your code reaches a device, changes it, and proves the change landed.

• Week 5 and 6: Netmiko. Connect, run show commands, push config from structured data, and always read state back afterward to confirm. For this specifically, Kirk Byers’ material (pynet.twb-tech.com) is excellent, and he wrote Netmiko. His free email course on Python for network engineers has been running for years and is a legitimate alternative to our free track.
• Week 7: the model-driven APIs. REST and RESTCONF first, because the request-response shape is the easiest to reason about. Then NETCONF, including confirmed commit, which is the API equivalent of reload in 5 before you touch a remote box.
• Week 8: gNMI and streaming telemetry, so you have seen state arrive as a stream instead of a poll.

You need something to practice against. Cisco CML if your employer has licensing, EVE-NG or Containerlab if you are building your own bench, or the Cisco DevNet sandboxes if you want zero setup. Our paid course ships in-browser labs against simulated device state, so the graded work needs no lab bench at all; build the bench anyway, because your production network runs on real boxes.

Day 60 checkpoint: from a clean prompt, use Netmiko to push a VLAN or interface description change to a lab device, verify it landed by reading state back in code, and then do the same change over RESTCONF. You will have made the same verified change through two different paths, without copying a command from a blog post.

Days 61 to 90: workflow, and AI with a check on it

Phase three covers the work that gets you trusted with production change: Git discipline, CI, and AI-assisted coding with a verification step. It is unglamorous work, and it is exactly what a NetDevOps interview probes.

• Week 9: Git. Configs and automation code in a repository, small commits, branches, and the habit of git diff before anything runs.
• Week 10: CI for network change. A pipeline (GitLab CI or GitHub Actions, either is fine) that runs your tests on every push, so a bad parser is caught by a runner instead of a maintenance window.
• Week 11: AI-assisted coding as a repeatable loop: pin a contract prompt, let the model draft, grade the draft with tests you wrote, and make accept or reject a decision your code renders. The transcript above is this week in miniature.
• Week 12: put it together. One change, end to end: branch, AI-drafted code, your tests, CI green, push to the device, verify, merge.

Day 90 checkpoint: deliver one real change through that full path and keep the artifacts (the branch, the CI run, the before and after device state). That artifact set is the honest answer to “show me your automation experience” in an interview.

Where should you actually study this?

Honest answers, since a shortlist you can trust matters more than our pitch:

• Kirk Byers (pynet.twb-tech.com): the author of Netmiko. His free Learning Python for Network Engineers email course is the long-standing default recommendation, and his paid courses go deep on Netmiko, Nornir, and Ansible. If phase 2 is your gap, start there.
• ipSpace (Ivan Pepelnjak): deep material on architecture-level automation thinking, data models, and why automation projects fail. Read it in phase 3 and after.
• Vendor docs and DevNet: for RESTCONF, NETCONF, and gNMI specifics on your platform, the vendor documentation is the source of truth, and the DevNet sandboxes are free practice targets.
• CBT Nuggets, INE, Pluralsight, Udemy: broad video libraries. Fine as supplements, but video alone will not get a CCNP to something demonstrable in 90 days. Pair every hour of video with an hour of building.
• RouteSwitchU (us): the free Python foundation track is phase 1 of this plan with a graded lab on every lesson. The paid AI-Assisted Network Automation course ($249 one time, as of August 2026) is the full bridge: Python, Netmiko, the device APIs, Git and CI, and the AI-verification discipline the transcript above comes from, in 9 modules with graded in-browser labs throughout.

Start phase 1 today. Do not let day 30 arrive without something you can demonstrate. The free track is the lowest-friction way to start, and it will grade you honestly.