Are Network Engineers Addicted to the CLI?
In the networking community, there's ongoing debate about the role of Command Line Interfaces (CLIs) in network operations. A recent discussion in the Network Automation Forum (NAF) Slack workspace explored whether network engineers are "addicted" to the CLI - either through process familiarity or nostalgia. This blog post summarizes the key insights shared by various community members.
The Current State of CLI Usage
According to the NAF community discussion, CLIs remain deeply embedded in network operations culture. Several members pointed out that despite predictions of GUIs replacing command lines, CLIs continue to be the primary interface for many network engineers. As Mark Prosser—who kicked off the lively discussion—noted, network certifications were built around applying domain knowledge via CLI, which has reinforced this approach.
Many participants observed that even in highly automated environments, CLI still plays a critical role:
Eduardo Pozo mentioned that even in advanced automation engagements aiming for 100% automation, "there is ALWAYS CLI involved" - whether due to lack of API support, one-time configurations, or handling non-standard services.
Ryan Shaw noted that CLI becomes less frequently used when proper tooling is in place, but remains essential for troubleshooting edge cases.
Historical Context
Anna Claiborne provided historical context for this CLI dependency:
Cisco's IOS started as a research project before modern APIs were common (described as "by accident")
Cisco then "purposely did not add an API and invented certifications to make their product sticky and create a walled garden" (described as "by design")
When Google requested better APIs in the early 2000s for management at scale, they eventually built their own switching hardware and software when their needs weren't met
Cisco certifications embedded CLI mastery deeply into the "psyche of network operators," making it almost "sacred knowledge"
The CLI's Evolving Role
Several participants suggested that modern systems are evolving toward a balance:
Wim Henderickx noted that "In a modern system the CLI is a representation of the API. It is a convenience [function] for many people that are used to it."
James Henderson made the important distinction between interface method (CLI vs. GUI) and abstraction level. He described network equipment CLIs as "mini declarative language[s] of device level intent" where operators declare "what" the configuration should be, not "how" to implement it.
The Ideal Approach
The discussion pointed toward a balanced approach that leverages multiple interfaces:
James Henderson suggested that "an ideal network automation system supports a CLI for human interactions, a GUI for sales presentations and an API for integration to other systems."
Anna Claiborne emphasized that "an API is really just a different form factor of a CLI that is more standardized and machine accessible."
Several members suggested that systems engineering has achieved a good balance, using CLI primarily for emergency troubleshooting while relying on automation tools for routine operations.
Moving Forward
The consensus among NAF members seems to be that moving beyond CLI dependency requires:
A change in mindset among network operators
Significant changes from vendors to provide better APIs and alternatives
Focusing on first principles - understanding what operators need to accomplish and building intuitive interfaces
As the discussion highlighted, there's likely a middle ground where CLI remains valuable for certain operations while automation handles routine tasks - similar to how the systems engineering world has evolved.
This blog post represents opinions and insights shared by NAF community members and doesn't necessarily reflect industry consensus or best practices. It does, however, provide valuable perspective on the ongoing evolution of network operations interfaces.
