How I Built My First App with Kiro

Introduction

A few months back my son and I built a game using QCLI. This took me on a journey to understand agentic coding and prompt engineering, I then shared this journey with others in a talk The continued developer evolution.

I've been creating applications using agentic coding tools ever since. However, recently I decided that instead of mindlessly prompting my way through another prototype that would work once and confuse me forever, I tried something called spec-driven development with Kiro another new tool in the crowded agentic IDE market.

Spoiler: I didnt build a game this time ( as my son was at school :) ) I actually built a task manager app, to help me keep on top of all the things I havent done so far this year. The application needed: priorities, due dates and filtering. To build this application I turned to an immerging process called Specification Driven Development ( SDD ) and the tool to support this process is called KIRO

Here’s how it went down.

The Problem with My Old Workflow

I’ll be honest with you - I’ve been riding the AI coding wave hard. Type what I want, watch code appear, test it, call it a day. However when I revisited these projects, a week or even a month later, I'd think “wait, why did I build it this way?”

Well I could go through the chat history and find all the nuggets of my lost thought process, or look at the git history log - but this wasnt a reliable process. Also my architecture was a mystery and my requirements - lost in time.

All I could think of was if I had a team working with me, how could I explain the code to them ? The answer was I couldnt... and to me this wasnt acceptable when building real working software. This was “vibe coding” at its 'finest' - and it was starting to annoy me - there's got to be a better way ?

Enter Kiro

I started trialing Kiro during one of these “there has to be a better way” moments . Instead of jumping straight into code generation, it made me think through three levels: requirements, design, and implementation. This process formalised a new approach called Specification Driven Developent or SDD. Each level creating actual markdown files that get version-controlled with your code and so giving some structure to the previous chaos of vibe coding. So what is Kiro and how do we get started ?

Getting started with KIRO

This was super easy, I downloaded KIRO from here and signed in with my BuilderID and I was presented with a window much like this

I then read a few articles on KIRO best practices and finished this workshop, just to get familiar with everything around KIRO and the SDD process that it supports.

Lets start building...

Building My Task Manager

I decided to test my new found understanding of SSD and Kiro by building my new task manager application with priorities, due dates, and filtering. Nothing groundbreaking, but complex enough to see if this spec-driven thing actually worked. With SDD its important that I have an idea of what I want before starting so here is my initial sketches.

As you can see I'm not much of an artist :)

Phase 0: Steering and Architecture

Before we can start building we need to define the guardrails and rules that govern our application. These will help guide the AI as it generates the code. To do this I first created some steering files.

I choose workspace only as the location for these steering files and filled in the details I wanted from the resulting blank file that was created. Here is some of my steering rules.

When creating Python code, use the following guidance:

- Use Flask as the web framework
- Follow Flask's application factory pattern
- Use Pydantic for data validation
- Use environment variables for configuration
- Implement Flask-SQLAlchemy for database operations

I also could have added in some MCP servers in Phase0 to add additional context for Kiro to understand what I'm trying to build. MCP servers like the AWS Docs Knowledgebase MCP Server to provide the latest AWS docs, and the AWS Pricing MCP Server to provide me with Pricing information.

Phase 1: Requirements - Lets gooo !

Next its time to tell Kiro what to build, from the "Lets Build" panel, I made sure that "Spec" is selected and typed: “Build a task manager with priorities and due dates.”

Kiro then generated detailed user stories in something called EARS notation in a requirements.md file. Now to some EARS might be a new thing, but to me it was something from my past( it actually came out in 2009 !! ) , as a technique I had used extensively on some larger projects I worked on. Think of it as a standard way of stating requirements.

So an EARS statement would typically be like:

'While optional pre-condition, when optional trigger, the system name shall system response>'

So Kiro generated extensive requirements like:

[WHEN] the user creates a task without a due date [THEN] the system [SHALL] set the default due date to 7 days from creation
[WHEN] the user attempts to save a task with an empty title [THEN] the system [SHALL] display an error message

These weren’t things I asked for. They were edge cases I would’ve discovered through production bugs at 2am. The AI was thinking ahead, documenting assumptions that would’ve otherwise lived only in my head. Pretty cool

I reviewed the requirements, and wanted to add some specifics about filtering and sorting. So to do this I could either use the chat interface again OR ( and this is what I did ) add the new requirements manually. Once that was done I saved the file and make sure that Kiro was aware of these changes I put a prompt into the chat interface:
'I have updated the requirements - please reload and review', and moved on to the next Phase.

Phase 2: Design - The “Aha!” Moment

This is where Kiro really changed my perspective. It took my requirements and proposed a complete technical design: data models, API endpoints, component structure, database schemas. Everything laid out in a document I could review, modify, and reference later.

For my task manager, it suggested: the following

A React frontend with clear component hierarchy
REST API with specific endpoints
SQLite for local storage
State management patterns

The design phase forced me to think about architecture before writing a single line of code. In my old workflow, I’d be three prompts deep into implementation before realizing my data model was completely wrong.

Here, I was able to catch issues early. As I had clearly articulated inside the steering files what the rules of this project were. So Kiro knew already what tech stack I wanted (if you have used other agentic coding assitants like claude code, you might call these rules ) So now every piece of generated code aligned with how I actually work.

Phase 3: Implementation - Breaking It Down

Once I had reviewed, iterated and finally was happy with the design, Kiro broke everything into discrete implementation tasks. It also gave me two options - to create some tasks as optional ( for a quicker MVP ), or to make all tasks mandatory. I chose the former

Each task was trackable. I could execute them one at a time or let Kiro’s Autopilot mode handle multiple tasks at once.\

The tasks weren’t vague like “create the frontend” - they were specific - here are some examples:

Set up project structure and dependencies
Implement Task data model with validation
Create TaskList component with filtering
Build API endpoints for CRUD operations
Add error handling and edge cases

I could review each task’s implementation, see exactly what code was generated, and understand how it connected to my original requirements. This traceability was exactly what I was after as show below

What if things go wrong ?

So in the implementation phase there was a number of times that task would not complete. However when this happened I could re-run these tasks and Kiro would open a new chat window, so clearing the context, before reloading the steering and design files. This allows it to easily pick up were it left off - a very handy feature when building complex applications with AI tools.

The Real Test: Adding Features Later

A week later, I wanted to add tags to tasks. In my old workflow, this would mean:
Searching through code history, logs and prompt history trying to figure out where things live.

Prompting the AI with incomplete context
Hoping I didn’t break anything( never successfully )

However now with Kiro, I just updated my requirements document with two lines about tagging functionality. Kiro automatically updated the design, created new implementation tasks, and modified the existing code to support tags. Everything was version-controlled, documented, and traceable.
It felt like having a really smart teammate who actually remembers what you decided last week.

A word on testing

I think its important to also point out that some of the tasks Kiro generated to satisfy my requirements and design ask, was to create until test suits to verify everything. Unit tests are not the only way developers verify their code is fit for purpose. We also had techniques like Business Driven Developement(BDD) and Test Driven Development (TDD). The good new is, one of these techniques Property Based Testing(PBT) is included in Kiro's workflow out of the box!!

So at the end of a hour or so of furious Kiro-ing I ended up with this thanks to SDD and it worked !

Given more time

If I had more time ( hopefully I will ) my next stage would be to use this process to create a build and deployment pipeline so I can deploy the Task Manager website into the cloud.

Other things I would love to investigate is another feature of Kiro called Kiro Powers. These specialized modules / plugins for Kiro, add expertise in specific tech stacks like AWS, Stripe, or Figma, by providing tools and workflows that support building with that stack. So by bundling tools, best practices, and code into easy-to-install packages, Kiro can then produce better outcome and accelerate development tasks. I've linked a nice article about Powers above and its definatley on my todo list

What I Actually Learned

So what did I actually learn by building this..
Your specs become super prompts. Your requirements and design documents stick around. Unlike chat history that disappears into the void, these are durable context the AI remembers across your entire project.
Slowing down speeds you up. Taking time to review requirements and design actually makes development faster. You catch architectural issues before they become technical debt that haunts you at 3am.
AI needs structure. Kiro’s approach keeps the AI focused and aligned with what you actually want. It’s true collaboration, not just “generate code and pray.”
Documentation is free. Your specs double as project documentation. When your teammate asks “why does it work this way?” you have an actual answer, not “uh, the AI did that I guess?”

When Should You Actually Use This?

Spec-driven development isn’t for everything. Building a quick proof-of-concept to test an API or experimenting with something you’ll throw away in an hour? ? Just vibe code it with prompts and get a quick feedback cycle happening

But for anything you’ll maintain, expand, or collaborate on, SDD provides the structure that prevents your codebase from becoming a mystery novel where you’re both the author and confused reader.

Kiro gives you the best of both worlds: the speed of AI-assisted development with the clarity of actually knowing what my code does.

Getting Started

With Kiro and SDD, if you can write a prompt, you can create a spec. The SDD Workshop by my esteemed colleage @094459 has hands-on tutorials that walk you through building complete features.

The shift from vibe coding to spec-driven development felt like going from scribbling notes on napkins to using a proper notebook. Both work, but one of them lets you find your notes later.

Now its your go

Get started just like me by doing this SDD Workshop on GitHub ( thx @094459 ) for hands-on tutorials, or download Kiro from kiro.dev and see how spec-driven development changes your workflow.*