Stop Writing CLI — Start Validating Design

Chun Fung Wong
May 19
3 min read

Updated: May 19

The Project That Triggered This Post

Recently, I was assigned to a mid-scale network migration spanning three data centers.

The architecture was straightforward but labor-intensive: it involved dozens of VRFs, hundreds of point-to-point BGP sessions in a BGP fabric, and a VMware NSX overlay. Despite this modern setup, I was asked to manually write all of the configuration changes as CLI.

After coding over 6,000 lines of CLI that night, I paused to reflect:

Should network design in 2025 still rely on manual CLI output?

Are we truly addressing the core architecture, or merely throwing syntax at complexity? In hindsight, a better question would have been:

Could we design this multi-site data center fabric in a more automated, intent-driven way from the start?

The Real Problem: We’re Designing Backwards

The network itself wasn’t broken—but the approach was. In this case, the team had been:

Manually subnetting point-to-point IP addresses in spreadsheets or Notepad.
Copy-pasting BGP neighbor configurations with only ASNs changed.
Dispersing route-redistribution logic across individual devices.
Adding a VMware NSX overlay as another abstraction layer that didn’t actually reduce complexity.

In short, the design lacked any intent-based modeling. The CLI commands became both the glue holding the solution together and the scapegoat for its shortcomings.

Manual IP Subnetting is Outdated

In today’s networks, manually calculating point-to-point subnets is no longer necessary. Instead, define IP address pools and automated assignment policies so software handles the math. After all, in our API-first, cloud-first, infrastructure-as-code world, we shouldn’t still be solving BGP mesh addressing with “spreadsheet math.” This approach isn’t just slow—it’s architecturally obsolete.

The Role We Should Play

As network architects, our job is not to churn out configuration lines. We’re hired to design and validate solutions. Specifically, we should:

Validate and verify the design logic.
Model configuration intent.
Align the topology with business and security requirements.
Build networks that are scalable, observable, and automatable.

In other words, it’s time to stop being mere config writers and become design validators. We need to demonstrate our problem-solving and architecture skills, not just our typing speed.

What Needs to Change

Technically:

Use centralized IP pools and templates instead of spreadsheets or manual subnet calculators.
Automate config generation (for example, using Python or Jinja2) driven by structured intent (YAML/JSON).
Leverage design metadata (such as network intent models) to generate configurations rather than relying on manual memory.
Invest in modern networking architectures, like software-defined fabrics (Cisco ACI, EVPN-VXLAN, etc.), to simplify multi-site designs.

Culturally:

Resist quick-fix requests like “just give me the config.” Instead, steer the conversation toward the design.
Respond with partnership: e.g., “Let me review the design logic first and deliver a reusable configuration model.” This shows you’re focused on long-term value.

If You’re Still Writing CLI Manually…

Consider this hard truth: if you’re typing every line by hand, you’re proving you can type, not that you can think. Don’t let years of network experience be reduced to syntax. Focus on delivering strategic value, not just filling in variables.

Conclusion: Be the Strategic Advisor, Not the Keyboard Resource

Often we hear the plea: “Hey, can you just generate the config for us?” Here’s a better response:

“Yes—but let me first review the design so I’m not just fixing symptoms.”

“Let’s align on the architecture model so we don’t end up creating another one-off solution.”

Because the future of network design isn’t more CLI—it’s better context, consistency, and smarter delivery. Let’s raise the bar, one design at a time.