In Episode 13 of "Let it Cook," James Montemagno and Burke Holland host Den Delimarsky to introduce Spec Kit (github.com/github/spec-kit), GitHub's newly-released, open-source toolkit for spec-driven development. Den frames the idea as "prompt engineering on steroids": you invest upfront to encode the what and the why in a spec, then let the model handle the how. Live in VS Code, he walks the four-command loop — /constitution to set non-negotiable principles, /specify to write the feature spec, /plan to pick the tech stack, and /tasks to break it into workable chunks — before letting an agent implement a VS Code Insiders podcast landing page. The whole thing is "just scaffolding": markdown templates and shell scripts pulled in by a Python CLI (specify), with support for Copilot, Claude Code, and Gemini CLI.
/constitution (principles), /specify (the what & why), /plan (the how / tech stack), and /tasks (smallest workable chunks), then implement.specify CLI (installed via uvx) just unzips a template release, bootstraps a git repo, and drops prompt files into .github/prompts.The hosts open by mapping the "camps" of AI-assisted development: the one-liner prompters, the paragraph-writers, and the planners who build task lists — with Pierce cited as the long-time advocate of specification-driven development. James recalls his time at Canon where features were fully documented, mock-screenshotted, and specified before a line of code was written. Against that backdrop, Den introduces Spec Kit, released "just on Tuesday" by a team including colleague John Lamb.
Den demystifies the concept immediately: it is not a magical, complex thing. As he puts it, "it's like prompt engineering on steroids." You spend time upfront defining what you want and how you want it built — tech stack, constraints — and then have the LLM build exactly that.
"it's like prompt engineering on steroids."
The deeper argument is about what we treat as the source of truth. Today, code is checked into a repo and is "everything" — but code binds you to one specific implementation. Want to rearrange the tiles or change the login screen? You reimplement from scratch. The spec inverts this: it is implementation-agnostic, so you can guide the LLM to many variations from the same scaffolding.
"but code also binds you to a very specific implementation"
Den ties this to what enterprises call "app factories" — building hundreds of apps and needing a standardized, interchangeable stack. With specs, a business can templatize its conventions (".NET on the back end, React on the front end") once and reuse them. And when the stack changes, the spec doesn't: "You defined your what and the why. What changes is the how."
"You're not rewriting your spec. Your spec is the same like you defined your what and the why. What changes is the how."
Burke and James press on how PRDs fit in. Den's answer: a PRD is "PM speak for spec" — the what and the why, not the technical how. Spec Kit splits that PRD from the how and from a detailed task breakdown. He then installs the tooling live: specify, a Python CLI run through uvx ("npx for Python"), which scaffolds a template, bootstraps a git repo, and drops three prompt files — specify, plan, and tasks — into a .github/prompts folder that VS Code picks up as slash commands. No CLI required either: the templates are downloadable zip releases, with support for Copilot, Claude Code, and Gemini CLI.
Before writing any spec, Den sets the constitution — the project's non-negotiable principles.
"the constitution essentially is a set of non-negotiable principles for your project."
Using GPT-5 in agent mode, he generates a web-app constitution (user-centric, accessibility-first, secure-by-design, least-privilege) and notes it's shareable across an org so nobody rewrites it. Then /specify writes the feature spec for a "podcast landing page for VS Code Insiders" — and the more concrete the prompt, the better the output. The generated spec includes acceptance scenarios, user stories, and functional requirements (like tag-based episode filtering), plus an acceptance checklist and [NEEDS CLARIFICATION] markers you must resolve before moving on.
Burke plays the skeptic: for green-field apps especially, "you don't know what you don't know." Programming is discovery — you plan one way, hit a wall, and shift. In theory, if you could tell the model everything upfront it would be right, because "Prompt engineering is just giving the model the answer that you want" — but nobody can (or wants to) enumerate every edge case.
"Prompt engineering is just giving the model the answer that you want."
Den's rebuttal: you don't need everything from the get-go, and going down the path isn't one-way. When the login flow comes out wrong, you re-encode it in the spec and have it rebuilt. The spec becomes the living, breathing document the whole team refers to — and because it's committed to the repo, it explains why a feature landed the way it did. He then runs /plan ("use Next.js, data is mocked, no databases"), which produces the technical design grounded in the constitution, and /tasks, which breaks the plan into the smallest possible workable chunks. Finally he hits implement and goes hands-off while the agent cooks — creating 25+ files, Playwright configs, and the Catppuccin-themed UI. Along the way the hosts cover Copilot pricing (included models like GPT-5 mini and 4.1 vs. premium requests billed per agent turn) and stress the recurring caveat: this is an experiment, feedback wanted.
"it's like prompt engineering on steroids."
"You're not rewriting your spec. Your spec is the same like you defined your what and the why. What changes is the how."
"the constitution essentially is a set of non-negotiable principles for your project."
"Prompt engineering is just giving the model the answer that you want."
| Approx. Time | Topic |
|---|---|
| 0:00 | Intro and banter — rigs, liquid cooling, name pronunciation |
| 6:57 | The camps of AI-assisted dev; Spec Kit announced |
| 9:32 | What spec-driven development actually is ("prompt engineering on steroids") |
| 9:53 | App factories — standardizing stacks across many apps |
| 12:07 | PRDs vs. specs — "PM speak for spec" |
| 14:43 | Installing Spec Kit — the specify CLI via uvx |
| 16:34 | specify init — scaffolding and the /specify /plan /tasks prompts |
| 21:16 | The plan (the how) and grounding in the constitution |
| 22:27 | The tasks prompt — breaking plans into chunks |
| 24:36 | Writing the constitution with GPT-5 agent mode |
| 27:15 | Running /specify to generate the feature spec |
| 33:07 | Skepticism: "you don't know what you don't know" |
| 36:05 | /plan with Next.js, then /tasks breakdown |
| 44:00 | Model choice — GPT-5/4.1 precision vs. Sonnet creativity |
| 48:00 | Implement — hands-off while the agent cooks |
| 50:12 | Copilot pricing — included models vs. premium requests |
| 52:10 | Wrap-up and call to action |
uvx) that scaffolds the templates and prompt filesspecify ("npx for Python")/constitution, /specify, /plan, /tasks — surfaced as VS Code slash commands from .github/prompts