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 Network change management in practice: a worked ticket
The ticket below is the shape a generated change should arrive in. Nothing about it is new to anyone who has run a change advisory board; the additions are the disclosure line, the attached tool output and the explicit statement of what must not change. Values are illustrative. The point is that a reviewer can check every field against something concrete rather than against the author's confidence.
CHG-2418 Extend management ACL to new NOC subnet Intent : permit SSH and SNMP from 10.44.8.0/24 to all core and distribution devices Must not change: existing permits for 10.44.0.0/24; implicit deny at the end of ACL 110 Drafted by tool: lines 3 to 6 of the attached diff (assistant, prompt attached as prompt.txt) Blast radius : 14 devices, management plane only; no routing protocol touched Platform check : parsed against IronWare 8.0 release help; 0 unknown keywords Analysis : reachability query attached; 10.44.8.0/24 -> vty: permit; 10.44.9.0/24 -> vty: deny Lab : applied to lab-dist-1 (same release), SSH from both NOC subnets confirmed Rollout : dist-3 first with 'reload in 10', then pairs, core last Rollback : timer cancelled only after 'show access-list 110' shows hits from 10.44.8.0/24 Monitoring : SSH session count and SNMP poll success per device, watched for 15 minutes Reviewer : on-call network lead Approved 2026-09-24 10:20 UTC
| Ticket field | What the reviewer checks | Reject if |
|---|---|---|
| Intent and must-not-change | One sentence each, consistent with the diff | Diff touches anything the second sentence protects |
| Drafted-by-tool lines | Named by line number, prompt attached | Disclosure missing or vague |
| Platform check | Parser or help output for the exact release | Any unknown keyword, or a generic parser used |
| Analysis | Queries that test the intent and the boundary just outside it | Only the happy path was queried |
| Lab | Same release, same neighbour types, failure exercised | Different release, or success only |
| Rollout and rollback | Order, timer, who confirms, on what evidence | Timer longer than the window, or confirmed by a script |
Two fields carry most of the weight. The must-not-change line turns the review from reading into testing: the reviewer looks for that protected line in the diff and in the analysis output. The rollback line names the evidence that ends the timer. Without it, operators cancel the timer because nothing has broken yet, which is a different thing from the change having worked.
router# configure router(config)# load merge chg-2418.txt router(config)# show | compare router(config)# commit confirmed 10 comment "CHG-2418 mgmt ACL, tool-drafted lines 3-6" commit confirmed will be rolled back in 10 minutes unless confirmed router(config)# run show access-list 110 | match 10.44.8 router(config)# commit commit complete router# show system commit | head -2 0 2026-09-24 10:31:07 UTC by ops via cli CHG-2418 mgmt ACL, tool-drafted lines 3-6
The comment on the commit is the cheapest piece of change control there is: it puts the ticket number and the disclosure into the device's own history, where an auditor or a colleague at 3 a.m. will find it without opening the ticketing system. NETCONF (RFC 6241) defines the confirmed commit capability that this shape relies on; where a platform lacks it, a timed reload of the saved configuration does the same job with less grace.
05 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.
06 Failure modes in reviewing generated changes
- Syntax first. The reviewer starts at line one of the diff and is tired by line forty. Generated text is syntactically clean, so nothing is found, and the semantic error in the prefix-list slips through. Intent and blast radius come first for exactly this reason.
- Trust transferred to the tool. "The assistant checked it" appears in the ticket as if it were a test result. A model reviewing its own output is the same model making the same assumptions. Only a parser, an analysis tool, a lab or a device is evidence.
- Stale analysis snapshot. The reachability model was built from configurations collected last month. A change that passes against it may fail against the network as it is. Refresh the snapshot before the run, and record its date.
- Lab on a different release. A command that exists on the lab image and not on production is the wrong-version trap moved one step later. Match the release exactly or note the gap in the ticket.
- Automatic confirmation. A deployment script that issues the confirming commit on its own, or an operator who cancels the timer at the first prompt, removes the safety net while leaving it in the ticket.
- Merged changes. Two generated changes to the same device in one ticket cannot be rolled back separately. One intent, one ticket, one timer.
Most of these are ordinary change-management failures with a new cause. The fix is the same as it always was: define the evidence before the change, and refuse to close the ticket without it. Watching the monitoring named in the ticket is part of that evidence; interface state and session counts polled through the standard SNMP interface objects give a per-device answer within one polling interval.
07 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.
08 Expert tips for reviewers
- Read the must-not-change line, then search the diff for it. If the protected line appears at all, stop and ask why.
- Ask the author to reproduce one analysis query live. A result that cannot be reproduced during review is not a result.
- Reject "cosmetic" reorderings in generated ACLs and route-maps. Order is semantics on those objects, and the tool does not know which lines are load-bearing.
- Time-box the syntax pass and spend the saved minutes on the boundary cases: the prefix one bit wider, the subnet next door, the neighbour that should now be denied.
- Keep the device commit log, the ticket and the show output together, timestamped in UTC with untranslated addresses, as RFC 3871 asks of operational logs; the practice described for retaining edge logs as a tamper-evident record applies unchanged to the record of a router change.
- Review the prompt as well as the output. A prompt that names the platform, the release and the protected lines produces fewer of the errors this page lists, and a prompt library is a cheap team asset.
09 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. Treat it as a review aid and make the judgement yourself.
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.
What should a change ticket contain when part of it was drafted by a tool?
The same fields as any change, plus three: which lines the tool drafted and the prompt used, the tool or lab output that verified them, and a one-line statement of what must not change. Reviewers approve on that evidence, and the ticket number goes into the device commit comment so the record survives outside the ticketing system.