Kiro turned one this week. AWS launched it in preview last July, and the anniversary post on the Kiro blog has some numbers worth reading: over 100,000 developers tried it in the first five days, and the count has kept doubling quarter over quarter since. GA arrived in November, then the CLI, powers, web and mobile surfaces.

I’ve been using it since the early preview days, and by now it covers most of my daily work: production-grade prototypes, IaC, internal tooling, documentation, cost analysis scripts. A year in, my honest take is that the tool is easy to start with and deceptively deep.

Before we start, a disclaimer: this is deliberately a simplified path. It doesn’t aim to be exhaustive, and it isn’t a zero-to-hero guide. The goal is narrower and, I think, more useful: give you a fast, structured way to approach Kiro and spec-driven development from zero, in one day, so you can then decide where to go deeper. I’ve made simplifications on purpose.

The gap between “I installed it” and “I actually know how to work with it” is real, but it’s smaller than you’d think. One well-spent Saturday closes most of it, using only official AWS material, all of it free. Here’s the plan I give colleagues and customers who ask me where to start: a morning and an afternoon, roughly three hours each.

Saturday morning: setup and foundations (about 3 hours)

Start with the official installation guide on kiro.dev. Kiro runs on macOS (Intel and Apple silicon), Windows 10/11 and Linux. Budget 45 minutes for the whole first-run flow, and note two things that matter more than they look:

  • You can sign in with an AWS Builder ID, Google or GitHub. An AWS account is optional.
  • The importer brings in your VS Code settings and extensions. Kiro is built on Code OSS, so your muscle memory transfers.

During first-run setup you’ll be asked about shell integration, which lets the agent run commands in your environment. It’s a big part of the agentic workflow, and it’s also a decision worth making consciously rather than clicking through: understand what the agent will be allowed to execute, keep command review on so you approve what runs, and read the privacy and security documentation before granting more autonomy. Whatever you enable, review what the agent does. That habit matters with every agentic tool, on day one and after a year.

Skip the docs binge and go straight to Kiro – Getting Started from Build to Operate on AWS Workshop Studio. It’s the best starting point I’ve found: 11 labs plus a code challenge, covering the whole lifecycle from building a web application to deploying it with IaC, then operating it from the CLI.

With one morning, aim at Labs 1-3: setting up Kiro, building a web application, deploying it with infrastructure as code. They’re sequential and they give you the full build-to-deploy arc. That’s a complete first experience of how the tool actually works.

One habit worth building from the very first lab: write specs before code. Kiro’s spec-driven workflow (requirements first, then design, then tasks) could feel slow at first, and pays for itself immediately: reviewing a one-page plan is far cheaper than reviewing 3,000 lines of generated code. The specs documentation explains the model; the labs make you practice it.

Saturday afternoon: configuration and the CLI (about 3 hours)

The afternoon is where Kiro becomes a system you configure to work your way. Two moves, in this order.

First, go back to the workshop for Lab 5 (MCP) and Lab 7 (steering, skills and custom agents). If I could keep only two labs from the entire workshop, these would be the two. MCP connects Kiro to your external tools and data sources; steering encodes your team’s standards (naming, frameworks, security requirements) so every generation follows them. Twenty minutes of writing steering files pays for itself the first week.

Second, spend the rest of the afternoon on Advanced Development with Kiro CLI, the official follow-on workshop. Time will be tight, so prioritize the context management module. The single most common failure mode I see with agentic tools is people dumping an entire repository into context and wondering why the output is generic. This workshop teaches you to be deliberate about it, and that lesson transfers to every agentic tool you’ll ever touch, on codebases of any size.

When you have more time

A Saturday gets you operational. These are the follow-ups I’d queue for later, in order of return on time invested:

  • Agent hooks: automations triggered on file events. Tests regenerated when code changes, docs updated on save. Small feature, big compounding effect.
  • The remaining workshop labs: security checks, cost analysis from the CLI, custom agents, and .NET modernization if that matches your job.
  • If you prefer learning through something playful, the Learn by Playing tutorial has you fixing bugs and shipping features on Spirit of Kiro. Nine steps covering steering, specs, hooks and MCP, and it’s genuinely fun.

What I’d tell you after a year of daily use

The features that changed how I work are steering files and specs. Steering means I write my constraints once and every generation respects them. Specs mean the agent and I agree on what we’re building before it builds it. Vibe coding is fine for throwaway scripts. For anything that ships, structure wins.

Also, an opinion: evaluate Kiro (or any agentic tool) on a real codebase, with real constraints encoded in steering. Toy repos hide the hard problems, so any tool could look great on them. The Saturday investment shows on the code you actually maintain.

To go further

If you spend a Saturday on this and something doesn’t click, tell me in the comments. I’m curious where the plan breaks.

Comment on Fediverse (Mastodon)