Inspired by the talented Chris Bingham, an AWS Ambassador here at Fujitsu, I recently set myself a new target: to apply for the Ambassador program myself. Chris spoke positively about the program, and it struck me as the kind of nudge I needed to step outside my comfort zone. It also felt like an opportunity to help bring positive attention to the good AWS work being done at Fujitsu.

However, there’s one glaring weakness with any application I might submit: I’ve never really shared knowledge publicly. So, I decided to start there. Build a habit of sharing knowledge regularly and then decide later whether I want to keep it up long-term and actually apply.

The next question to answer was, how would I share articles and opinions?
Enter Kiro.

What is Kiro?

Kiro is a new tool from AWS that promotes Spec Driven Development. It’s a forked version of Visual Studio Code, so it’s familiar and supports the same extensions.

The Spec driven Development approach that it encourages guides the user to plan out a project, quickly but thoroughly, before generating code. That’s a little different from some of the other AI-assisted coding tools out there that focus purely on code generation.

I managed to get onto the recent preview of Kiro — and so I wanted to use it in a way that would let me experience it fully.

I decided to use Kiro to plan, design, build, and deploy a blogging site to host my articles - this website. Well three out of four isn’t bad. ‘Deploy’ was achieved outside of Kiro, but I’ll explain that later.

What is Spec Driven development?

Spec Driven development (SDD) is a methodology that encourages the developer to use a coding assistant in the ‘right’ way. You start with a ‘specifcation’. Define what you want to achieve, inputs, outputs, etc.

SDD doesn’t immediately launch into generating code. It uses your prompt to build the spec. There are three main phases to the process that we’ll look at:

1. Create requirements - generate a well written project plan
2. Create the design - generate a design capable of meeting the plan
3. Create the tasks - generate the tasks capable of delivering your project

Start with a prompt:

The entirety of my prompt to Kiro was:

Create the requirements

As you can see, Kiro was happy to oblige and generated requirements.md, a list of high level requirements for my blog, written in the form of user stories with acceptance criteria.
For example:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

### Requirement 1

**User Story:** As an aspiring AWS Ambassador, I want to host my own blogging platform on AWS, so that I can publish technical articles and demonstrate my AWS expertise.

#### Acceptance Criteria

1. WHEN I access the blogging platform THEN the system SHALL be hosted entirely on AWS infrastructure
2. WHEN I create a blog post THEN the system SHALL support rich text editing with code syntax highlighting
3. WHEN I publish an article THEN the system SHALL make it publicly accessible with SEO optimization
4. WHEN visitors access my blog THEN the system SHALL provide fast loading times and high availability

In total, 5 requirements were created from my prompt. I changed only one. A line in one of the acceptance criteria from “generate CloudFormation or Terraform IAC”, to “generate Terraform IAC”.

Now, have a quick look at my original prompt again and consider this:
I received five, well written, comprehensive requirements from that prompt. There’s real value in going from a rough idea to a clear, and easily edited, list of requirements – something that gives ‘shape’ to the idea. It really accelerates the process of going from idea -> to POC -> to market.

Create the design

Kiro waited patiently for me to review the requirements and make any amendments I wanted. When I was happy with the requirements, Kiro then produced design.md. This is a proposed solution, including a summary of that solution, high level archtitecture, list of components, and other relevant details to my plan. Here’s a snippet of my design:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

## Overview

The AWS Blogging Platform is designed as a cost-effective, Hugo-based static site solution that demonstrates AWS best practices while providing excellent performance and SEO capabilities. The platform leverages Hugo static site generation with AWS hosting services to create an extremely affordable, fast, and secure blogging solution suitable for technical content creation and AWS expertise demonstration for Ambassador applications.

## Architecture

### Primary Architecture: Hugo Static Site Generator

**Selected Architecture**: Hugo-based static site with AWS hosting
- **Frontend**: Hugo-generated static site on S3 + CloudFront
- **Content**: Markdown files in Git repository
- **CMS**: Git-based workflow with GitHub repository
- **CI/CD**: GitHub Actions for automated builds and deployment
- **Cost**: ~$1-5/month for moderate traffic
- **Pros**: Extremely fast, cheapest option, Git-based content management, excellent SEO, perfect for technical blogging
- **Cons**: No dynamic features, requires Git knowledge, limited admin interface

In actual fact Kiro created three high level proposals:

1. Servers Static site using React/Node.js hosted on S3 + CloudFront, and using DynamoDB.
2. Container based solution - React app on ECS Fargate + RDS PostgreSQL
3. A Hybrid approach which didn’t fully make sense using API Gateway, Lambda, ECS, and RDS.

After some cherry picking on my part, I chose a design close to option 1 but dropped React/Node.js and DyanmoDB, and instead used Hugo to convert markdown to static HTML hosted on S3 + CloudFront.

During the review of design.md I spotted the only misunderstanding I encountered with Kiro. My prompt included: “I’d like to review architectural diagrams and assess their suitability” .

Kiro interpreted this as a request for my blog site to also have functionality and capability to receive architectural diagrams. I realised that when I spotted this in the original design.md:

### Architecture Review System
┌─────────────────┐    ┌──────────────────┐    ┌─────────────────┐
│  Architecture   │────│   Diagram        │────│   Cost          │
│  Generator      │    │   Renderer       │    │   Calculator    │
└─────────────────┘    └──────────────────┘    └─────────────────┘
         │                       │                       │
         │             ┌──────────────────┐    ┌─────────────────┐
         └─────────────│   Template       │────│   Validation    │
                       │   Library        │    │   Engine        │
                       └──────────────────┘    └─────────────────┘

That’s a lesson for me as a user of the tool about being clear and unambiguous. It’s also a reminder that you do actually need to review the requirements, designs, and tasks that it produces.

Pretty cool though! – I’ve added the idea to my backlog.

Create the tasks

As before, Kiro will wait for you to review, amend, and finalise the design before proceeding to the next step. That could be by either manually updating design.md yourself, or interacting with Kiro to describe the changes you want, and Kiro will update the design.

Once you’ve settled on the requirements, then the design, Kiro will generate tasks.md. This is a list of tasks that are all directly a result of, and therefore, linked back to, the requirements, for example:

These tasks are ‘clickable’. Where you now see Task completed, it orginially read start task. Clicking that was all that was required to complete the task(s). I had the choice of clicking 2. create aws infrastructure with Terraform to complete all of the tasks in step 2, or I could execute each one individually and review as I went.
I was moving quickly but also had short pauses to review what had been achieved in bite size chunks.

It felt fast and considered. What do I mean by that?

Having reviewed tasks.md and about to generate the code - I was less than 2 hours into the process. i.e. 2 hours prior I hadn’t submitted my request to Kiro.

Now I was generating complex code that was tuned to specific requirements and validated tasks – that’s undeniably fast. However, in that time I’d still had an opportunity to review the requirements and the subsequent designs, and to make changes. Therefore, the code I was about to create had been carefully considered.

Does SDD differ from Vibe coding?

Yes.

Vibe coding is fun. When done right, it’s a great way to experiment or knock out a quick fix. But it doesn’t ask you to stop and think about what your requirements actually are.
If you get distracted, you can easily lose your place. The “plan” (if you had one) lives only in your head, which makes it hard to share with others, human or AI. And if you don’t have a plan, how exactly do you measure progress, or build in testing?

Spec Driven Development (SDD) flips that around.
The small upfront investment of writing down your requirements pays off quickly. You’re forced to clarify your goals and capture them in a way that’s easy to edit later. Kiro can then update the design and tasks automatically. Your spec becomes a single source of truth that’s easy to share with colleagues, clients, or AI helpers. Testing stops being an afterthought, and becomes super simple to embed into the process from the start because your objectives are clear.

Why does that matter?

Bluntly - it offers significant time savings. Using Kiro and SDD I estimate that I saved at least 3 weeks on my project.

Consider this scenario. An account manager receives an opportunity to create a small static marketing website for a client wishing to reach customers with updates, announcements, and new offerings. The subsequent timeline might look like this:

• The account manager schedules a call with the project team (A project manager, solutions architect, and a couple of cloud engineers). Availability of the team means it’s two days before the call happens. (+2 days)
• After the call, the solution architect is tasked with documenting the requirements and circulating for review, correction, and agreement. (+1 day)
• The solution architect takes a day to generate a high level design (+1 day)
• Feedback from the team results in iteration over the next couple of days (+2 days)
• Once finalised, one of the cloud engineers works with the PM to create user stories in Jira. (+1 day)
• The cloud engineers begin the process of writing code in terrform to define the infrastructure hosting the environment. (+5 to 8 days)
• Deploying the infrastructure reveals some bugs and improvement opportunities (+2 days)
• The cloud engineers switch to generate the CICD pipelines in Github actions to test, build, and deploy the site content. (+5 days)
• Oops - that thing we forgot to account for (+ 1 day)

Does that sound familiar?
Thats roughly 18-21 working days involving 4-5 people. That’s approximately four working weeks. And of course in the real world that team won’t get four weeks uninterrupted to focus on that project - holidays, sickness, other priorities jumping the queue, etc. There will be additional delays, and the longer something runs, the more it’s affected by these sorts of delays and interruptions.

Outcomes and timeline

Those steps I described above are equivalent to what I undertook to create this blogging site, but it took me just 4 days to get the site up and running.

Approximately 3 days of that was spent fine tuning, tweaking, corrections, etc - but it took just 3 hours to achieve the following in Kiro:

• Confirm the project (my) requirements - requirements.md
• Plan the project, outline the steps involved
• Generate and propose four high level solutions with comparative pros and cons on cost and complexity
• Select one of the four options, iterate that design to get to a solution I was happy with
• Produce the high level design architecture for the chosen solution - design.md
• Define all of the steps needed to make the project a reality - tasks.md
• Generate the CICD pipeline workflows in GitHub Actions, to validate PR’s, perform build and integration tests, and deploy content to the solution.
• Generate the first draft of Terraform IAC including, S3, Cloudfront, OAC, SSL certs via ACM, IAM Roles + least privilege policies, CloudWatch, Budgets, Route 53, Notification integrations with Slack, etc.
• S3 bucket for content and state file backups.
• Create 2 repositories, one for the IAC, one for blogging content. Both with specific security scanning, pre commit hooks etc.

3 hours effort to do that? - It blew my mind.

Now as I’ve already said, I wasn’t finished in 3 hours, it was more like 4 days.
Having got to the first draft of Terraform code, I wanted to make some changes, validate what had been produced, customise to suit my needs, etc. I also had some corrections and customisations to make on the GitHub actions workflows.

That process took me a further 3 working days (approx. 20hrs effort) to deploy, fix, tweak, and iterate to get the platform working as you see it now.

So less than 5 days, for a solo experienced cloud architect/engineer to complete something that was ready for deploying and acceptance testing.
Realistically that traditionally might take a team 3-4 weeks.

What did I learn from this?

AI powered coding tools can accelerate individual tasks. e.g. writing scripts, or a Terraform module. These tasks could be chained to accelerate aspects of a project delivery, but that on it’s own lacks a cohesive approach in terms of project planning, and working to an agreed plan.

SDD accelerates the whole project. It does this by shaping requirements and design first. So you have a clear plan that you can act on and your code is generated in line with that.

I also learned to have a backup plan.
Having travelled at the speed of developer light for the first few hours I ran into this issue:

There was 10 days before I’d get new credits and having generated, but not yet deployed and tested, all of the code… I couldn’t sit around and wait for that.

Most of the heavy lifting was done though - I was at the stage of deploying, reviewing, correcting, until it deployed cleanly and my site looked sensible and stable. But at this juncture I switched to ChatGPT Codex, integrating that with my repos in GitHub to take me down the home straight.

Conclusion

As is hopefully evident, I found Kiro to be incredibly powerful and easy to use. It promoted good practice and made planning quick and easy, but also to the appropriate level, neither under nor over cooked. Although it was rapid - it never felt like I was cutting corners. Quite the opposite in fact, Kiro steers you to think about what you’re doing and helps you to do it quickly.

Working with Kiro is closer to working with people than other code generating tools. I was able to hand off tasks (literally tasks.md) to Kiro while I joined calls or responded to other requests. In that regard, Kiro was like having a team to hand things off to so I could focus on something else, then check in later and course correct.

Kiro’s SDD approach promotes a single source of truth that works for an individual or for a project team. Integrating new project requests would be simplified too - just update the spec and the plan adapts then generates updates for the code automatically.

Teams using Kiro’s SDD could be much more competitive in delivering solutions for clients, then can be faster and cheaper.

Business can benefit too. How often is innovation a challenge for organisations because of a lack of available resources? Kiro could allow teams to deliver much more quickly, freeing up time to focus on innovation, or to take on additional projects.

Pricing will be interesting. At the time I write this, pricing has only been known for a few days and it’s higher than expected. Already there are op-ed articles highlighting how the costs could potentially rise quickly.

I’m not massively put off by that yet - I feel like I accidentally stumbled across a viable solution in my own use case: i.e. Use Kiro to go as far as you can, at least completing the project plan, and getting to the generated code ready to test. Then if you’re out of credits, switch to another (cheaper) coding assistant that can focus just on generating good quality code.

I would have loved to have completed my blog journey exclusively in Kiro - but I’d seen enough in my use case to recognise that there is genuine game changing potential in Kiro’s approach.

Right now I’m in the early process of learning about two potential projects coming my way. Whether it’s one of those or something else, price permitting, I’d be very keen to use Kiro to move quickly and accurately.

Additional Resources

• Claude-4 from Anthropic
• Kiro Tiers and Pricing
• Getting started with Hugo

This post is part of my AWS technical blog series. Found this helpful? Connect with me on LinkedIn or check back here for more AWS content and discussions.