Most enterprise network changes are still typed by hand. A recent DevOps.com article by John Capobianco puts the share at roughly 70% of enterprise networks. That is his estimate, and we have not verified it. Network teams have had automation tools for about a decade, so the question is why adoption stayed low and what a workable starting point looks like. This article summarizes his argument, describes one documented automation project from a data center migration, and lists steps for teams that want to start.
What the article argues
- Traditional automation asked network engineers to become software developers while also keeping the network stable. The author’s view is that this on-ramp was the problem, not the engineers.
- AI agents let an engineer describe a change in plain language. The engineer’s judgment still determines the outcome.
- The engineer’s role shifts from typing changes to defining agents, setting their guardrails, and reviewing their work.
- Trust should be graduated. The author’s sequence is: (1) read-only work such as documentation, compliance checks, source-of-truth reconciliation, and testing; (2) proposing changes that a human approves; (3) making changes and proving they worked; (4) closing routine tickets without a human in the loop.
The piece is an opinion article. The author also describes adoption as early.
A documented example
During a data center migration, Ahead built an automation platform for bulk firewall-rule changes for a client. The client is confidential.
| Measure | Before | After |
|---|---|---|
| Throughput | ~800 rules per person-day | 2,000+ rules per minute |
| Engineering effort | 316 person-days | Under 1 person-day |
| Accuracy | ~90% | 99%+ |
Other results:
- A projected 6-month migration delay was avoided.
- First-year savings exceeded US$3 million.
- The freed engineers were reassigned to other project work.
This was an automation platform built for one defined task. The figures apply to that task and should not be read as results for agent-based tools in general.
What the two have in common
Both replace repetitive manual entry with a system that does it faster and more consistently. The engineer’s work moves toward defining scope and checking results.
The accuracy figure is the important one in regulated environments. The article makes the same point about hand-typed changes: a missed step or a half-configured redundancy pair is a risk that has nothing to do with engineering skill.
Controls still apply. In the regulated financial-services environments we work in, changes go through change advisory boards, segregation of duties, and audit review. Automation does not remove those. The graduated model above fits inside them: read-only, then propose, then approve, then execute.
Risks
- Automation increases the speed of correct changes and incorrect changes equally. A wrong rule set applied in bulk is a larger problem than one wrong rule typed by hand, so validation before execution is required.
- Read-only tools still need access. The scope of that access should be defined and logged.
- The 70% figure and the timelines in the article are the author’s. Treat them as unverified.
Recommendation
The simplest approach for a network team starting out:
- Pick one read-only task already on the backlog, such as diagram reconciliation, configuration compliance checks, or documentation updates.
- Measure the baseline first: time per task and error rate. A before-and-after comparison like the table above requires a measured starting point.
- Write down the guardrails: what the tool can read, what it can change, and who approves.
- Move to proposed changes with human approval only after a period of clean read-only results. The article suggests about a quarter per stage. Set your own interval based on change volume and risk.
- Keep change management, segregation of duties, and the audit trail in place at every stage.
- For the first write-access use case, choose the highest-volume repetitive change type, such as bulk firewall rule changes during a migration.
The goal is not to eliminate oversight but to reduce manual effort.
Sources
- Capobianco, John. “From Operator to Agent Manager: The Real Shift in Network Engineering.” DevOps.com, August 31, 2026. devops.com
- Ahead internal case study (client name confidential)