Spec-Driven Development Went Mainstream. The Specs Still Start Blank.

GitHub's Spec Kit crossed 117,000 stars this month. Spec-driven development - writing a structured spec before an AI agent touches code - went from niche idea to the way serious teams ship with AI. The toolkit's own pitch says it plainly: focus on product scenarios and predictable outcomes "instead of vibe coding every piece from scratch." We agree completely. There is just one thing every spec-driven workflow still gets wrong.

What Spec-Driven Development Actually Fixed

For two years the default AI workflow was a prompt and a prayer. You typed a paragraph, an agent guessed, and you cleaned up the mess. Spec Kit formalized the alternative: a constitution, a spec, a plan, a task list, then implementation. Define the what and why before the how. More than 30 coding agents now plug into it. The result is fewer wrong builds and far less rework. The industry finally agrees that specifications matter again.

Where Every Spec Still Starts: Blank

Open Spec Kit and the first real step is the specify command. You describe what you want to build, in that moment, from memory. The example in the docs is "build an application that can help me organize my photos in separate albums." That is the gap. The spec is only as good as what you remember to type. Your product vision is not in there. Your strategy guardrails are not in there. The discovery finding from six weeks ago that says users abandon at album creation is not in there. The format captures intent, but only the intent you can recall at the keyboard.

A Structured Spec From Shallow Context Is Still Shallow

Spec Kit's own philosophy calls for "rich specification creation using guardrails and organizational principles." That is exactly right, and exactly the part a CLI cannot generate for you. Guardrails and principles do not live in a slash command. They live in your product thinking: vision, strategy, OKRs, and the learnings from everything you have already shipped. If none of that reaches the spec, you get a beautifully structured document built on whatever was top of mind that morning. The container improved. The contents did not.

The Missing Layer: Live Product Context

This is the half Delvyn Studio handles. Your vision, strategy, OKRs, discovery findings, and past learnings stay in one place and stay current. When you write an agent spec, it inherits that context automatically before it ever reaches a coding agent:

• The strategic why - how this feature ties to the objective it is meant to move
• Guardrails - the constraints and non-goals you have already decided against
• Prior learnings - what surprised you the last time you built something adjacent
• Current OKRs - so the spec is checked against the outcome it is supposed to drive

What This Looks Like in Practice

Maya leads product at a 20-person fintech. Her team adopted Spec Kit for every feature and the structure helped right away. But specs kept drifting from strategy, because each one started from whatever the engineer typed into the specify command. She connected the team's vision, OKRs, and discovery notes in Delvyn Studio and now generates the spec from there first.

“The structure was never our problem. The context was. Now the spec already knows our guardrails and what we learned last quarter before anyone runs a single slash command.”

Spec Kit and Delvyn Solve Different Halves

This is not Spec Kit versus Delvyn Studio. Spec Kit structures the build: spec, plan, tasks, implement. Delvyn Studio structures the thinking that should feed the spec in the first place. One gives you a repeatable workflow. The other makes sure the input to that workflow carries your real product context instead of a blank prompt. Generate the spec in Delvyn, then push it to GitHub or Linear and let Claude Code, Copilot, or your Spec Kit pipeline execute it. Use both.