Blogs

Vibe Coding Grows Up: Inside Spec-Driven Development for Network Engineers

Head of AI & Developer Relations

Vibe Coding representation that shows the promise of spec-driven development in production.

Key Takeaways

- Why Spec-Driven Development (SDD) is what vibe coding grows up into
- Why network engineers already know how to do this, they just never called it that
- How the clarify step catches ambiguity you didn’t know you left open
- Why SDD ships tested code, not just working code
- How to mix models across steps to keep token costs under control
- Where Itential’s own SDD framework and Builder Skills fit once you’re ready to point this at your own network

A few weeks ago in Munich, I sat down with Andy Lapteff at the Art of Network Engineering podcast and built a fully functional subnetting trainer in about an hour. Browser based, 77 passing tests, 100% coverage on the engine. I did not write a single line of code by hand.

That is not the interesting part. Vibe coding can do that too, and often faster. The interesting part is that we could hand what we built to a stranger, and that stranger could read exactly what we asked for, why we asked for it, and how the system verified it works. Try that with a vibe coded prototype.

The difference is a practice called Spec-Driven Development, or SDD. It is not a product. It is a discipline, and it happens to map almost exactly onto how network engineers already work. It also happens to be something we have spent a lot of time on here at Itential, because it is the operating model our own platform enforces.

💡 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. It runs in five phases, Requirements, Feasibility, Design, Build, and As-Built, gated by two formal approvals: one that locks the requirements before any environment access, and one that locks the design before a build starts.

Every engagement ends with a reconciled as-built record, so what actually shipped, and why, survives past the person who shipped it. That is what makes automation trustworthy on Day 2, and what keeps an AI agent’s authority bounded to something a human actually approved.

Vibe Coding Is Not the Problem

Let me be clear about something up front. Vibe coding, describing what you want in plain language and letting an LLM write the code, works. It is a legitimate way to build things fast, and I use it constantly.

The problem is not the speed. The problem is what you are left holding. Unconstrained output, no test coverage, no record of why the model made the choices it made. It might run. You do not always know why, and six months later, neither does anyone else on your team.

That is fine for a weekend project. It is not fine for anything that touches production infrastructure.

This Is Just Change Management With a New Name

Here is what I told Andy on the podcast, and I will say it again here because it is the whole point. If you have ever planned a network change, you already know this workflow.

You gather requirements.

You write an implementation plan.

You define success criteria.

You write a rollback plan before you touch anything in a maintenance window.

Nobody in networking calls that a specification, but that is precisely what it is.

💡 SDD takes that exact instinct and applies it to how you work with an LLM.
Instead of discarding your requirements once the coding starts, the specification becomes the executable artifact. Everything traces back to it, in Git, in Markdown, readable by the next person who picks up the project.

The Six Steps We Used in Munich

Andy and I used GitHub’s open source Spec Kit alongside Claude Code, and the workflow broke into six steps, each landing as a Markdown file in the repo:

Constitution. The guardrails. Code quality standards, testing requirements, non-negotiables, set before a single prompt hits the model.
Specify. What you are building and why. Not the tech stack. Not the language. Just the requirements, written as user stories.
Clarify. The step most people skip and the one that matters most. The model reviews the constitution and spec, then asks up to five questions about the gaps and ambiguities you did not realize you left open.
Plan. Now, and only now, you choose the architecture and tech stack.
Tasks. A dependency ordered breakdown, generated automatically from everything that came before.
Implement. The code gets written. Tests get written first, then made to pass. This is the step that burns tokens, and the only one where I would reach for a more capable model.

Clarify Is the Step That Sold Me

Andy and I were building a subnetting game, and after the spec was written, the model came back with questions neither of us had thought to answer. What defines mastery: a streak of correct answers, a cumulative score, a checkpoint quiz? Does it teach a concept before testing it, or test cold? Is there time pressure, or does it measure passively? Andy’s answers were the obvious ones once he heard the questions out loud, a streak to advance, teach before you test, no timer. Obvious in hindsight. Neither of us had written any of it down.

None of that is code. All of it is the kind of ambiguity that turns into a rewrite two weeks into a project, or a support ticket six months after launch. Getting asked before the code exists, instead of discovering it after, is most of the value in one step.

Then We Actually Watched It Happen

It was not seamless, and that is worth saying out loud. Partway through implement, Claude Code hit a wall: Node.js was not installed on Andy’s machine. The agent could not fix that itself. It handed us a command, we pasted it into a second terminal, and we kept going. SDD does not make you a bystander. It just means the friction you hit is the ordinary friction of setting up a dev environment, not the friction of guessing what the model was supposed to build.

Eric Chou dropped into the recording partway through implement, while the agent was still grinding through tests, and made a point that stuck with me: the thing AI assistance actually cures is not skill, it is the blank page. He used to sit in front of unstarted code or an unstarted chapter and stall out. Now there is always something to react to, correct, and improve, even when the first draft is wrong. That is a different kind of help than writing the code for you. It is permission to start.

Implement is also where SDD shows its test-driven-development roots. The agent did not just write code and call it done. It wrote failing tests first, then wrote code to make them pass, then kept finding gaps in its own coverage and closing them without being asked twice. By the time it finished, we had 77 tests, all green, and 100% coverage on the subnetting engine itself. Neither of us had touched a line of it by hand.

And then we played it. Live, on the recording, two network engineers who between them have passed more Cisco exams than either of us wants to count, fumbling basic subnet math in front of an audience. That part was not scripted, and it was the best proof the whole exercise produced: the game worked well enough to embarrass us honestly, on the first try, with zero hand-written code behind it.

💡 Andy’s line at the end stuck with me more than anything I could have planned to say.
He was going to default to this from now on, not because vibe coding stopped working, but because an hour and a half spent this way produces something rigorously tested that he is comfortable handing to someone else.

Itential Already Runs This Playbook

GitHub’s Spec Kit is a great way to learn SDD on a side project, and if you have been following what we have been building at Itential, you already know we did not stop there. We turned SDD into the operating model the platform itself enforces: five phases with two formal approval gates instead of six informal steps, Requirements, a Gate 1 that locks intent in writing, Feasibility, Design, a Gate 2 that locks the execution contract, Build, and As-Built. No environment access happens until Gate 1 is approved. No build starts until Gate 2 is approved. Every engagement closes with an As-Built Record, so the next engineer, the next audit, or the next AI agent starts from a reconciled baseline instead of tribal knowledge. That is Governed Autonomy: the approved spec is the boundary an AI agent operates inside, not a suggestion it can quietly drift from.

If you want to try that discipline against your own environment instead of a subnetting game, we open-sourced Itential Builder Skills, a Claude Code plugin that runs this exact lifecycle against the Itential Platform.

Three agents own the five gated stages:

spec-agent owns Requirements and will not let anything move forward until the spec is locked
solution-arch-agent owns Feasibility and Design and surfaces platform constraints before a task is ever built
builder-agent owns Build and As-Built, implementing, testing, and documenting exactly what shipped.

It ships with 22 pre-built specs across networking, operations, security, and infrastructure, and instead of a repo you have to clean up afterward, it produces Workflows, Operations Manager entries, Configuration Manager assets, Lifecycle Manager resources, Itential Gateway services, and FlowAgents, tested and documented inside the platform.

Install is two commands: /plugin marketplace add itential/builder-skills then /plugin install itential-builder@itential-builder.

A Word on Cost

SDD is heavier on tokens than vibe coding, and you should plan for that rather than get surprised by a bill. The early stages do not need your most expensive model. Save the capable, expensive model for the build stage, where the actual code generation and test writing happens. Mixing models by stage is a real cost control, not a compromise.

Where to Start

Want to see the whole thing play out before you try it yourself? Watch the episode on demand and follow along play by play, timestamps and all, as we build the game live and unrehearsed.

Ready to Build Your Own?

Install GitHub Spec Kit, then clone the Networking Video Game Starter Kit we built off the back of this episode. It ships three template Markdown files, a constitution, a spec, and a plan, pre-loaded with the opinionated defaults that made our game work, plus a dozen topic and mechanic pairings if you do not have an idea yet. Fill in the three files, hand them to your agent in order, and 60 to 90 minutes later you have a playable prototype.

Want to build alongside people doing the same thing? Join the VibeOps Forum, the free Slack community founded for practitioners figuring out production-grade agentic ops before there is a playbook for it. No question too basic, no background required.

John Capobianco

John Capobianco is the Head of AI & Developer Relations at Itential, and a technology leader, developer advocate, and builder at the intersection of AI and network automation. With a career spanning enterprise, government, and cloud networking, John has held roles including Head of Developer Relations at Selector AI, where he focused on AI-driven observability, configuration intelligence, and autonomous network operations, as well as Cisco AI Technical Leader and Senior Network Architect for the Parliament of Canada / House of Commons. He brings deep, hands-on experience applying automation and AI in highly regulated, mission-critical environments. His work centers on helping large organizations adopt AI safely while maintaining reliability, security, and operational trust. John is a former professor at St. Lawrence College, an author, speaker, and educator. He is the author of Automate Your Network (self-published, 2019) and the Cisco Press pyATS book (2024). He regularly shares insights through talks, workshops, and the Automate Your Network brand, with a focus on practical, production-ready AI, developer empowerment, and the evolution of network engineering in an AI-first world.

Keep Learning