I’ve been saying for ten years that network automation was three years away from being the only way to do things. Every year I moved the goalposts, because the data never caught up to the rhetoric. After a decade of scripts, YAML, Ansible, Terraform, and every NetDevOps framework we could throw at the problem, roughly 70% of enterprise networks are still managed by hand.
The industry’s explanation for that has always been some version of “those teams just haven’t gotten with the program.” I don’t think that’s right. I think we built the on-ramp wrong.
The On-Ramp Was Never Going to Work
To automate the network the old way, we asked a 25-year network engineer to also become a proficient software developer: fluent in a programming language, comfortable with source control, capable of writing automation that survives contact with production. We asked them to pick up a second career on top of the one they already had, which was keeping the network so stable that nobody noticed it existed.
The best day a network engineer can have is the day nobody calls them. We built the entire discipline around stability and predictability, then asked the same people to ship production-grade software on the side. The math was never going to work, and blaming the engineers for not doing the math was never fair.
Writing Configs by Hand Is a Solved Problem
What changed isn’t the underlying capability. It’s the interface. When an engineer describes what they want in plain language and an agent handles the translation, the expertise doing the real work is still the engineer’s. Fifteen or twenty years of judgment about how a network should behave doesn’t move to the model. It just stops getting filtered through a programming language the engineer never trained in.
That matters because every hand-typed change is a chance to introduce a human problem that has nothing to do with engineering skill. A fat finger. A missed step. A redundancy pair only half configured because the second command got typed at 2 a.m. and nobody caught it until morning. Automation was always supposed to take that risk out of human hands. We just never made the on-ramp easy enough. We do now.
The Job Isn’t Disappearing. It’s Becoming Management
The next decade of network engineering isn’t about engineers being replaced. It’s about engineers running a fleet. One agent handles documentation. One handles compliance checks. One triages tickets. One sits read-only, gathering the data the others need. The engineer’s job shifts from typing the change to defining the agent, setting its guardrails, watching its work, and deciding when it’s earned more scope.
NVIDIA CEO Jensen Huang described this as IT eventually needing something like an HR department for agents, and I think network engineers are better positioned for that role than almost anyone else in IT. We already troubleshoot in layers. We already design for redundancy. We already operate in environments where a single mistake takes down a business. Managing a fleet of agents is going to feel more familiar to a senior network engineer than it will to most other technical roles.
Trust Has to Be Graduated, Not Granted
Nobody should hand an agent production access on day one, and nobody has to. Start with read-only work: documentation, compliance checks, source-of-truth reconciliation, testing. None of it touches production, and all of it delivers value immediately. If you’ve ever put a new hire’s first two weeks toward updating the network diagrams that never matched reality, you already know this playbook.
Let trust build the same way it would for a person. A quarter of clean documentation and compliance runs might earn the agent the ability to propose a change a human approves. Another quarter of that might earn it the ability to make the change and prove it worked. Eventually, routine tickets close without a human in the loop at all. It’s the same onboarding curve you’d use for a junior engineer, applied to software instead of a person.
Leverage, Not Loss
When Excel arrived, accountants didn’t disappear. The manual reconciliation and line-by-line calculation moved to the spreadsheet, and accountants moved up into work that required judgment. I think the same shift is coming for network engineering, and I think it happens faster than most people expect.
If you’re an engineer who has been waiting for the right moment to get into this, the moment is now, not because you’re behind, but because almost nobody is ahead. Spec-driven development is roughly six months old. MCP is barely a year old. Pick one read-only use case your team has been meaning to get to for years and build an agent that does that one thing. Watch it work. Then build the next one. That’s how the role changes: one agent at a time, not all at once.