From hours to seconds: automating network topology design

Give us an address, and our job is to build a reliable, performant, and safe network for it. Our customers’ networks are critical infrastructure, and the quality of a network is largely determined by the quality of its install.

Before we can install a network, we have to design what’s called a topology for it: a design that both designates the precise count of devices, cable types, and peripherals a site needs and describes how each one of them connects and gets configured to bring the site online.

Errors at this stage are expensive. An errant connection, an extra device, or a mislabeled port leads to delayed installs, incorrect shipments, and a painstaking on-site validation process.

The work is also tedious and brittle. Until recently, our deployment engineers created network topologies by hand in Lucidchart, and complex deployments like school campuses could take tens to hundreds of hours. The resulting diagram existed outside of Dashboard, where we operate and deploy networks. If we made an update to a customer’s topology requirements, we needed to relabel every downstream device by hand—then compare a static drawing to a live network, step by step, hoping we didn’t miss anything.

This manual work simply won’t scale to serve our customers. So, we built an automated topology designer in the Meter Dashboard that 1) turned a site’s specific requirements into a valid, deployable network design in a matter of seconds and 2) could accommodate updates to its design as both our and our customers’ businesses shift.

Below, we’ll walk through how it works, the questions we wrestled with as we built it, and why it allows us to deploy more and better networks at scale.

What we built

A deployment starts with determining what will deliver an excellent experience for the customer. For example, Meter dispatches a technician to visit the site and performs a site walk to figure out what the precise customer requirements are. There are many cases where the customers themselves don't know their own requirements, so we do that discovery with and for them.

Meter deployment engineers now use this and past deployments to describe what each site needs in the Dashboard—such as hardware model, quantity, port demand, switch counts, and ISP handoffs—instead of how those elements should relate to each other.

The system then applies Meter’s stepwise rules for a valid topology. For example, it will:

• Size hardware with appropriate headroom
• Create valid network and power topologies
• Apply approved network patterns
• Generate wiring and labeling details
• Validate the final design against Meter standards

After all applying rules, the topology tool returns a valid and deployable design in seconds.

The same pass also generates virtualized hardware devices in Dashboard, with labels for every device and port.

The same topology can also produce a rack elevation for installation and any future device changes. Because the same underlying data produces each output, deployment engineers no longer have to reconcile Lucidchart, device records, labels, and rack plans by hand. Fewer than 1% of topologies we design require post-generation changes.

How we built it

Distilling judgment

LLMs have ushered in a new era in software engineering, and we’re all still making sense of what this newfound power will mean for networks. What hasn’t changed is that as engineers, we’re ultimately responsible for the artifacts that we produce.

Conventional practice tells engineers to talk to your users, conduct user interviews, be wary of asking hazy or amorphous questions and ground yourself in the concrete and particular, or else you’ll be tricked.

We sidestepped that, armed with a UI from above, a rock-solid API below, and a burning queue of real customer networks to install on time and with utmost precision.

First, we needed to distill the decisions that experienced network engineers made when designing topologies. Alex, a network engineer at Meter, used a coding agent to build a prototype of the designer that expressed Meter design decisions as rules.

Sameer and Daniel on our engineering team then connected the prototype to Meter’s internal APIs, which constrained the prototype’s output to valid device and relationship records, and to Dashboard, where Alex could visualize each topology, iterate on any edge cases—like sites that required hundreds of switches—and refine the rules against existing Meter designs.

We called this the “vibe-code sandwich”: a domain expert prototyping in the middle, a production data model below, and a production interface above. This gave the team a closed feedback loop while keeping every output in a format compatible with Meter’s existing software.

Preserving judgment

Once Alex, sales engineering, quality engineering, and our hardware teams determined that the prototype was producing reliable designs, we then needed to reproduce the vibe-coded prototype’s behavior in our production system.

This was tricky. Alex and the team had encoded the prototype with hundreds of design rules and edge cases that weren’t captured in any written spec. Rebuilding the prototype from a description of those rules could produce topologies that were plausible yet different from the designs the team had refined. Plus, Alex built his client in Python, and we’re a Go shop.

An early design decision made this migration easier to verify: Daniel and Alex had required the prototype to produce the same topology for every input. So, we used the prototype’s outputs as the reference for the Go implementation.

Daniel generated 3,000 randomized and domain-specific site inputs and recorded the prototype’s output for each. He then ran the same inputs through the production version of the tool and compared the outputs. Each mismatch flagged a rule that hadn’t been reproduced in production, and these input-output pairs became characterization tests that the team could rerun after each change.

Evolving judgment

Since the topology designer’s rules would continue to change as Meter pushed new updates and hardware to our customers, we also needed to understand and test how each update to a given topology affected the resulting network.

So, we structured the production designer as a functional, immutable pipeline. Each stage receives the current topology, applies one group of design rules, and returns a new topology and leaves the previous version unchanged. This lets engineers test stages individually and trace the downstream effects of each change.

The core design also runs in a single forward pass without backtracking to revise or repair an existing topology. This keeps the growing test suite fast enough to provide timely feedback as we checked the validity of hundreds, then thousands, of designs.

Removing network design as a bottleneck

Now that our deployment engineers can generate topologies in seconds, they can concentrate on more complex sites. Producing device records, labels, and rack plans from the same design also removes the manual reconciliation work that left installers working with inconsistent instructions.

Today, about 99% of designs require zero human correction, and any remaining edge cases are reviewed, fixed, and fed back into the system. Our customers won’t interact with this tool—and why should they?—but it’s become a fundamental input into their network uptime for years to come.

We’re building out more tools like this to scale our networks across millions of square feet. If working at the intersection of software, hardware, and operations interests you, join us.