I started my career on a NOC floor, watching alarms, reading syslog and following runbooks. Fifteen years later I design data center and hybrid cloud networks. In that time the job has changed shape several times – from the CLI to controllers, from hardware boxes to cloud VPCs, from hand-typed changes to pipelines. AI is the next change, and it is the biggest one yet.
So is there a future for network engineers in the age of AI? Yes – but it is not the same job. This is how I see it, as someone who uses AI tools in real network work every week.
In short: AI will take over much of the reading, typing and first-draft work in networking. Engineers who combine strong fundamentals, automation skills and the judgement to verify what AI tells them – and who learn to build networks for AI – will be in more demand, not less.
Will AI replace network engineers?
No. But it will replace a large part of what many network engineers spend their day doing.
A lot of network work is reading and typing: reading configurations, logs and show output, and typing commands, tickets and documents. Large language models are very good at exactly that. What they do not have is accountability, knowledge of your business, and certainty. The network carries everything else in the company – when it breaks, everything breaks. Someone has to own the decision, and that someone is still an engineer.
Replacement is the wrong thing to worry about. The bigger shift is the gap that opens between engineers: one with an assistant reading the logs and drafting the change finishes in an afternoon what takes a colleague several days. Hiring managers will notice that gap long before any role disappears.
What AI already does well in network work
- Reading at machine speed. Give it a 3,000-line configuration or a page of
showoutput and get a summary, the differences from a baseline, or the line that looks wrong. - A second pair of eyes when troubleshooting. Describe the symptoms and the evidence, and get a ranked list of hypotheses with the commands to test each one.
- Drafting. Methods of procedure, pre-checks and post-checks, rollback plans, design documents and change tickets – a good first draft in minutes.
- Translating. Cisco to Juniper, one firewall vendor to another, CLI to Terraform or Ansible – as a first draft for an engineer to review.
- Writing automation. Python scripts, Ansible playbooks, Terraform modules, Jinja templates and regular expressions, with explanations.
- Finding patterns in telemetry. AIOps platforms correlate alarms, flag anomalies and cut alert noise far better than static thresholds.
- Acting through tools. With the Model Context Protocol (MCP) and similar frameworks, an assistant can call real tools – run a
showcommand, list the VPN connections in a cloud account, check BGP state – and reason over the results.
That last point is the big shift. In my own work I use an AI assistant connected to read-only tools that can query routers, firewalls and cloud accounts. A question like “why is this BGP session down?” turns into the assistant running the right show commands on the right devices and laying out the evidence. I still check the conclusion, but the legwork takes minutes instead of an hour.
What AI does not do – and why you still matter
- It can be confidently wrong. Models invent commands, mix up platform syntax and misread output. In networking, a plausible-looking wrong command can take down a site.
- It does not know your context. Why that odd static route exists, which application cannot survive a failover, what the business will accept during a change window, what the budget is.
- It does not own the outcome. Change approvals, audits, incident reviews and customer conversations need a person who is accountable.
- It struggles with the truly new. A firmware bug, a failing optic, an asymmetric path that only appears under load – new failures need someone who understands how the protocols really behave.
- It cannot make your trade-offs. Cost against resilience, simplicity against flexibility, speed against risk. That is design work, and design is a human decision.
How the role is changing
| Task | Yesterday | With AI |
|---|---|---|
| Troubleshooting | Log in to each device, run commands, read the output | The assistant gathers evidence across devices; the engineer tests hypotheses and decides |
| Configuration | Typed by hand or copied from an old change | The engineer defines intent, AI drafts, a pipeline validates and deploys |
| Documentation | Written after the fact – if at all | Generated from configurations and the source of truth; the engineer reviews |
| Monitoring | Static thresholds and alert floods | Anomaly detection and correlation; the engineer tunes and investigates |
| Design | The engineer researches and writes everything | AI compares options and drafts; the engineer owns the trade-offs |
| Learning | Books, labs and forums | All of those, plus an always-available tutor – whose answers still need checking |
The pattern is the same in every row. The engineer moves from doing each step to defining the goal, checking the result and owning the decision – less operator, more reviewer, designer and builder of systems.
The other side: networks built for AI
AI does not only change how we run networks. It is creating a whole new class of networks to build. Training and serving large models needs GPU clusters, and those clusters live or die by the network.
- Back-end GPU fabrics connect thousands of GPUs over 400G and 800G links, often in rail-optimised leaf-spine designs, where one slow link can stall an entire training job.
- Lossless Ethernet with RoCEv2 depends on PFC, ECN and congestion control being tuned correctly – a skill set few engineers have today.
- Ethernet or InfiniBand is an active architecture debate, and the Ultra Ethernet Consortium is pushing Ethernet further for AI workloads.
- Hybrid and multi-cloud connectivity matters more as data pipelines move training data between on-premises storage and cloud GPU capacity – the kind of AWS-to-data-center connectivity many enterprises already run.
- Inference in the enterprise and at the edge brings AI traffic onto campus, WAN and branch networks, with new demands on latency, segmentation and security.
If you already know data center fabrics, BGP EVPN, QoS and buffer behaviour, you are much closer to this world than you might think – years of running Cisco ACI data center fabrics taught me far more about this than any AI course could. It is one of the best growth areas in networking right now.
Skills that matter more than ever
- Deep fundamentals. You cannot check an AI’s answer about BGP path selection, OSPF areas or an MTU problem if you do not understand them yourself. AI raises the bar here: whoever reviews the work has to know more than the tool that produced it.
- Python, APIs and structured data. JSON, YAML, REST and gNMI are how tools – and AI agents – talk to networks.
- Source of truth and automation. Git, a source of truth such as NetBox, Ansible or Terraform, and CI/CD pipelines with tests (see my Cisco ACI automation case study). AI makes changes faster; this is what makes them safe.
- Telemetry and observability. Streaming telemetry, flow data and good logging. AI is only as good as the data you give it.
- Using AI well. Give it context, ask for evidence, verify every claim, and learn how to connect assistants to your own tools safely.
- AI infrastructure networking. RoCEv2, lossless Ethernet, GPU fabric design and high-speed optics.
- Security and governance. Access control for AI tools, data handling, and keeping secrets and customer data out of public models.
- Communication. Explaining trade-offs to managers, writing clear designs and leading reviews. The more routine work AI takes over, the more these human skills stand out.
Guardrails are part of the job
Letting AI loose on a production network without guardrails is how you get a very fast outage. These are the rules I follow:
- Read-only by default. Write access is a separate, narrow tool with an allow-list of what it may change.
- No secrets in the chat. Passwords, keys and customer data stay in the terminal or a vault, never in a prompt.
- Preview before push. A human reviews every generated change, with secrets masked.
- Order and verification in code. The tool enforces the sequence and checks the result on every device, instead of trusting the model to remember.
- Change control still applies. An approved change, a window and a rollback plan – exactly as for a change made by a person.
I will write about these guardrails in more detail in a future post.
Where to start this month
- Use an AI assistant for one real task a day – summarise a configuration, draft a method of procedure, explain an unfamiliar log – and check every answer against the device or the vendor documentation.
- Automate one repetitive task with Python or Ansible, and keep it in Git.
- Build a small lab with containerlab or Cisco Modeling Labs, and let an assistant help you break it and fix it.
- Read about AI data center networking – RoCEv2, PFC and ECN, rail-optimised fabrics – even if your current job does not need it yet.
Frequently asked questions
Will AI replace network engineers?
Not in the foreseeable future. AI is taking over much of the repetitive reading, typing and first-draft work – summarising configurations, drafting changes, correlating alarms. Design decisions, accountability for production changes, troubleshooting new kinds of failure and understanding the business still need an experienced engineer. The real risk is being outpaced by engineers who use AI well.
How are network engineers using AI today?
To summarise configurations and logs, suggest troubleshooting steps, draft methods of procedure and documentation, write Python, Ansible and Terraform code, and translate configurations between vendors. With the Model Context Protocol (MCP) and similar frameworks, assistants can also run read-only commands on network devices and cloud accounts. AIOps platforms use machine learning to detect anomalies and reduce alert noise.
What skills should network engineers learn for the AI era?
Strong fundamentals in routing, switching and security; Python, APIs and structured data such as JSON and YAML; Git, a source of truth and CI/CD-based automation; streaming telemetry and observability; using AI assistants safely; and AI data center networking, including RoCEv2, lossless Ethernet and GPU fabric design.
What is AI networking?
The term has two meanings. Networking for AI is the design of high-bandwidth, low-latency, lossless fabrics that connect GPU clusters for training and inference – typically 400G or 800G Ethernet with RoCEv2, or InfiniBand. AI for networking is the use of machine learning and large language models to operate networks: troubleshooting, anomaly detection, automation and documentation.
Is network engineering still a good career in the age of AI?
Yes. Every application, cloud service and AI cluster depends on the network, and AI infrastructure is creating new demand for engineers who understand high-speed data center fabrics. The role is shifting from typing commands towards design, automation and verification, so the best prospects are for engineers who build those skills.
The bottom line
AI will not take the network engineer’s job. It will take over the repetitive parts – the copy and paste, the log reading, the first draft. What is left is the interesting part: understanding how things really work, designing for the business, and owning the outcome. Engineers who lean into that will be more valuable than ever.
How are you using AI in your network work – or what is holding you back? I would like to hear about it. Get in touch or connect with me on LinkedIn.
