The outcome
Deliver a feature whose implementation traces back to agreed requirements instead of an improvised agent conversation.
Kiro is a agentic integrated development environment from AWS. Turning feature ideas into requirements, design, tasks, and implementation while preserving repository guidance and explicit review of agent changes. This guide narrows that broad capability into one repeatable outcome, with checkpoints that keep the source material and your judgment in the loop.
Before you begin
Set the boundary before the tool starts.
Choose one real task, identify who will use the result, and decide what evidence or test will make the result acceptable. Gather only the source material needed for that task. If the work contains confidential, personal, regulated, or client-owned information, confirm that the platform and account are approved before sharing it.
AI should make the work easier to inspect. If the workflow removes the source, the owner, or the review step, redesign the workflow.
Step by step
A workflow you can repeat.
- 01
Create a clean branch and write the user, problem, constraints, non-goals, acceptance criteria, privacy boundary, and required validation.
- 02
Generate a Kiro spec, then edit the requirements until every behavior is testable and ambiguous product decisions are resolved by an owner.
- 03
Review the proposed design for architecture, data flow, authorization, failure handling, migrations, observability, and consistency with existing patterns.
- 04
Break implementation into small tasks and complete them in supervised mode, reviewing and accepting each diff and command before continuing.
- 05
Run the full trusted test suite, compare the final behavior with every requirement, update documentation, and release through normal review with a rollback point.
Working standard
What good use looks like.
- Make requirements testable.
- Review design before task generation.
- Implement one accepted task at a time.
Supervised and Autopilot modes have similar underlying file and command access; supervised mode adds a review-and-revert workflow rather than a stronger sandbox. Use repository-scoped authentication, temporary AWS credentials, carefully bounded trusted-command prefixes, protected paths, reviewed extensions and MCP servers, human-approved specs, checkpoints, and independent tests. Never use a universal command trust pattern on untrusted content.
Official references
Check the current product documentation.
Features, plan limits, availability, and data controls change. These official pages are the starting points used for this collection.