Spec First, Agents Second
Why we build software with Spec-Driven Development, and why it matters most when the stakes are regulated.
By Justin Grammens
Welcome to the new Lab651 website. It felt right that the first post here should be about the idea at the center of how we work: write the specification first, and let the AI agents come second. It’s the discipline behind our focus: software engineering for regulated industries.
Speed goes up. Quality quietly collapses.
AI has made writing code cheap. An agent can scaffold a service, generate tests, and wire up an API in the time it used to take to read the ticket. That is genuinely useful, and we use it every day.
But typing was never the hard part of software. The hard part is deciding exactly what the system should do, and then proving that it does it. When code gets cheap and that question stays fuzzy, you get the failure we keep seeing: velocity climbs, and quality erodes quietly underneath it. Nobody notices until something important breaks.
“Vibe coding,” prompting until something seems to work, is fine for a weekend prototype. It is not how you build software that someone’s health, money, or livelihood depends on.
What Spec-Driven Development is
Spec-Driven Development puts the specification in charge. Before an agent writes a line of code, we write down what the system must do, precisely enough that a person or a machine can check the result against it.
The flow is simple:
- Specify: what it must do, with clear acceptance criteria.
- Plan: how we will build it.
- Tasks: small, reviewable steps.
- Build: AI-assisted, and owned by an engineer.
- Verify: checked against the spec, not against a feeling.
Every change traces back to a specification. The spec becomes the single source of truth, and the AI becomes what it should be: a fast, capable assistant working inside clear boundaries.
Why it matters most in regulated industries
In healthcare, insurance, financial services, and retail, “it seems to work” has never been an acceptable answer. An FDA auditor wants to trace a requirement to its implementation. IEC 62304 expects a software lifecycle that accounts for risk at every stage. A SOX auditor wants to know who decided what, and why.
Teams in these industries usually treat documentation as a tax paid at the end of a project. Spec-Driven Development turns that around. Because the work starts with a specification and every change traces back to one, the audit trail is produced as the software is built, not reconstructed afterward. When the regulator asks for evidence, it already exists.
That is also why regulated teams have been slow to adopt AI, and why this approach unblocks them. The worry is never that AI is too slow. The worry is losing control of what the system is supposed to do. A specification gives that control back.
It’s a discipline, not a tool
People often ask which tool we use. GitHub’s open-source Spec Kit is one of them, and it’s a good one. But the tool matters less than the discipline: specifications first, executable and reviewable specs, and an engineer who owns every AI-assisted output.
We pick the tooling that fits your process and your regulator, not the other way around.
What this looks like when we work together
Every Lab651 engagement follows the same shape:
- Discovery first. We learn the problem, the constraints, and what success looks like, and we end with a well-defined scope.
- Specify before we build. No spec, no build.
- AI as co-pilot. Agents handle the scaffolding and repetitive patterns. Engineers review, validate, and own the result.
- Transparent delivery. You see progress and problems while there is still time to act on them.
It isn’t the fastest way to produce code. It is the fastest way we know to produce software that holds up.
Go deeper
- Watch the talk. I walk through Spec-Driven Development on a medical device project in Beyond Vibe Coding: How Engineering Leaders Scale AI in Regulated Industries.
- Read the code. Slides and code from my Open Source North 2026 talk, “Spec First, Agents Second,” are on GitHub.
- Read the book. Software Development Done Right lays out the principles behind every engagement. It’s available by invitation.
If your team wants the speed of AI without losing control of what you’re building, let’s talk. We’re happy to start with a 30-minute conversation, no sales pitch.
And if you’ve ever wondered about the name: 651 is Saint Paul’s area code. We’re glad you found us.