AWS Kiro: The real Development Environment

In the last 12 months, I have built quite a few applications outside of my work. Everything started on an AI-powered IDE and ended up with minimal help but more trouble from AI. I have been jumping between different AI-powered IDEs such as Copilot, Cursor and most recently Google's Antigravity. My observation so far, they are all good at generating code. They're all bad at understanding what I actually wanted to build.

When I tried AWS Kiro, something clicked in a way the others never did. With Kiro, I was "Developing" an application, not just "Coding" it.

The Project I was working on

I needed to build a simple Chrome extension that had some form-reading operations. Since Google's Antigravity has a built-in Chrome environment that can automatically open, test, and record videos, it seemed like the obvious choice. Great for Chrome extensions, right?

Well, it was good at creating a nice-looking UI. I'll give it that. But even with the state of the art Gemini 3 Pro model, I couldn't get the plugin to a working state even after 3-4 days. The model kept going in circles, and I was burning time on fixes that led nowhere. I even lost track of what I was doing, and did not have a clear way out.

I scrapped it. Started fresh. New project. But this time on AWS Kiro.

Within 2 days, I had a working sample. So, what was different?

Spec-Driven Development: Think First, Code Later

Most AI IDE tools are itching to write code the moment you type something. You give them a prompt, and boom — files everywhere. Sounds efficient until you realize you're 500 lines deep into something that doesn't match what you actually needed. We've all been there.

Kiro flips this completely.

When I told Kiro I wanted to build a Chrome extension with specific functionality, it didn't start generating files. Instead, it created clear specs, user stories, and acceptance criteria using EARS notation, something I am very much used to as a software engineer.

Standard format:

WHEN [condition/event] THE SYSTEM SHALL [expected behavior]

Here's what a real requirement looks like:

## Requirements

### Requirement 1: Form Field Detection
**User Story:** As a user, I want the extension to automatically detect form fields on any webpage, so that I can interact with them programmatically.

**Acceptance Criteria:**
1. WHEN a webpage loads THE SYSTEM SHALL scan for all input, select, and textarea elements
2. WHEN a form field is detected THE SYSTEM SHALL highlight it with a visual indicator
3. WHEN no form fields exist THE SYSTEM SHALL display "No forms detected" message

Call me old school, but this is much better than a 20 page wall of text. These are actual structured requirements, segregated by category: functional requirements, security considerations, performance improvements.

Here's where it gets interesting. I started with about 10 requirements. After a few rounds of back and forth discussions, challenging the specs, and answering clarifying questions, "We" (ya, it was not just I anymore) ended up with over 50 well-defined requirements, many of them I did not even think about before I started.

Kiro would actually point out contradictions between user stories and call things out: "Hey, this user story says X, but this other one implies Y. Which one do you want?" That kind of debate is gold when you're trying to nail down what you're actually building.

And this is key: Spec-driven development avoids context drift. When the AI has a clear, documented understanding of what you're building, it doesn't get lost during troubleshooting and start doing absurd things. The specs become the anchor.

I haven't seen any other tool do this as well as Kiro. Not even close.

Design Mode and Task Lists: Finally, Some Traceability

After the specs were locked, Kiro generates a design document and task list. You might already know this - these three files form the foundation:

• requirements.md — User stories with acceptance criteria in EARS notation
• design.md — Technical architecture, sequence diagrams, implementation considerations
• tasks.md — Discrete, trackable tasks sequenced by dependencies

But, the key here is, this isn't just a to-do list. It's a traceable implementation plan. Each task maps back to a requirement. When you're deep in implementation and wondering "why are we building this again?", you can trace it right back to the original spec.

Development is not always Linear

Real development isn't linear. You don't always implement Task 1, then Task 2, then Task 3. Sometimes you jump ahead because you need to test something, or a dependency forces you to work on a later task first.

I was shuffling around — implemented the backend API (Task 5) before the frontend changes (Task 4). When I tried to use the backend, Kiro pointed out: "You asked for the backend API, and I gave you that. But that's Task 5. We haven't done Task 4 yet, which is the frontend integration."

Even though I was jumping around in the chat, not touching the task list file, Kiro kept track of what was done, what was tested, and what was pending.

It's like pairing with someone who actually remembers what we talked about yesterday.

Steering Files: This Changes Everything 🎯

Here's something that frustrated me with every other AI IDE: you give feedback about one library not working, and suddenly the AI rips out your entire tech stack and introduces something completely different. You complain about a CSS issue, and next thing you know, it's migrated you from React to Vue. That's just confusion and trouble.

Kiro's steering files solve this completely.

Steering files are markdown documents stored in .kiro/steering/ that give Kiro persistent knowledge about your project. I created steering files that defined:

• The technology stack Kiro must use
• Boundaries Kiro cannot cross during troubleshooting
• Libraries that are off-limits
• Coding conventions and patterns

Here's a sample tech.md steering file:

---
title: "Technology Stack"
inclusion: always
---

# Technology Stack Guidelines

## Frontend
- Framework: React 18+ with TypeScript
- Styling: Tailwind CSS only (no styled-components, no CSS modules)
- State: React Context for simple state, no Redux

## Constraints
- DO NOT introduce new dependencies without explicit approval
- DO NOT switch frameworks or major libraries during troubleshooting
- DO NOT use jQuery under any circumstances

## Preferred Patterns
- Functional components only
- Custom hooks for shared logic
- Error boundaries for fault isolation

Now, just because I complain about a particular library, Kiro doesn't rip it off and do something completely different like other tools would. It stays within the boundaries. Closed context. No irreparable damage to the codebase.

And there is much more that we can achieve with the steering files.

When building an app with Cursor I remember how it created 2 different auth flows, since the first one did not meet the full requirements, and leaving the files related to both the flows in the code base creating a lot of confusing routes and mappings. With Kiro, I could totally avoid any such scenarios by defining a steering file with how to handle these cases.

Another simple situation is, I noticed that whenever I had a discussion with Kiro, gave feedback, debated an approach, finalized a new direction, it would create an MD file documenting what changed and why. Over time, these files cluttered my workspace. I had about 20 random files like "encryption_fix.md", "testing_guide.md", "functionality_notes.md".

It was annoying. So, I created a steering file:

**CRITICAL RULE**: All feedback, status, and documentation files created by Kiro must follow this naming convention:

feedback/{NNN}_{descriptive-name}.md

Where:
- `{NNN}` is a zero-padded 3-digit sequential number (001, 002, 003, etc.)
- `{descriptive-name}` is a kebab-case description of the content
- All files must be in the `feedback/` directory at the project root

### Examples

**Good**:
- `feedback/001_gradle-migration-complete.md`
- `feedback/002_jwt-authentication-fixed.md`

**Bad** (DO NOT USE):
- `GRADLE_MIGRATION_COMPLETE.md` (wrong location, no number)
- `JWT_AUTHENTICATION_FIXED.md` (wrong location, no number)
- `status.md` (wrong location, no number, not descriptive)
- `feedback/migration.md` (no number)
- `feedback/1_test.md` (not zero-padded)

Now instead of random files scattered everywhere, I have a clear chronological track of all discussions and architectural decisions. It's actually become a feature — a decision log I can reference later.

Plus, I created an agent hook to clean up this or summarize whenever I need.

Agent Hooks: Automation That Runs in the Background 🤖

Agent hooks are event-driven automations that trigger when specific events occur — saving files, creating new files, deleting files. Instead of manually asking for routine tasks, hooks handle them automatically.

Here's one of the hooks I set up:

{
  "name": "Cleanup Unused Files",
  "description": "Identify and remove unused files and folders",
  "trigger": {
    "type": "manual",
    "label": "Clean Up Project"
  },
  "action": {
    "type": "sendMessage",
    "message": "Performing project cleanup:\n\n1. Scan for unused files and folders\n2. Check for:\n   - Empty directories\n   - Backup files (*.bak, *~)\n   - Temporary files\n   - Unused dependencies\n   - Old documentation files\n3. List files to be removed\n4. Ask for confirmation before deletion\n5. Document cleanup in feedback file\n\nBe careful not to remove important files!"
  },
  "enabled": true
}

I configured hooks for: auto-generating test cases, running test cases after every task completion, auto-updating documentation, cleaning up unused files, and creating summaries of discussions on any changes to the initial plan.

It's like pairing with someone who actually remembers to do the boring stuff you always forget.

Context Management That Just Works

Here's something that drives me crazy with other tools: token limits. You're mid-conversation, making progress, and suddenly the context window fills up. Now you have to start a new session, re-explain everything, and hope the AI picks up where you left off.

Kiro handles this automatically. When tokens exceeded the limit, it compacted the discussion internally, keeping a summary of what mattered. I didn't have to manually open new sessions and explain everything as a fresh start — Kiro did it behind the scenes.

When I looked at my session history, there were 7-8 sessions. But they weren't disconnected fresh starts. They were continuations of the same conversation, with context preserved.

That's exactly what I needed — long, complex development sessions without worrying about losing the thread.

Other Cool features

Kiro has many other cool development features, which now few other IDEs are also providing.

Checkpoint Restore: The "Undo" Button that we all need

I challenged an implementation but later asked Kiro to revert my decision, which kind of worked, but still some files and the ideas from that discussion were lingering.

That's where checkpoint helps. I went back to the checkpoint before my "why this, change it..." comment, and Kiro simply forgot everything after that point. Context intact. Memory not corrupted. Back on track.

Permission Control Done Right 🔐

When Kiro runs commands, it doesn't ask for blanket permissions. It's selective, per command.

For example, when it wanted to run rm -rf on the distribution folder, I could approve that specific command on that specific folder. But when it ran curl commands, I could say "give you access for curl *" if I trusted those.

Everything shows up in the chat for easy selection. Much better than micromanaging every single command or giving away the keys to the kingdom.

Pro tip: You can also configure Trusted Commands that auto-approve:

npm *       # Allows all npm commands
git status  # Allow git status checks
python -m * # Allows Python module execution

MCP Integration: Connecting to Your World 🌐

Kiro supports Model Context Protocol (MCP), which lets you connect to external tools and data sources:

{
  "mcpServers": {
    "aws-docs": {
      "command": "uvx",
      "args": ["awslabs.aws-documentation-mcp-server@latest"],
      "env": {
        "AWS_PROFILE": "default"
      },
      "disabled": false
    }
  }
}

Features I'm Still Exploring

Kiro has even more capabilities I'm aware of but haven't deep-dived into yet:

• Kiro CLI — Terminal-based workflows with the same steering files and MCP servers
• Autonomous Agent (Preview) — A frontier agent announced at re:Invent 2025 that maintains context across sessions, learns from code review feedback, and works asynchronously across multiple repositories. Matt Garman called it "orders of magnitude more efficient" than first-generation AI coding tools.
• Kiro Powers — One-click packages that add specialized capabilities (Datadog, Postman, Stripe, Figma integrations)
• Property-Based Testing — Extracts properties from specs and tests whether generated code meets them

These are on my list. But even without them, Kiro has already transformed my workflow.

Finally, The Look and Feel 👻

A trivial thing, but I love Kiro's ghost icon. It's a nice touch.

More importantly, the IDE feels like a real IDE — well-integrated, cohesive, not just a VS Code wrapper with some AI bolted on (looking at you, Cursor). Kiro is built on Code OSS, so you get VS Code familiarity with your existing settings and extensions, but it feels intentional and polished.

Fun fact: Amazon is now using Kiro internally as their standard AI development environment company-wide. That's a pretty strong signal.

What I Wish Kiro Had

Google's Antigravity has some features I genuinely miss:

• Inline comments and edits — The ability to make surgical changes right in the code
• Multiple interactions with the same agent — Running parallel conversations
• Agent manager — Coordinating multiple agents for complex tasks

If Kiro gets these features, I think it would be unmatched. The foundation is already strong — these additions would make it exceptional.

Quick Tips for Getting Started with Kiro 💡

1. Start with Spec Mode — Don't jump into code. Let Kiro generate requirements first, then challenge them.
2. Set up steering files early — Define your tech stack and boundaries before you start building. You'll thank yourself later.
3. Use Supervised mode for risky areas — Auth, payments, infrastructure. Switch to Autopilot for boilerplate.
4. Create cleanup hooks — Automate the boring stuff: tests, docs, build artifacts.
5. Configure MCP for AWS docs — If you're building on AWS, the live documentation integration is invaluable.
6. Trust the checkpoint — When things go sideways (and they will), just restore. Don't waste time with manual fixes.

Final Thoughts: Controlled VIBE Coding

Here's the thing about AI IDEs: they're all trying to help you code faster. But faster doesn't matter if you're building the wrong thing, or if you lose your context halfway through, or if the AI keeps pivoting on you without warning.

When I have Spec Mode engaged, steering files in place, hooks running in the background, and checkpoints available — it's like VIBE coding, but controlled. It's similar to coding in Cursor or any other AI IDE, but with guardrails that give you confidence Kiro won't break things. And even if it does? Checkpoint restore is right there.

If you're starting a project from scratch and want an AI that thinks before it codes, Kiro is worth your time. It's not just another autocomplete on steroids — it's the closest I've found to pairing with someone who actually understands what you're building.

Happy coding! 🚀

---

This article reflects my personal experience using AWS Kiro for side projects. I build applications for business use cases and spend a lot of time testing these tools to understand what actually works. Your mileage may vary based on your use case and project complexity.