AI-assisted network engineering sounds close to network automation.
I think that is where some of the confusion starts.
They touch the same work. They can even produce some of the same artifacts: templates, playbooks, policies, configuration snippets, tests, diagrams, pull request summaries, and implementation plans. But they are not the same discipline, and treating them as the same thing can blur an important boundary.
Network automation is still the practice of making infrastructure change repeatable, testable, reviewable, and operationally safe.
AI-assisted engineering is something different. It can help an engineer reason through a change, draft the first version of an artifact, explain an unfamiliar pattern, summarize a diff, review a pull request, or find inconsistencies in a plan. That is useful work. I am increasingly convinced it belongs in the infrastructure workflow.
But usefulness is not the same as determinism.
The difference matters
If I write an Ansible playbook, a Terraform module, or a Python script, I am trying to encode a repeatable expectation. Given the same inputs and the same environment, the system should behave in a predictable way. If it does not, I should be able to inspect the code, run a test, compare a diff, reproduce the issue, and fix the logic.
That is the bargain automation makes with us. It may be imperfect. The tool may have sharp edges. The inputs may be messy. But the goal is still clear: turn a known operation into something that can be executed consistently and reviewed before it changes the environment.
AI does not make that same bargain.
An AI system can be helpful and still produce a slightly different answer the next time. It can follow a pattern for ten files and then drift on the eleventh. It can generate a configuration that looks right until someone notices the naming standard is off, the route policy is too broad, the rollback step is vague, or the validation command checks the wrong thing.
This is not a reason to reject AI. It is a reason to put it in the right part of the system.
AI belongs closer to the thinking, drafting, and review layer. Automation belongs closer to the execution, validation, and repeatability layer.
That distinction is not academic when the thing being changed is a network.
Networks punish vague intent
Network changes often look smaller than they are.
A prefix list gets one more entry. A BGP policy gets adjusted. A firewall rule moves from a narrow exception to something broader. A site template gets copied for another location. An interface description changes. A VLAN gets added. A routing change is supposed to affect one path but ends up changing the preferred path somewhere else.
None of those examples need to sound dramatic to matter.
The risk is often in the relationship between details: naming standards, route preference, config inheritance, site exceptions, shared services, monitoring expectations, rollback behavior, and who takes the first call if something breaks.
That is why mature network automation is not only about generating config faster. It is about controlling blast radius. It is about idempotence. It is about schema validation, linting, dry runs, diffs, peer review, integration tests, and rollback planning. It is about knowing whether the proposed change matches the intended change before it gets anywhere near production.
AI can help with many of those steps. It can draft the change plan. It can explain the expected impact. It can compare generated config against a standard. It can write a first pass at a test. It can summarize what changed in a pull request for the reviewer.
But the generated work still needs to pass through the same engineering controls.
Maybe stronger ones.
Generated work still needs a control plane
Two articles helped sharpen this for me, even though they are mostly framed around infrastructure as code rather than networking specifically.
William Collins argues for AI working through IaC, not around it, because the lifecycle management parts of the system still matter: state, plans, provider schemas, review, and organizational trust boundaries. Firefly makes a similar case that AI agents do not remove the need for IaC; they make the control plane more important because generated infrastructure changes still need visibility, policy checks, rollback paths, and auditability.
That maps cleanly to network engineering.
If an AI tool generates a device template, the useful question is not only whether the template looks plausible. The useful questions are more operational:
- Does it conform to the expected schema?
- Does it preserve naming and addressing standards?
- Does it produce a readable diff?
- Can it be tested against representative inventory?
- Does it behave the same way when re-run?
- What is the rollback plan?
- Who reviews the change before it reaches production?
- What telemetry tells us whether the change behaved as expected?
Those questions do not become less important because the first draft came from a model.
In some ways, they become more important because the cost of producing artifacts has dropped. When it becomes easier to create playbooks, policies, templates, and test files, the bottleneck moves. The hard part is less likely to be typing the first version. The hard part is knowing whether the generated thing is correct, appropriate, and safe in this environment.
That is still engineering work.
Guardrails are useful, but they are not automation
I do think guardrails matter.
Skills, prompts, agents, checklists, examples, and validation flows can make AI-assisted work much better. If a team has a standard way to build network change plans, it can encode that structure. If templates need specific sections, examples can teach the assistant what good looks like. If generated configs need to pass linting, schema validation, and dry-run checks, the agent can be taught to run those steps before handing work to a human.
That is real progress.
But I would be careful about confusing those guardrails with the automation system itself.
A prompt that says “follow our site template” is not the same as a tested template renderer. An agent that knows the checklist is not the same as CI enforcing it. A skill that describes the rollback pattern is not the same as a rollback that has been rehearsed. A generated test is not valuable because it exists. It is valuable if it actually detects the class of failure we care about.
The guardrails should help create, improve, and review the automation system. They should not become a softer substitute for it.
That is the part I expect teams to wrestle with. It is tempting to look at a capable AI workflow and feel like the old automation work got skipped. Maybe the agent can read the intent, generate the config, call the API, and report success. For a lab, a short-lived environment, or a low-risk experiment, that might be fine.
Production infrastructure is different.
For production, I still want the boring parts: Git history, code review, tests, diffs, policy checks, dry runs, controlled deployment, observation, and rollback. I want the change to be understandable by someone who did not participate in the original conversation with the AI tool. I want the system of record to outlive the chat thread.
That is not anti-AI. That is just respect for operations.
The better version
The best version of this is not AI instead of automation.
It is AI helping engineers build, understand, and maintain better automation.
That might mean using AI to refactor a brittle playbook, explain an unfamiliar Terraform module, generate test cases for a network policy change, compare intended state to observed state, summarize a complicated diff, or help a reviewer find the part of a change that deserves closer attention.
It might also mean using AI to make automation more approachable. A lot of infrastructure automation fails quietly because only one or two people understand it well enough to change it. If AI can help more engineers understand the intent, structure, and failure modes of the system, that is valuable. Not because the model owns the automation, but because it helps the team reason about it.
That is where I am landing for now.
AI-assisted network engineering is not network automation. It is a layer around the engineering workflow that can make automation easier to write, review, explain, and improve.
But the discipline of automation still matters. Maybe more than before.
If generated work becomes easier to produce, then validation, review, and operational judgment become more important, not less.
References: