My Top 5 Ways to Start Using AI as a Network Engineer

These are the five jobs I’d suggest you try handing to AI first, from the G Talks Tech video “Will AI Replace Network Engineers?” I picked them for how much time they give back compared to the time they take to set up. Each one gives you the job it takes off your plate, how AI does it, what it needs, a prompt to start with, and where it still needs you, the human.

Three rules first

• Lab first. I would recommend testing these in a lab first, then running it next to your manual process in prod/dev for a few real cycles before you fully trust the system. The more you use these tools, the more trust you will build with it.
• Watch the data. I’d only put real configs, inventory and device output into an AI tool your company approves for that data, not a free consumer chat. Keep credentials out of scripts and prompts. Each prompt below is labeled: Public-safe means it has no real data in it, Enterprise-only means you’ll paste your own data, so use your approved tool.
• You still sign off. AI only knows your network through the context you give it, and it will be confidently wrong at some point. Have it show its work: the evidence, the raw output, or a before-and-after you can check yourself. In my opinion, that matters most when the answer is “you’re not affected by this CVE.” I want to know why I’m not and how the AI came to that conclusion.

1. Post-cutover app testing

The time sink: after a firewall cutover you may have to manually test your apps, or have other teams online with you testing them. It’s likely past midnight, you just successfully cut over to new hardware, but you have to test every app so you can actually get some sleep.

How AI does it:

1. Have AI read the rules you’re changing and build the list of apps and ports to test.
2. Have it write a script that tests each one and prints pass or fail.
3. Run it before the cutover and again after, and compare the two runs.
4. Have it check the rule hit counts and the logs for anything getting blocked that shouldn’t be.

What it needs: the rule set (read-only), a machine that can reach the apps internally, and one externally, if you’re testing public-facing apps.

Starter prompt (Public-safe):

Write a Python script that reads a CSV of application checks (name, host or URL, port, expected HTTP status) and uses an HTTP request when the row has a URL and an expected status, and a TCP connect when it only has a host and port. Print PASS or FAIL per check, save the results to a timestamped csv file, and add a compare mode that shows what changed between a before run and an after run.

Where it still needs you: you pick the flows that matter and decide what a failure means. The script knows the port answered, not which app the change was for.

NOTE: If you don’t know what all your apps are, or you’re worried your NAT and ACLs are out of date, your pre-check run shows you how things actually work today. That way, when you cut over, you know what to expect. If something wasn’t responding before the cutover, you shouldn’t expect it to respond after. You can clean that up after your change window.

2. Security advisory triage

The time sink: reading every new advisory, then checking what code version the device is running, whether you use the affected feature, whether the device is internet-facing or internal only (helps determine severity and patching priority), and whether any of the workarounds will actually work for you.

How AI does it:

1. Give AI read-only access to your devices so it can build network state: what you run, what code version, what role, and how each device connects, kept in an inventory file it maintains (YAML works well). If you have a source of truth (NetBox, Nautobot, a CMDB), point it there instead, and use live show commands to double check anything that isn’t logged in your SoT. Either way, stamp network state with the time it was built and refresh it before you triage, whether you build it manually or have an automated system for it.
2. Pull new advisories. Cisco’s PSIRT openVuln API is free with a Cisco account. Palo Alto has an advisory API and an RSS feed, Fortinet has an RSS feed, and for everyone else you can point AI at the vendor’s advisory page or email alerts. Add CISA’s Known Exploited Vulnerabilities list too (free, in CSV or JSON): an advisory on that list is being exploited right now.
3. Use the vendor’s lookup to decide which versions are affected, not AI’s own judgment. Comparing version strings against fixed releases (is 17.9.4a affected? is 17.12.1 already fixed?) is where AI tends to slip, so have it call the vendor’s lookup and use that answer. Cisco’s openVuln API can look this up by software version.
4. Have AI check the context on each match: is the affected feature turned on, and is the device reachable from the internet? It works that out from network state, the device role and the interface configs, and when that can’t answer it, AI logs in and runs the specific show commands to help it get an answer. Reachable means the management plane too, and any NAT on the firewall in front of it, not just the device’s own config. If it can’t tell, it says so and treats the device as internet-facing until you confirm.
5. Re-rate each one for your environment, using rules your security team agrees to. CVSS has an environmental score built for exactly this. A 9.8 on an internal-only device can rank below a 6.5 on your internet edge, but anything on the exploited list goes to the top.
6. Get back the short list that’s actually yours, ranked, with each advisory’s workarounds pulled out and the command output or config lines behind every call.

What it needs: a read-only account on your devices, with the limit enforced on the account itself (a read-only role, ideally TACACS or ISE command authorization), not just in the prompt. An inventory file or source of truth with platform, code version and device role. Your vendors’ advisory feeds. Your security team’s rules for rating severity.

Starter prompt (Enterprise-only):

You have read-only access to my network devices. For each advisory: use the vendor’s version lookup (for Cisco, the openVuln API) to find which of my devices run an affected version. Don’t compare version strings yourself. For each match, check whether the affected feature is enabled, and run any extra show commands you need. Decide whether the device is reachable from the internet, based on its role, interfaces, routing, firewall zones and any NAT in front of it, including its management interfaces. If you can’t tell, say so and treat it as internet-facing until I confirm. Re-rate the severity for our environment using these rules: [paste your security team’s rules], and put anything on CISA’s Known Exploited Vulnerabilities list at the top. Give me a ranked list with the advisory, the devices, your rating and why, any workaround, and the exact command output or config lines behind each call, including every “not affected” answer. Never run a command that changes configuration.

Where it still needs you: the rating rules and the call to act belong to you and your security team. Internal-only lowers the priority but doesn’t remove the risk, because an attacker who’s already inside can still reach the device, so it still gets patched, just later. A “not affected” answer needs evidence just like an “affected” one, and it’s the answer to spot-check most while you build trust, because a wrong “not affected” is the expensive mistake. Test any workaround in the lab before you trust it in production.

3. The “are we affected by this?” question

The time sink: someone on your team, or your boss, sees a post about a new vulnerability and messages you: “are we affected?” You spend thirty minutes (at least) logging into devices, checking versions and config, and writing a knowledgeable response back. This goes hand in hand with #2 above.

How AI does it:

1. If you’ve set up #2, most of the work is already done: AI has network state and read-only access to your devices.
2. Drop in the link to the advisory, or paste its text, and ask the question.
3. AI uses the vendor’s version lookup to find which devices run an affected version, then checks whether the affected feature is actually turned on (like whether the web UI is enabled), logging in to run the show command when network state doesn’t cover it.
4. It drafts the reply in plain language, with the evidence underneath for you to check.

What it needs: the setup from #2 (network state, a read-only account, the vendor’s version lookup). Without it, you can still paste your inventory and the relevant config into an approved AI tool. It’s just slower.

Starter prompt (Enterprise-only):

Someone asked whether we’re affected by this advisory: [link or paste]. Use the vendor’s version lookup to find which of our devices run an affected version. Don’t compare version strings yourself. For each one, check whether the feature the advisory says must be enabled is actually on, and run any show commands you need. Answer in two sentences a non-network colleague can follow. Under that, list every device you checked, what you found, and the command output behind it. If anything is missing or you couldn’t confirm it, say so. Never run a command that changes configuration.

Where it still needs you: you decide whether it gets sent. Read every draft before it goes out under your name, because a wrong answer sent to a coworker is hard to take back, and the hardest one to take back is “no, we’re fine.” If the answer is “not affected,” look at the evidence before you hit send.

4. Change-window pre-checks and post-checks

The time sink: it’s 2 AM in the change window. Before you touch anything, you run the same show commands on every device. Afterward you run them all again, then scroll through route tables and neighbor lists, eyeballing what moved.

How AI does it:

1. Have AI write a script that runs the same show commands on each device before and after the change. If you built network state in #2, that’s most of your pre-check already, so refresh it at the start of the window.
2. Save every output to a file named for the device, the command and the stage (pre or post), so you have a record when someone asks what changed.
3. Diff the two, hiding the counters, uptimes and timestamps that always move.
4. Hand the diff and your change plan to your approved AI tool and ask: did what moved match what this change was supposed to do? Have it call out anything that changed that the plan didn’t mention, like a neighbor that dropped or a route that disappeared.

What it needs: a read-only account on your devices (the same one from #2), your list of show commands, and your change plan.

Starter prompt (Public-safe):

Write a Python script using Netmiko that runs a list of show commands on a list of devices (host, device_type), saves each output to a file named for the device, command and stage (pre or post), and then prints a diff between the pre and post files that ignores counters, uptimes and timestamps. Read device credentials from environment variables.

Where it still needs you: what counts as an acceptable change, and the call to roll back. The diff can show you a neighbor dropped, and AI can tell you that wasn’t in the plan, but you decide whether your change caused it and whether to roll back.

NOTE: if the pre-check already shows something broken, write it down before you start. Otherwise you’ll spend the window chasing a problem your change didn’t cause.

5. Documentation refresh after a change

The time sink: the change went fine, it’s late, and the last thing you want to do is update the interface table, the routing summary and the diagram. So it waits, and a few months later nobody trusts the docs.

How AI does it:

1. Use the post-check output from #4 as your fresh state, or have AI pull it off the devices with its read-only access.
2. Have AI update your interface table, routing summary or runbook section to match, in the format you already use.
3. For diagrams, have it rebuild the diagram as code (Mermaid is a good fit, since it’s plain text) from CDP or LLDP neighbors and interface descriptions. It gets you most of the way there, but expect to clean up the layout.
4. Have it mark anything it couldn’t confirm from the output instead of guessing, and show you a before-and-after of everything it changed.

What it needs: fresh device output (or the post-check files from #4), your existing documentation, and for diagrams, CDP or LLDP turned on.

Starter prompt (Enterprise-only):

Here’s the current output from these devices: [paste, or point it at the post-check files]. Here’s the documentation section it should match: [paste]. Update the section to match the output and keep my format. Show me a before-and-after of every change. Mark anything you couldn’t confirm from the output instead of guessing. If I’ve included CDP or LLDP neighbor output, also give me a Mermaid diagram of how these devices connect.

Where it still needs you: you check the update and add the why. The config shows what’s set up but not why, and the why is what makes your documentation worth reading.

How to start

Pick one, ideally the job you did by hand most recently, while every step is still fresh. Prove it in the lab, then spend some of the time it gives back on the next one.

G Talks Tech: practical AI workflows for network engineers who are tired of doing everything the hard way. More at gtalkstech.com.