I Failed With Kiro. Then I Tried Again.

Jean Velez — Mon, 13 Jul 2026 22:17:36 +0000

The first time I used Kiro, it recommended services I've never worked with like AWS Device Farm for scanning barcodes off a bookshelf. The second time, it built me a working app with a sane architecture.

My name is Jean. I'm an Solutions Architect at AWS, based in Puerto Rico. Before this I wrote code full time. I still do when I can.

Personal projects, demos for customers, workshops, community events. Being an SA gave me exposure to dozens of services but took away the long blocks of focused coding time. I wanted both. Kiro ended up being how I got them back.

Two months after Kiro launched, I tried it on a side project.

Shelftalk

My fiancee owns over 1,000 books. She also buys books for her friends more than for herself. The problem: nobody can remember which books she liked, which ones she already has, or which ones her friends have. Duplicates happen constantly.

I wanted something that could scan a barcode, pull metadata, and build a shared catalog across people. Not just inventory. Preferences, ownership, the social context around what's on someone's shelf. Books, DVDs, videogames, anything with a barcode.

I opened Kiro and prompted it.

First Attempt

No spec. No constraints. No context.

"Build me a scanning app for DVDs and videogames."

It went badly.

Kiro defaulted to library versions that hadn't been updated in years. The scanning flow it built took hours per item. The architecture used Device Farm. That's a mobile testing service. For scanning barcodes off a bookshelf.

I don't blame the tool. I gave it nothing. No requirements, no research about what metadata APIs actually exist for books and media, no cost constraints. I typed a sentence and expected production-grade software. It responded the only way it could: by guessing. The guesses were expensive and wrong.

I closed the project and forgot about it for a few weeks.

Second Attempt

When I came back, I installed AI-DLC as steering files. AI-DLC is open source (github.com/awslabs/aidlc-workflows). It tells the agent to work through requirements first, then design, then implementation. Structured. Sequential.

This time Kiro didn't jump to code. It asked questions. What does scanning mean in this context? What metadata providers exist? What's the cheapest architecture that solves the problem?

The spec found gaps I hadn't thought about. It caught that the barcode libraries I'd vaguely imagined were deprecated. It steered the stack toward TypeScript CDK with containers and serverless, which made sense for the workload. And each iteration built on the previous one. The spec remembered what we'd decided, so I wasn't re-explaining context every session.

Today Shelftalk is in private beta. A few coworkers are testing it. I've cataloged about 200 books. There are still challenges, specifically that not all books have reliable online metadata (Google Books doesn't cover everything). But it works. I use it. And the speed from first prompt to working beta would not have happened if I'd kept prompting without structure.

MCP surprise

Kiro connects to MCP servers, and there are a lot of free ones available for different data sources.

Some of them have write actions. One wanted to create files in my project directory. Another had permissions I couldn't fully assess at a glance.

I'm new to this ecosystem. Kiro flagged every write action before executing. It showed what the server was requesting, the scope, and asked for confirmation. I didn't have to dig through logs or hope for the best. It was right there.

That matters more than it sounds. When you're learning something new, you don't always know what you don't know. Having a tool that catches risk before you accidentally approve something irreversible lets you explore without fear.

SA Work

The personal project is where I learned the workflow. My job is where it paid off.

I prepare demos, build workshops, and create technical content for developer events across the Caribbean. I run series called Modernizate and Desafio. Over the past year those events reached 500+ developers across 23 sessions. Every one of them needed fresh, accurate, tested content.

Before Kiro I produced about 3 demos a month. Now it's around 9, and they go deeper. Most of those 23 events would have shipped with less depth or not happened at all if prep still took the old amount of time.

The numbers at the task level:

Task	Before	Now
Workshop section update (content + validation + env testing + best practices)	12 hours	2 hours, running 4 in parallel	6x
Demo, services I already know	4 days	8 hours	4x
Demo, unfamiliar services (research + learn + code)	2 weeks	2-3 days	4-5x
Monthly demo volume	3	~9, deeper	3x

Parallel agents are what make the workshop number possible. I don't work through sections sequentially anymore. I start 4 at once. Each one runs in its own context. I review the output, adjust, and move on.

The unfamiliar-services improvement is the one that changed my work life. An SA is always expected to learn something new and deliver on it fast. The spec forces understanding before implementation. By the time running code exists, I actually know the services I just used, because I had to define what I needed from them first.

AI-DLC is open source. If you want the same workflow, load it as steering files and start every project with a spec. github.com/awslabs/aidlc-workflows

Developer to SA

When I coded full time, I built things slowly and thoroughly. When I moved to SA, I gained breadth but lost build time. The job is advisory. You know the architecture but you don't always write it.

Kiro gave me both back. I build real demos in hours. I learn unfamiliar stacks by working through the spec, which teaches me the structure as I build. I deliver community content at a pace that sustains 500 developers a year. None of that was possible at my old speed.

One Year

Kiro turns one this week. The moment it clicked for me was seeing the gap between attempt one and attempt two on the same project. Same tool. Completely different outcome. The variable was structure.

If you take one thing from this post: start from a spec. Don't prompt into the void. Define what you need, let the agent figure out how. It works.

What's the workflow change that shifted how you operate? Drop it in the comments. I want to read those stories.

DEV Community: Jean Velez