Network Engineers: You’ve Been Doing Spec-Driven Development for Years, You Just Didn’t Know It

Let me tell you what a network engineer does before touching a device.

They gather requirements. They document the current state. They define what the network needs to do after the change – and what it must never do. They get stakeholder sign-off. They write a test plan. They build rollback procedures. And only then – only after all of that upfront work – do they make a single change.

That’s not called spec-driven development in our world. We call it “doing your job.”

In software engineering, they named it. They built frameworks around it. They argued about it at conferences. And now, as AI enters the picture and the concept is migrating from application development into infrastructure and network automation, there’s a reasonable chance you’re reading about SDD for the first time and thinking: this is new to me.

It’s not. The discipline has always been yours. It just didn’t have a name.

What Is Spec-Driven Development?

Spec-driven development (SDD) is an operating model for building automation – and increasingly, for building AI agents – that front-loads intent before anything gets built or executed.

The core principle is simple: lock what you want the system to do before you let it do anything.

In practice, SDD works as a sequence of structured phases:

• Constitution – the values, constraints, and guardrails that govern everything downstream. What the system must always do. What it must never do. Who it serves. What it protects.
• Specifications – the detailed, explicit description of what you’re building. Inputs, outputs, behaviors, edge cases, error conditions. Written in natural language, not code.
• Tasks – the discrete, ordered work items derived from the specs. This is the plan the system will execute.
• Implementation – only now does anything get built. The code, the configuration, the agent actions – all of it driven by what was written before.

Notice what’s missing from that list? Improvisation. The model – whether that’s a human developer or an AI agent – doesn’t get to decide anything that wasn’t already decided in the spec. Its job is to execute intent, not invent it.

That’s what makes SDD so well-suited to infrastructure. And it’s why network engineers, despite never having heard the term, are arguably the most naturally prepared practitioners to adopt it.

Why This Matters Now

Here’s the problem that SDD is solving in 2026.

AI can write code. It can write it fast, and for many tasks, it writes it well. That has created a tempting shortcut that’s already common in software circles: describe what you want, watch the model generate it, ship it.

This approach has a name – vibe coding. And for side projects, demos, and weekend experiments, it works fine.

For infrastructure, it’s a liability.

The reason isn’t that AI is bad at writing network automation. It’s that LLMs are probabilistic and infrastructure is not. Point an AI agent at a BGP session, a firewall policy, or a device configuration without structural guardrails, and you’ve introduced non-determinism into a system that doesn’t tolerate it. The model might do the right thing nine times out of ten. The tenth time is the outage.

SDD bridges that gap. The constitution, the specs, the tasks – those aren’t overhead. They’re the constraint layer that turns a probabilistic system into something your production environment can trust.

The human writes the intent. The model executes it. Nothing touches infrastructure that wasn’t explicitly governed before it ran.

What Spec-Driven Development Looks Like in Practice

When I started building NetClaw – a network-focused AI agent built on top of OpenClaw – I learned this lesson the direct way.

One of the first things I built was a soul file. That’s the SDD equivalent of a constitution: a set of hard guardrails written in plain English that the agent treats as inviolable. Things like:

• Never apply an ACL that would block management traffic.
• Never change an enable secret unless explicitly instructed to.
• Never make a configuration change that could lock the operator out.
• On every session, gather device state and cross-reference against the source of truth. Flag discrepancies before acting.

None of that is code. It’s intent, written down, that the agent references before it does anything. It’s requirements engineering – the same thing network architects have been doing for decades – applied to an AI agent.

Then came the tools file: a structured description of how the agent uses each capability available to it. And the user file: context about the human operator the agent is serving. And the heartbeat file: an instruction that tells the agent to check in via Slack or WebEx at regular intervals, like a junior engineer reporting status to their senior.

Every one of these artifacts is a spec. Together, they define what the agent is, what it can do, what it won’t do, and how it communicates. That’s SDD – not as an abstract methodology, but as the actual structure that makes a network agent safe to run.

I opened NetClaw live to 600 network engineers and infrastructure practitioners in the VibeOps Forum Slack. Within minutes, 35 social engineering attempts came in. People trying to get the agent to violate its own constraints – bypass guardrails, escalate privileges, take destructive action.

The soul file held. Because the spec said it would. That’s the payoff you get from doing the upfront work. Not guardrails bolted on after the fact. Governance designed in from the start.

How Itential Is Building With Spec-Driven Development

At Itential, we don’t just talk about spec-driven development – we’re using it to build the tools we ship to practitioners.

The Itential Builder Skills are a library of Claude Code skills built specifically for network and infrastructure automation workflows. Each skill is a structured, spec-driven instruction set that tells the model exactly what to do, how to do it, and what guardrails apply – before any code gets generated.

These skills are available in the Anthropic Marketplace and in our public GitHub repo at: github.com/itential/builder-skills. They’re practical, open, and built the way we think automation tooling should be built: spec first, execution second.

If you want to see what SDD looks like applied to real network automation workflows, not in theory but in working artifacts, that repo is the place to start.

The MCP Layer: SDD First, Connectivity Second

If SDD is the structure, Model Context Protocol (MCP) is the connectivity.

MCP is the protocol that lets AI agents communicate with external tools and systems – your network devices, your source of truth, your ITSM platform, your observability stack. It’s how an agent stops being a chatbot and starts being an operator.

I’ve catalogued 56 infrastructure-relevant MCPs that I’d consider trustworthy, viable, and useful – sources of truth like NetBox, Nautobot, and InfraHub; device vendors including Arista, Cisco, and Juniper; observability platforms; and ITSM systems.

Of those 56, exactly one is an official vendor release. The rest are community projects.

That tells you something important about where the market is right now. Community is moving faster than enterprise. The engineers who understand this moment – who can evaluate an MCP, wrap it in a well-governed spec, and put it to work safely – are the ones who will be the most valuable practitioners in the next phase of network operations.

But here’s the thing: MCP without SDD is just giving an AI agent access to your infrastructure with no structure around what it does with that access. The spec is what makes the connectivity safe. SDD first. MCP second. In that order.

The Skills You Already Have

There’s a framing I want to push back on.

I keep seeing SDD positioned as a software engineering practice that network engineers need to learn. Like it’s another Python course, another certification, another body of knowledge that exists somewhere outside of what practitioners already know.

It’s not.

The engineer who spent fifteen years writing change management documentation understands requirements. The one who built rollback plans for every major configuration change understands failure modes. The one who went through three rounds of stakeholder review before touching a production MPLS topology understands governance.

What SDD gives those engineers is a framework that formalizes what they already do – and extends it into the AI era. The model does the building. The engineer drives the intent. The spec is the interface between human judgment and machine execution.

And the engineers I’ve seen struggle most with AI agents aren’t the ones who spent years with their hands on devices. It’s the ones who want to skip the structure and get to the output fast.

In infrastructure, that instinct has always been dangerous. SDD is the reason why.

Where to Go From Here

And if you want the full SDD operating model – what each phase looks like, how it connects to agentic operations, how network engineers are putting it to work today – read the definitive SDD guide.

If you’re heading to Cisco Live US in Las Vegas, come find me in the VibeOps Lounge by Itential. I’ll be running live SDD demos – real agents, real infrastructure, real specs. It’s a session where you can actually get your hands on the tooling rather than just hearing about it.

You’ve been doing this work longer than you realize. SDD is just the name we’re finally giving it.