## Definition **Kiro** is an agentic IDE from AWS that treats a *visual* design — flow diagrams, component trees, state machines — as the spec and source of truth. The agent reads the canvas and emits code consistent with it, rather than reading prose and guessing structure. ## The diagram as spec Most [[Spec-Driven Development]] tools render the spec as text. Kiro inverts this: the artifact you edit is a diagram, and the code is the compiled output. A state machine on the canvas becomes a state machine in code; a component tree becomes a component hierarchy. The agent's job is faithful transcription plus the boilerplate humans hate writing. This places Kiro at the *visual, high-fidelity-structure* end of the [[SDD Spectrum]] — opposite a plain-prose spec, which is maximally expressive but structurally ambiguous. ## Why it works: alignment The deep value is social, not technical. A diagram is something a PM and an engineer can stand in front of and argue over *one canvas*. Prose specs fracture into "what I meant" versus "what I read"; a flow diagram has fewer places to hide a disagreement. | Property | Diagram-as-spec | Prose-as-spec | |---|---|---| | Shared mental model | Strong | Weak | | Reviewable by non-engineers | Yes | Partial | | Expresses structure | Excellent | Verbose | | Expresses behaviour/edge cases | Poor | Good | ## Why it breaks: expressiveness Not every property is drawable. "Retry with exponential backoff capped at 30s" or "reject inputs over 4 KB" are behavioural facts that no box-and-arrow captures cleanly. The honest failure mode of a visual spec is silent omission: the diagram looks complete, so the missing behaviour is never specified at all. The fix is to pair the canvas with text. Let the diagram own *structure and flow*; let an [[Executable Acceptance Criterion]] own *behaviour*. The diagram says "these states exist and connect thus"; the acceptance criteria say "in state X, given Y, the system must Z." ## Place in the SDD landscape Kiro is one of three SDD frameworks worth knowing, alongside [[OpenSpec]] (Markdown-spec-centric) and the [[BMAD Method]] (agent-role-centric). They differ in *where the spec lives*: a diagram, a Markdown document, or a choreography of roles. None is universally right — choose by what your team can review without friction. ## Related - [[SDD Spectrum]] - [[Spec-Driven Development]] - [[Executable Acceptance Criterion]] - [[OpenSpec]] - [[BMAD Method]]