With AI tooling absolutely dominating the tech space (and world for that matter) right now, it only seems fitting that as an engineer I test the bleeding edge tools to evaluate for myself. So I thought I'd give it a test whilst building a real feature that was sitting in my backlog for a while, but never had the time to get round to.
The feature in question is a embedded social widget within an existing blog website. And delving into Kiro and walking through its initial setup of how it begins to craft a feature started to make me shift my mindset about agentic coding capabilities: the magic isn't in how fast you can generate code, it's in how well you can think through what you're building before a single line gets written.
Let me walk you through what I think makes this IDE different, and why it might just change your development workflow too.
What is it?
Before diving into my experience, let's establish what Kiro actually is. Developed by AWS and launched sometime in summer 2025, Kiro is an agentic IDE that introduces a structured methodology called "spec-driven development" to AI-assisted coding. Unlike traditional AI coding assistants that jump straight from prompt to code, Kiro forces you to think through three distinct phases:
- Requirements: What you want to build and why
- Design: How it should be architected and implemented
- Tasks: Discrete, sequenced implementation steps
Similar to other offerings currently on the market, Kiro is a fork of VSCode - so for someone who primarily develops using TypeScript, it feels familiar.
There are some additional context artifacts that Kiro generates, and bakes into the prompts (e.g. steering docs), but I'm not going to cover those aspects in this blog - possibly at a later date!
The Spec-Driven Development Workflow
The key differentiator in my opinion, is the spec-driven development aspect of the product. Instead of purely allowing the AI to churn lines of code out, sometimes dubbed "vibe coding", Kiro implements a rigorous, three-phase approach that I found great to interact with.
Phase 1: Requirements Generation
When I started building the embedded social widget, I simply typed:
Create Spec: Embedded tweets/YouTube videos within the blog posts
Kiro immediately transformed this single prompt into a comprehensive requirements document using EARS (Easy Approach to Requirements Syntax) notation.
Within minutes, I had:
- User stories for viewing cards, and managing interactions
- Acceptance criteria for edge cases I hadn't considered
- Explicit assumptions that made it clear what the system would do (and would not do!)
With some of the context that Kiro inferred from the project, it was able to create some pretty comprehensive user stories that aligned with my overall goal of building the feature of embedded social media post support.
This phase alone was invaluable as I deliberately kept the initial prompt lightweight to truly understand how deep (or vague) Kiro would take it. It forced me to think about what I actually wanted to build, not just start coding and figure it out later. I could iterate on the requirements, refining them until they captured exactly what I needed.
Phase 2: Technical Design
Once I approved the requirements, it continued to analyse my existing Next.js codebase and generate a complete technical design document. This included:
- Data flow diagrams showing how information moves through the widget
- TypeScript interfaces defining the shape of my data structures
- Markdown API with clear contracts
This definitely was the most interesting part for me - this is where it highlighted different edge cases that may not have been immediately on my mind whilst first building the feature from scratch. Things like supporting different flavours of URLs to embed (e.g. short codes). For this particular project, and the scale that it is at, this could be considered overkill, but I quite like that it was able to highlight and include support for this.
Phase 3: Task Sequencing and Implementation
This is where Kiro's approach really shines. The IDE broke down the entire feature into individual, dependency-ordered tasks. Each task included:
- What functions, and features it is building
- New interfaces that it will design
- References to the requirements that it was supporting
Instead of facing an overwhelming project, I had a clear roadmap of small, manageable chunks. I could execute tasks one by one, reviewing the output at each stage. If something wasn't quite right, I could iterate on that specific task without throwing away the entire implementation.
On top of this iterative approach, Kiro also had checkpointing baked in if I ever needed to rollback and restore to a particular point - similar to a snapshot restore.
Love/Hate
Having worked on a number of AI-assisted projects before, where results have widely varied, the task-based workflow feels much better than a glorified autocomplete.
Now of course, it still hallucinates. It still writes bugs. However, the smaller iterative approach that allows you to drive deeper context into top-level requirements feels like you have more control over the output.
Smaller Chunks, Better Control
Each task typically took 5-15 minutes for the agent to complete. I could review the changes, test them, and move on without losing context. Compare this to asking another agentic coding tool to "build an entire authentication system" then trying to debug a thousand lines of generated code.
Easier Iteration
When a task didn't work perfectly, I could simply regenerate just that task with additional context or constraints. The agent already understood the broader requirements and design, so refinements were quick and accurate.
Progressive Testing
Because tasks were small and sequenced by dependencies, I could test incrementally as I built. By the time I finished all tasks, the feature was already mostly working, not a massive integration nightmare waiting to happen.
Real-World Results: The Embedded Widget
So how did it all work out? Well with some additional functionality written, and tested - it now looks like the following:
What Went Well
- Upfront clarity: The spec process forced me to think deeper about requirements, and ensured I built exactly what was needed.
- Manageable: Smaller tasks and chunks felt much more manageable, and allowed me to provide the deeper context to receive a higher quality output.
- Fast iteration: When I needed to adjust the design, updating the spec and regenerating tasks was straightforward.
Challenges and Learning Curve
Kiro isn't perfect. There were a few pain points:
- Verbosity: For small tweaks, the full spec workflow can feel like overkill - especially with re-generating tasks. Learning how to strike a balance is key.
- Spec maintenance: As your codebase evolves, keeping specs in sync requires discipline.
- Availability of models: Kiro currently only supports some of Anthropic's Claude models which is certainly a bit lacklustre in comparison to the like of Cursor.
Key Takeaways from My Experience
After completing my first AI-driven project with Kiro, here's what I learned:
1. Thinking Before Coding Matters More Than Ever
With AI, it's tempting to skip planning and just start generating code. Kiro forces you to slow down and think, and that discipline pays dividends in code quality and reduced rework.
2. Specs Are Living Documents, Not Dead Weight
Unlike traditional waterfall specs that get written once and forgotten, Kiro's specs evolve with your code. They stay in sync and provide ongoing value for onboarding, refactoring, and feature additions.
3. Small Tasks Beat Big Prompts
Breaking work into discrete, reviewable tasks makes AI-assisted development predictable and manageable. You're not gambling on a massive code dump working perfectly.
Summary
AWS Kiro represents a shift in how we think about AI-assisted development. Instead of treating AI as a faster autocomplete, its focus on spec-driven development feels like we have more control over the output, and that works best when given clear direction and structure.
For my embedded widget project, that structure was exactly what I needed. The spec-driven workflow helped me think through requirements, communicate intent clearly, and iterate on discrete chunks of functionality. The result is production-ready code that's well-tested, documented, and maintainable.
My recommendation would be to give it a try. The free-tier that comes with Kiro is enough to build a small feature to get a feel for the approach that it uses. Like I had mentioned previously, it does generate other artifacts that form part of the context that gets supplied to the LLM, but I'll talk about those in a future post.
You can check it out at https://kiro.dev/.
Top comments (2)
Solid breakdown on the spec-driven workflow. I've found that 'Small Tasks Beat Big Prompts' is absolutely key when working with any agentic tools. Big prompts usually just lead to a mess that's harder to debug. Quick question - how did Kiro handle state management when you were iterating on the embedded widget?
Are you referring to the management of context to the LLM within the IDE? If so, I found it pretty good since it can theoretically create a new session per task but still include things like your steering docs or other resources.
It does begin summarising conversations at somewhere around 80% usage of the context total, but I didn't notice any significant degradation when this happened.