On this page
01 What changes when a tool drafts the change
Network teams that ran Foundry, Cisco and Juniper gear side by side learned to review changes for the vendor-specific traps: a command that exists on one platform and means something else on another. AI assistants add a new class of trap. They produce syntax that is fluent, plausible and sometimes for the wrong platform or the wrong software version, and they rarely signal uncertainty. The checklist below, in the routing section, adapts ordinary change review to that failure pattern.
02 Disclosure: mark what the tool wrote
Ask authors to state in the change ticket which parts were drafted with a tool and which prompt produced them. This is not about blame. It tells the reviewer where to spend attention, because generated lines fail differently from typed ones: they are less likely to have typos and more likely to have confident errors in semantics, such as an ACL that permits the intended range plus the one next to it. The method for checking generated subnet and ACL arithmetic covers the most common case.
03 Review intent before syntax
Restate the intent
The reviewer writes one sentence on what the change should do and what must not change. If the author and reviewer disagree, stop there.
Bound the blast radius
List the devices, routing domains and customers the change touches. A generated change that touches more than the intent requires is the first thing to question.
Check platform and version
Confirm every command exists on the target platform and software release. Generated configurations mix dialects freely.
Verify with tools
Run the candidate configuration through an analysis tool that models reachability and policy, such as the open-source Batfish, as described in verifying AI-written configs before deployment, and in a lab or simulator where possible.
Approve the rollout plan
Review how the change goes out and how it comes back, not just the change itself.
04 Staged rollout with a way back
Where the platform supports it, deploy with a confirmed commit: the device applies the change and reverts automatically unless an operator confirms within a set time. NETCONF defines this as a standard capability, and many network operating systems offer an equivalent. Where it is not available, schedule a timed rollback before applying the change. Start with one device or one site, check the monitoring you defined in review, then widen. On a core router carrying transit traffic, a staged rollout is the difference between a blip and an outage.
05 Recording what the tool got wrong
Keep a short shared log of errors caught in review: wrong platform syntax, misaligned subnets, missing deny statements, invented command options. Over a quarter it shows which checks catch most problems and which prompts produce the worst output. It also gives new engineers an honest picture of where the tools help and where they do not. Security-focused configuration management guidance from NIST treats reviewed, recorded and reversible change as the baseline; generated changes do not get an exception.
| Error class | Seen in generated changes | Caught by |
|---|---|---|
| Wrong platform dialect | Commands valid on another vendor's OS | Platform and version check |
| Over-broad match | ACL or prefix list wider than intended | Configuration analysis, address tests |
| Missing deny or default | Implicit behaviour assumed, not written | Intent review, lab test |
| Invented options | Keywords that no release supports | Parser in lab or simulator |
Generated changes are welcome in review. Unverified generated changes are not welcome in production.
06 Questions
Should network engineers disclose AI use in change requests?
Yes, stating which lines a tool drafted helps reviewers focus on the errors generated text tends to contain. It is a review aid, not a judgement.
What is the biggest risk in AI-generated network configs?
Confident semantic errors: valid-looking commands for the wrong platform or version, and ACLs or routes that match more than intended.
How do I test a generated config safely?
Model it with a configuration analysis tool, run it in a lab or simulator, then deploy to one device with a confirmed commit or timed rollback.
What is a confirmed commit?
A deployment mode in which a device applies a change and reverts it automatically unless an operator confirms within a set time. NETCONF defines it as a standard capability.
Does AI assistance change who is accountable?
No. The author and reviewer remain accountable for the change, exactly as with any other source of configuration text.