What is AWS Kiro?

To truly understand Kiro, we must discard the mental model of a "chatbot in a sidebar." Kiro is not an assistant that you summon when you get stuck. Kiro is an engineering operating system that mandates structure, formalizes requirements, and treats code generation as the final, almost trivial step of a rigorous planning process.

The Architectural Analogy: Bricklayer vs. Master Builder

Imagine you want to build a complex, multi-story skyscraper. Traditional AI coding assistants (like Copilot or the early versions of ChatGPT) are like having a swarm of incredibly fast bricklayers next to you. You point to a spot and say, "Build a wall here," and they build it instantly. It feels magical. But without a master blueprint, plumbing collides with electrical wiring, load-bearing walls are misplaced, and the building eventually becomes structurally unsound. In software, this is known as "vibe coding"—building entirely by feeling and immediate feedback without architectural foresight.

AWS Kiro is the Master Architect and the Construction Manager combined. Before a single brick is laid (or line of code is written), Kiro demands a blueprint. When you request a new feature, Kiro pauses. It creates a formal Specification. It outlines the business requirements, draws up the technical architecture, defines the database schemas, and breaks the entire project into a sequence of atomic tasks. Only when you, the human overseer, approve the blueprint does Kiro dispatch its sub-agents to start laying the bricks.

AWS Kiro didn't emerge out of a vacuum. It is the culmination of Amazon's multi-year, multi-billion-dollar journey in AI developer tooling. It represents the official retirement of Amazon Q Developer, marking a pivot from reactive assistance to proactive agency.

In a standard AI IDE, the feedback loop is: Prompt → Code → Review → Re-Prompt. In Kiro, the workflow is strictly phased and infinitely more robust:

Phase 1: Requirements Analysis (requirements.md)

You provide a natural language prompt: "Build a user authentication flow." Kiro’s Spec Agent intercepts this. It refuses to write code. Instead, it generates a `requirements.md` file. It asks clarifying questions: "Do you need OAuth? MFA? What are the password complexity rules?" It translates your vague desires into strict, testable business requirements.

Phase 2: Technical Design (design.md)

Once you approve the requirements, the Architecture Sub-Agent takes over. It creates `design.md`. This document outlines the component hierarchy, the database schemas, the API route definitions, and even generates Mermaid.js sequence diagrams. It maps the business requirements to technical realities.

Phase 3: Task Breakdown (tasks.md)

The Planning Sub-Agent slices the technical design into sequential, atomic tasks. "Task 1: Set up Cognito User Pool. Task 2: Create React Login Component. Task 3: Implement JWT middleware." Each task has distinct acceptance criteria.

Phase 4: Execution & Autonomous Coding

Finally, the Execution Agent starts working through `tasks.md`. It writes code, runs your test suite, and if a test fails, it autonomously loops back to fix the code until the acceptance criteria of the specific task are met. If it hits an unresolvable roadblock, it updates the Spec and asks for human intervention.

This methodology creates an immutable paper trail. When a junior developer joins the team months later, they don't just stare at thousands of lines of AI-generated code. They read the exact specification that produced it.

During the Requirements phase, Kiro doesn't just write loose bullet points. It strictly adheres to a formal systems engineering standard called EARS (Easy Approach to Requirements Syntax). Originally developed in the aviation and aerospace industries, EARS ensures that requirements are unambiguous, testable, and perfectly formatted for an AI model to comprehend without hallucination.

EARS relies on structured sentence templates. Every requirement Kiro generates (or that you provide) should map to one of these five patterns:

• 1. Ubiquitous (Always Active): Use for rules that apply constantly.
  Format: "THE SYSTEM SHALL [system response]."
  Example: "THE SYSTEM SHALL encrypt all passwords using bcrypt before database insertion."
• 2. Event-Driven (Triggered): Use when a specific action initiates a response.
  Format: "WHEN [trigger], THE SYSTEM SHALL [system response]."
  Example: "WHEN the user clicks the 'Checkout' button, THE SYSTEM SHALL validate the cart inventory."
• 3. State-Driven (Conditional Ongoing): Use when a specific system state alters behavior.
  Format: "WHILE [system state], THE SYSTEM SHALL [system response]."
  Example: "WHILE the payment gateway API is unreachable, THE SYSTEM SHALL queue incoming transactions in SQS."
• 4. Unwanted Behavior (Error Handling): Use to define fallback and error mechanisms.
  Format: "IF [trigger], THEN THE SYSTEM SHALL [system response]."
  Example: "IF the user provides an invalid JWT token, THEN THE SYSTEM SHALL return an HTTP 401 Unauthorized response."
• 5. Optional (Feature Toggles): Use for features dependent on specific configurations.
  Format: "WHERE [feature is included], THE SYSTEM SHALL [system response]."
  Example: "WHERE the user has a 'Premium' subscription tier, THE SYSTEM SHALL bypass standard API rate limits."

A massive problem with earlier AI tools was "Context Amnesia." You would tell the AI to use functional components, and 20 minutes later it would generate a class component. Kiro solves this permanently with Steering Files.

Steering files are markdown documents placed in a `.kiro/steering/` directory at the root of your project. They act as the immutable DNA of your repository. Kiro reads these files before executing any action, injecting your explicit rules into its context window.

Example Steering Configurations:

• `tech-stack.md`: "This project uses Next.js 16 (App Router), TailwindCSS for styling, and tRPC for data fetching. Do not use standard fetch API."
• `security.md`: "All database queries must use parameterized inputs. Never log personally identifiable information (PII). All secrets must be pulled from AWS Secrets Manager."
• `conventions.md`: "Use snake_case for database columns, camelCase for variables, and PascalCase for React components."

Kiro is not just an interface you talk to; it is a system that watches you work. Agent Hooks are event-driven automations that trigger specialized sub-agents based on IDE activity.

Hooks are configured via JSON files in `.kiro/hooks/`. They allow you to bind Kiro's intelligence to standard developer actions without manual prompting.

Real-World Hook Examples:

• The Save Hook: When you press `Cmd+S` on a `.ts` file, a background hook triggers the Linting Agent. It doesn't just highlight errors like ESLint; it autonomously writes the code to fix the formatting and type errors instantly.
• The Test Hook: When you complete a function, a hook triggers the Testing Agent to automatically draft unit tests for the edge cases of that function and run them.
• The Commit Hook: When you attempt to `git commit`, the Security Agent scans the diff. If it detects a hardcoded API key or an injection vulnerability, it blocks the commit, opens a chat, and provides the remediated code.

Kiro's intelligence is not a single monolithic brain. It is an orchestration layer built on top of Amazon Bedrock, utilizing a dynamic routing architecture to balance cost, speed, and reasoning capability.

When Kiro performs a task, it analyzes the complexity and routes the request to the most appropriate foundation model:

• High Reasoning (Claude Sonnet 4.5+): Used for Spec generation, complex architectural design, and deep multi-file refactoring where context retention is critical.
• High Throughput (Amazon Nova Pro / Qwen3 Coder): Used for rapid scaffolding, writing boilerplate tests, and executing simple linting hooks where speed and cost-efficiency are paramount.

Furthermore, Kiro natively supports the Model Context Protocol (MCP). This means you can easily wire Kiro to external enterprise tools. Through MCP, Kiro can read Jira tickets to understand sprint requirements, query your production PostgreSQL database to understand current schemas, or pull logs from Datadog to debug an active incident—all directly inside the IDE environment.