{ "video": { "id": "IddXPepIAS4", "title": "Using Spec-Driven Development for Production Workflows - Erik Hanchett, AWS", "duration": 1067, "upload_date": null, "channel": "AI Engineer", "source": "AI Engineer", "event_format": "Online" }, "analysis": { "video_id": "IddXPepIAS4", "title": "Using Spec-Driven Development for Production Workflows - Erik Hanchett, AWS", "one_liner": "An AWS developer advocate makes the case that writing requirements and design markdown before any code — the Kiro-style spec-driven workflow — is what keeps coding agents, which he calls \"AI interns,\" from going off the rails on complex features.", "summary": "Erik Hanchett defines spec-driven development as creating structured specifications before any code is written — requirements, then a design document, then a task list, all as markdown the human reviews between each stage. He argues frontier models still need this guidance, treats the LLM as an over-eager intern that must be steered, and insists the human stays the code reviewer and the one who gets blamed. He demos Kiro's spec mode on a movie-website project (EARS-format requirements, mermaid architecture and sequence diagrams, fast-check property-based tests, an MVP-ordered task list), and notes the whole flow can be done manually or with GitHub's open-source Spec Kit.", "key_points": [ "Definition given up front: \"structured specifications are created before any code is written\" — markdown requirements and design docs precede implementation, which works well with LLM coding assistants.", "Coding assistants are \"AI interns\": give them a little leeway and they go off the rails, so specs exist to guide them; he compares it to dropping everything when a VP tossed out a random idea during his first job.", "Frontier models aren't enough — they improve incrementally or by leaps, but requirements and paradigms keep changing, and thinking/planning modes in harnesses are weaker than actual documents with you in the middle.", "Context needs a \"Goldilocks zone\": don't over- or under-stuff agents.md / CLAUDE.md (called steering docs in Kiro).", "He recommends pairing spec-driven development with skills — on-demand instruction files triggered by keywords or /name — used in parallel during design-doc creation or task implementation.", "The flow works without Kiro: manually prompt for user requirements (optionally seeded with your own), review, then design document, review, then implementation task list. GitHub's open-source Spec Kit installs into a variety of coding assistants.", "Kiro (AWS's AI IDE, GA late last year, plus a CLI with plan mode) offers vibe mode and spec mode, asks clarifying questions before generating requirements, has a new quick plan mode, and added a spec mode for bug fixes; launch went viral with tens of thousands of downloads and a gate people routed around.", "Specs are not just for greenfield — he's seen years-old apps carrying dozens and dozens of spec files; best for in-depth features and complex projects needing upfront planning.", "The demo produced an EARS-format requirements doc (\"When the application initialize, the filter engine shall load\"), mermaid architecture and sequence diagrams, and property-based tests written against the requirements and design docs, run via fast-check in TypeScript/Node dozens to hundreds of times with different values.", "MCP feeds the flow: pull Jira/Asana tickets and PM-written requirements docs into spec generation, either by naming the server in the first step or by putting the rule in steering/agents.md. He rejects the \"MCP is dead\" take — it's still maturing, especially on security." ], "takeaways": [ "Stop between each artifact — requirements, design, tasks — and edit the markdown with your own knowledge, expertise and taste; review it for inconsistencies, hallucinations and errors before letting the agent implement.", "After the task list is generated, tell it to move the top four tasks to the top and build an MVP first, so you can see something working before implementing the rest.", "Turn on property-based tests against the requirements and design docs to check the tasks were actually implemented correctly.", "Keep steering/agents.md in the Goldilocks zone — enough rules and guidelines to know what to do, not a dump — and add on-demand skills for the parts of the spec flow you repeat.", "Wire your project-management MCP server (Jira, Asana, whatever) into the requirements step so PM-written docs and tickets seed the spec instead of being re-typed." ], "topics": [ "spec-driven development", "coding agents", "mcp", "property-based testing", "prompting", "context engineering", "skills", "developer tooling" ], "tools": [ "Kiro", "kiro.dev", "AWS", "GitHub Spec Kit", "MCP (Model Context Protocol)", "fast-check", "TypeScript", "Node", "Jira", "Asana", "Mermaid", "EARS format", "agents.md", "CLAUDE.md", "OpenAI", "Anthropic", "LinkedIn", "Discord", "Bluesky" ], "quotes": [ { "text": "Because if you give them just a little bit of of leeway, they will go off the rails. And really the spec-driven development helps guide them in the right direction.", "at": "01:32", "url": "https://www.youtube.com/watch?v=IddXPepIAS4&t=92s" }, { "text": "Kind of like that Goldilocks zone of information is what you need.", "at": "04:32", "url": "https://www.youtube.com/watch?v=IddXPepIAS4&t=272s" }, { "text": "at the end of the day, if something goes wrong, you are the person that are going to be blamed for it, not the agent.", "at": "05:50", "url": "https://www.youtube.com/watch?v=IddXPepIAS4&t=350s" }, { "text": "Please take the top four tasks, put them at the top, and create an MVP for me first.", "at": "12:40", "url": "https://www.youtube.com/watch?v=IddXPepIAS4&t=760s" } ], "words": 3793 }, "summary_url": "/#IddXPepIAS4", "transcript": { "html": "/transcripts/IddXPepIAS4.html", "txt": "/transcripts/IddXPepIAS4.txt", "vtt": "/transcripts/IddXPepIAS4.vtt" } }