Spec-Driven Development with Kiro Training

What is spec-driven development, and how is it different from prompting? Prompting is conversational and disposable. Spec-driven development makes the specification the artifact: you define requirements, then design, then tasks, and the agent works against that structure. The spec can be reviewed, versioned, and revisited, which means the reasoning behind a feature survives beyond the chat session. On a team, that difference is what makes agentic development reviewable rather than opaque. What is EARS notation? Easy Approach to Requirements Syntax, a structured way of writing requirements that removes the ambiguity ordinary prose leaves behind. It matters more with agents than with human developers, because a human will ask when a requirement is unclear and an agent will simply pick an interpretation. The course covers it as part of the Requirements-First workflow. Do I need to be an AWS user? No. Kiro is an AWS product, but this is a development tooling course rather than a cloud infrastructure one. The prerequisites ask for general programming, Git, API, and generative AI familiarity, not AWS services experience. How does this relate to Agentic AI Foundations on AWS? Agentic AI Foundations is a one-day fundamental course that introduces agentic AI broadly and covers Kiro as one tool among several, alongside Amazon Q Developer, the Strands Agents SDK, and Bedrock AgentCore. This course goes deep on Kiro specifically and on spec-driven practice as a development methodology. If you want the landscape, start with Foundations. If you have chosen Kiro and need your team productive in it, come here. What are Kiro Powers, hooks, and subagents? They are three ways of extending and scaling the agent. Powers package related context, MCP configuration, and steering so the agent gets domain expertise without drowning in context. Hooks trigger actions automatically on defined events. Subagents delegate work to a scoped agent with limited tool permissions. Modules 6 and 7 cover all three, including how to decide which one a given problem calls for. Does the course cover using this across a team? Yes, and it is one of the reasons to take the instructor-led version rather than experimenting alone. The final module covers shared workspace configuration, spec review conventions, and enterprise governance controls including MCP registry allowlisting and model governance, which are the questions that surface as soon as more than one developer adopts the tool.