[{"data":1,"prerenderedAt":267},["ShallowReactive",2],{"blog-post-\u002Fblog\u002Fpdd-and-spec-driven-development":3},{"id":4,"title":5,"authors":6,"badge":13,"body":14,"date":257,"description":258,"extension":259,"image":260,"meta":261,"navigation":262,"path":263,"seo":264,"stem":265,"__hash__":266},"blog\u002Fblog\u002Fpdd-and-spec-driven-development.md","SDD describes the change, not the product",[7],{"name":8,"description":9,"to":10,"avatar":11},"Itai Gendler","@itai-gendler","https:\u002F\u002Fgithub.com\u002Fitai-gendler",{"src":12,"alt":8},"\u002Fteam\u002Fitai-gendler.png","Engineering",{"type":15,"value":16,"toc":248},"minimark",[17,41,46,49,115,118,122,128,131,134,138,148,151,158,162,165,225,228,232,238,241],[18,19,20,21,28,29,34,35,40],"p",{},"Spec-driven development works. If you use ",[22,23,27],"a",{"href":24,"rel":25},"https:\u002F\u002Fopenspec.dev",[26],"nofollow","OpenSpec",",\n",[22,30,33],{"href":31,"rel":32},"https:\u002F\u002Fgithub.com\u002Fgithub\u002Fspec-kit",[26],"spec-kit"," or ",[22,36,39],{"href":37,"rel":38},"https:\u002F\u002Fkiro.dev",[26],"Kiro",", you\nknow the shape: describe the change before you build it, plan it, break it into\ntasks, and let the agent work against a written target instead of one sentence\nin a chat. This post is not an argument against it. It is about where it falls\nshort, and what it does not cover properly: the product.",[42,43,45],"h2",{"id":44},"what-these-tools-keep","What these tools keep",[18,47,48],{},"None of them throws the work away when it ships.",[50,51,52,68,90],"ul",{},[53,54,55,58,59,63,64,67],"li",{},[56,57,27],"strong",{}," keeps ",[60,61,62],"code",{},"openspec\u002Fspecs\u002F"," as the source of truth for how the system\nbehaves today. Each change carries a proposal, a design, tasks, and delta\nspecs. Archiving merges the deltas into the main specs and files the rest\nunder ",[60,65,66],{},"changes\u002Farchive\u002F",".",[53,69,70,72,73,76,77,80,81,84,85,67],{},[56,71,33],{}," gives each feature its own directory with ",[60,74,75],{},"spec.md",", ",[60,78,79],{},"plan.md","\nand ",[60,82,83],{},"tasks.md",", plus a project constitution. Whether those files stay living\nor become history is\n",[22,86,89],{"href":87,"rel":88},"https:\u002F\u002Fgithub.github.io\u002Fspec-kit\u002Fconcepts\u002Fspec-persistence.html",[26],"left to each team",[53,91,92,94,95,76,98,101,102,104,105,76,108,101,111,114],{},[56,93,39],{}," writes ",[60,96,97],{},"requirements.md",[60,99,100],{},"design.md"," and ",[60,103,83],{}," for each\nfeature, and keeps ",[60,106,107],{},"product.md",[60,109,110],{},"tech.md",[60,112,113],{},"structure.md"," as steering\nfiles that every conversation reads.",[18,116,117],{},"So the files stay. The question is what they hold.",[42,119,121],{"id":120},"the-product-gets-mixed-with-the-build","The product gets mixed with the build",[18,123,124,127],{},[56,125,126],{},"What usually steers these frameworks is the technical side",": the design,\nthe plan and the tasks. The product requirements are rarely discussed in full, and\nwhat is covered ends up mixed into the technical artifacts the framework\nproduces.",[18,129,130],{},"And the product never sits in one place. It is spread across feature and change\nfolders, so nothing describes the whole of it.",[18,132,133],{},"That matters. When the two are mixed, you can no longer tell what the product\nmust do from how it happens to be built today.",[42,135,137],{"id":136},"the-specs-drift","The specs drift",[18,139,140,143,144,67],{},[56,141,142],{},"A spec is only as true as the last time someone updated it."," A hotfix, a\nrefactor, a change made outside the workflow, and it quietly stops matching the\ncode. spec-kit's own docs name the risk:\n",[22,145,147],{"href":87,"rel":146},[26],"silent divergence",[18,149,150],{},"Keeping them current is a chore nobody owns. Every change means touching the\nproposal, the design and the specs, and the more files pile up, the more work\neach change costs. So it gets skipped, and the next agent builds from a spec\nthat is no longer true.",[18,152,153,154,157],{},"Splitting the product from the implementation changes that. ",[56,155,156],{},"The product lives\nin one place",", so a product decision is written once, not restated in every spec\nit touches. A purely technical change, like a refactor or a new library, never\nhas to touch it. And that one record serves every change, every agent and every\nperson on the team.",[42,159,161],{"id":160},"draw-the-line","Draw the line",[18,163,164],{},"PDD draws the line between product and implementation, in one place. A Product\nModel holds what any rebuild of the product would have to keep, and nothing a\nrebuild is free to change:",[166,167,168,181],"table",{},[169,170,171],"thead",{},[172,173,174,178],"tr",{},[175,176,177],"th",{},"In the Product Model",[175,179,180],{},"Left to the spec and the code",[182,183,184,193,201,209,217],"tbody",{},[172,185,186,190],{},[187,188,189],"td",{},"Who can reach each place",[187,191,192],{},"Architecture and data flow",[172,194,195,198],{},[187,196,197],{},"What it shows and asks for",[187,199,200],{},"Components and layout",[172,202,203,206],{},[187,204,205],{},"What can be done there",[187,207,208],{},"API style, endpoints and tokens",[172,210,211,214],{},[187,212,213],{},"Which rules apply",[187,215,216],{},"Libraries and frameworks",[172,218,219,222],{},[187,220,221],{},"What happens next",[187,223,224],{},"Tasks and file changes",[18,226,227],{},"Because it is kept apart, the model can also be checked against the code on\nevery change, so drift shows up when it happens instead of a year later.",[42,229,231],{"id":230},"sdd-describes-the-change-pdd-describes-the-product","SDD describes the change. PDD describes the product.",[18,233,234,235],{},"Spec-driven development is good at what it was built for: planning and building\na change. It was never meant to hold the product. Give the product a home of its\nown, kept apart from the technical artifacts and checked against the code, and\n",[56,236,237],{},"your specs can go back to doing what they do best: describing the build.",[18,239,240],{},"Nothing else has to move. Keep the spec-driven framework you use, or use none at\nall. The product just gets a place of its own.",[18,242,243,244,67],{},"For the problem this comes from, read\n",[22,245,247],{"href":246},"\u002Fblog\u002Fyour-agent-is-guessing","AI is writing code for products it doesn’t understand",{"title":249,"searchDepth":250,"depth":250,"links":251},"",2,[252,253,254,255,256],{"id":44,"depth":250,"text":45},{"id":120,"depth":250,"text":121},{"id":136,"depth":250,"text":137},{"id":160,"depth":250,"text":161},{"id":230,"depth":250,"text":231},"2026-10-06","SDD tools mix product and implementation in one place. PDD draws the line and gives the product a model of its own.","md","\u002Fblog\u002Fpdd-and-spec-driven-development.webp",{},true,"\u002Fblog\u002Fpdd-and-spec-driven-development",{"title":5,"description":258},"blog\u002Fpdd-and-spec-driven-development","E40EeIWq9QgVYf3ledTKBgY4tooV85Huhb2v8LC3LC4",1791840533970]