7+ Things You Didn't Know About Amazon Kiro
From vibe coding to spec-driven development - Kiro is far more than just another AI code editor
Over this past summer, I've been showing off Kiro at AWS Summits in Los Angeles, New York and DC - presenting lightning talks, running builder sessions, and watching developers react in real time as they see spec-driven development for the first time. Now I'm taking it further: I'm delivering a brand new instructor-led training course called Spec-Driven Development with Amazon Kiro for our AWS Enterprise customers. After spending weeks deep in the course material and teaching it live, I wanted to share some of the most important and surprising things I've discovered about what Kiro can actually do.
If you've heard about Amazon Kiro, you probably know it's an AI-powered IDE. But beneath the surface, Kiro introduces some genuinely surprising capabilities that go well beyond auto-completing your code. After spending time diving deep into how it works, here are seven things that might change how you think about AI-assisted development.
1. It Doesn't Just Write Code - It Makes You Specify *Before* You Implement
Most AI coding tools follow a simple loop: you describe what you want, the AI writes code, you ship it. That's "vibe coding" - and Kiro replaces that pattern with something far more rigorous.
When you ask Kiro to build a feature, it doesn't jump straight to code. Instead, it generates three distinct artifacts:
- requirements.md - structured requirements written in EARS notation (Easy Approach to Requirements Syntax), making each requirement unambiguous and directly testable
- design.md - a technical design document grounded in your *actual* codebase, not generic architecture patterns
- tasks.md - a discrete, trackable execution plan
Each artifact has a mandatory review gate between phases. You wear a different hat at each gate: product owner for requirements, technical lead for design, project manager for tasks. The cost is a few minutes of review. The return? Six months from now, any team member can read those files and understand *why* a feature was built a certain way.
The surprise: Kiro treats planning artifacts as first-class project documentation, not throwaway notes. They persist in
.kiro/specs/ and become part of your project history.
2. It Has a Memory That Spans Sessions (and the Whole Team)
Every AI tool you've used forgets everything the moment you close the chat window. Kiro solves this with steering files - persistent markdown documents stored in
.kiro/steering/ that the agent reads on every interaction.Kiro auto-generates three foundational steering files by analyzing your workspace:
| File | Question It Answers | What It Prevents |
|---|---|---|
| product.md | What are we building? | The agent making feature decisions that contradict your goals |
| tech.md | What tools do we use? | Suggesting Express when you use Fastify, or JavaScript when you use TypeScript |
| structure.md | How is the code organized? | Placing new files in the wrong directory or inventing naming conventions |
Here's where it gets powerful: because these files are version-controlled with your project, they ship through Git. Every developer who clones the repo gets the same agent context on first open. No re-explaining conventions. No inconsistent output across teammates. The entire
.kiro/directory - steering, specs, hooks, skills, and subagent configurations - commits with your code.The surprise: A new teammate can
git clone → open in Kiro → start building immediately, with an agent that already knows the product vision, tech stack, and coding conventions. It's onboarding-as-code.
3. Bugfix Specs with Built-In Regression Guards
Most developers fix bugs by describing what's broken and writing a patch. Kiro forces you to document three* perspectives before touching code using its Bugfix Spec workflow:
- Current behavior (the defect): `WHEN a user selects Celsius THEN the system displays Fahrenheit`
- Expected behavior (the fix target): `WHEN a user selects Celsius THEN the system SHALL display Celsius`
- Unchanged behavior (the regression guard): `WHEN a user selects Fahrenheit THEN the system SHALL CONTINUE TO display Fahrenheit`
That third section - SHALL CONTINUE TO - is the magic. It converts silent assumptions ("obviously the Fahrenheit path shouldn't break") into explicit constraints the agent *must* honor. Without it, the agent might fix Celsius perfectly while quietly breaking Fahrenheit, because nobody told it that path mattered.
The decision rule is elegantly simple: Could this fix break something else? If yes, use a Bugfix Spec. If no, a quick vibe session is fine.
The surprise: It's regression-prevention-by-specification - before a single line of code changes. The discipline of naming what *shouldn't* change turns out to be more valuable than describing what should.
4. "Powers" Dynamically Load Expertise On Demand (Not Just Tools)
Most IDE plugins give you tool access - connect to an API, query a database, search documentation. Kiro's Powers system goes a step further: it bundles tool access with domain expertise and loads them dynamically based on what you're working on.
Here's the problem Powers solve. Say you connect 15 MCP servers - payments, database, monitoring, infrastructure, deployment. Every tool definition from every server occupies context window space, whether or not you need it right now. Your agent is spending tokens parsing tool catalogs instead of solving your problem.
Powers flip this model. You can have dozens of Powers installed, but only the relevant one activates at any time. When you type a prompt about CDK deployment, Kiro scans your installed Powers by keyword, loads just the CDK Power (with its tools and best-practice guidance), and keeps the other Powers dormant at zero cost. Switch topics? The active Power deactivates and a different one takes its place.
The anatomy of a Power is elegant:
- POWER.md (required) - Domain expertise: best practices, usage patterns, guardrails
- mcp.json (optional) - Tool configuration
- steering/ (optional) - Extended context and hooks
The surprise: A Power can be pure expertise with no tools at all. Just a
POWER.md that teaches the agent how to use tools you've already configured - like having a senior engineer's tribal knowledge loaded on demand. The catalog already has 40+ Powers spanning design, backend, deployment, observability, security, and agent development.
5. Agent Hooks Turn Your IDE Into an Event-Driven Automation Platform
Kiro has a hidden automation layer that most people never discover: Agent Hooks. These are event-action pairs where the IDE watches for something to happen and responds automatically - no manual intervention required.
Ten trigger types across five categories:
| Category | Triggers | Example Use Case |
|---|---|---|
| Session | Prompt Submit, Agent Stop | Inject coding standards into every prompt automatically |
| Task | Pre/Post Task Execution | Run tests after every spec task completes |
| Tool | Pre/Post Tool Use | Validate outputs from MCP tools, or inject architecture context before file writes |
| File | Create, Save, Delete | Auto-generate companion test files when a new component appears |
| Manual | On-demand click | One-click security scans when *you* decide |
Two action types:
Ask Kiro - sends a prompt to the agent for tasks needing judgment (consumes credits)
Run Command - executes a shell command directly, no agent reasoning (free and faster)
The kicker? For Pre Tool Use and Prompt Submit hooks, a non-zero exit code from a Run Command blocks the triggering action entirely. A failing lint check can literally prevent a file write. A failing security scan can prevent a prompt from reaching the agent. Your hooks become enforcement gates.
The surprise: Hooks don't fire inside custom subagents - a deliberate constraint that prevents recursive automation chains. And tool-use hooks support wildcard filtering (`@mcp.*sql.*`) so you can target only database-related MCP calls without catching everything else.
6. MCP Is an Open Protocol - Not a Kiro Lock-In
People assume Kiro's tool integration is proprietary. It's not. Kiro implements the Model Context Protocol (modelcontextprotocol.io), an open standard. Any MCP server works with Kiro, and any Kiro-compatible server works with other MCP clients.
The three primitives MCP servers expose are:
- Tools - executable functions the agent calls autonomously (search docs, create tables, run scans)
- Prompts - server-provided templates you pull in via `#` mention
- Resources - structured reference data (API schemas, config templates)
The distinction that matters: Tools are agent-driven (autonomous), while Prompts and Resources are user-summoned (you explicitly `#`-reference them). This means you control what informational context enters the conversation while letting the agent decide when to *act* on tools.
This open architecture means the ecosystem grows independently of Kiro. Community-built servers, company-internal tools, third-party integrations - they all plug in through the same standard protocol. Install from the IDE, from kiro.dev, or paste a GitHub URL for community Powers.
The surprise: Because MCP is open, your investment in building MCP servers isn't locked to Kiro. Switch IDEs tomorrow and your servers still work. That's a bet on a protocol, not a product.
7. You Can Split the Agent Into Specialized Subagents with Scoped Permissions
Kiro doesn't force you to work with a single monolithic agent. You can define custom subagents - specialist agents with their own system prompts, scoped tool access, and focused roles.
Think of it like having a frontend specialist and a backend specialist on your team, except they're agents:
- A backend subagent might have access to database tools and deployment commands but no ability to modify frontend files
- A security subagent might have read-only access to scan code but no write permissions
- A documentation subagent might have access to your wiki tools and markdown files only
The main agent delegates to subagents automatically based on the task at hand. Each subagent sees only the tools and context relevant to its role, which means smaller context windows, more focused reasoning, and natural permission boundaries.
Like everything else in Kiro, subagent configurations live in
.kiro/agents/ and ship through Git. Your entire team gets the same specialist agents on clone. And because hooks don't fire inside subagents, there's a clean separation between automation (hooks in the main agent) and delegation (subagents with focused roles).The surprise: Combined with steering files, hooks, and Powers, you're essentially designing an agent *architecture* - not just prompting a chatbot. The `.kiro/` directory becomes a complete agent configuration that's version-controlled, team-shareable, and composable.
+ Bonus: It's Free to Try - 50 Credits a Month, No Credit Card Required
Here's the part most people miss: Kiro has a permanent free tier - not a 14-day trial, not a limited preview. You get 50 credits per month, access to Claude Sonnet 4.5 and open-weight models, and full access to the entire 40+ Power catalog - all at $0, forever. That's enough to genuinely explore spec-driven development, steering files, hooks, and Powers without spending a cent.
Don't want to just read about it? Here are two free, self-paced labs where you can try Kiro's features hands-on:
A guided walkthrough of Kiro's core features using a real project. You'll set up steering files, create your first Feature Spec (requirements → design → tasks), execute spec tasks with live progress tracking, configure agent hooks for automation, and connect your first MCP server. This is the fastest path from zero to productive with Kiro.
A creative, multi-task lab built around an open-source video game called *Spirit of Kiro* (an infinite crafting game where every object is AI-generated). You clone the repo, then complete a series of increasingly complex challenges:
- Fix a physics glitch using Bugfix Specs
- Refactor messy vibe-coded interactions across multiple files
- Implement a complex feature (email verification + password reset) using full spec-driven development
- Automate asset management with agent hooks
95% of the game's code was written by prompting Kiro - so you're literally using AI to improve AI-generated code. It's the most fun way to internalize the spec-driven workflow.
Both labs are completely free and work with the Kiro Free tier.
The Bigger Picture
What makes Kiro genuinely different isn't any single feature - it's that all seven of these capabilities compose into a coherent system:
- Specs ensure intent is captured before code is written
- Steering ensures the agent never forgets project context
- Bugfix Specs ensure fixes don't create new problems
- Powers ensure expertise loads precisely when needed
- Hooks ensure automation runs consistently without manual effort
- MCP ensures you're building on an open standard, not a walled garden
- Subagents ensure the right specialist handles the right job
And the entire configuration lives in
.kiro/, commits to Git, and ships to every developer who clones the repo. It's not just an AI code editor - it's a spec-driven, team-aware, event-driven development platform.The era of "type a prompt and hope for the best" is giving way to something more structured. And that might be exactly what professional software teams have been waiting for.
Have you tried Kiro? What surprised you most? Drop a comment below.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article