Kiro: The AI Teammate That Doesn't Break Prod

#ai #kiro #agentskills #agents

I had the honour of presenting another session at the annual Amazon Web Services (AWS) Summit in Johannesburg, for the fifth time.

This year the AWS Summit Johannesburg moved to the Gallagher Convention Centre in Midrand, not the usual Sandton Convention Centre we’d grown used to over the years. New venue, more floor space, and the same passion shared among the people in the room.

A bit of history first, because five years goes quickly. Last year I spoke twice: Chaos Engineering in the Community Lounge (now better known as the Developer Community Theatre), and MCP on the main stage for customers and partners. Before that I’ve covered Infrastructure as Code, GenAI, and FinOps. Different topics, but the same thread runs through all of them: the gap between what the technology promises and what actually happens when it meets production. This year I wanted to sit squarely in that gap. The topic: how NOT to break production with AI. Specifically, with Kiro.

If you haven’t picked it up yet, Kiro is AWS’s AI-native integrated development environment (IDE), a customised fork of VS Code built for spec-driven, agent-assisted development. It’s genuinely good. And that is exactly the problem. The better these tools get at writing and shipping code, the easier it becomes to let them drive straight into production without the guardrails we would insist on for any human engineer.

My actual problem with AI

Let me start with my real problem with AI. Not the sci-fi, take-over-the-world problem. Something far more specific and far more personal: it keeps breaking code that was working perfectly fine before I asked it for help.

That’s the whole talk in one sentence. You have something that works. You ask for a small change. You get the change, plus three others you never asked for, and now the thing that worked, doesn’t.

The real problem: it’s sure, even when it shouldn’t be

Here’s what makes that dangerous. The AI is so sure of itself, even when it has no business being.

Picture a simple graph. Up the side, how confident the AI sounds. Along the bottom, how much it actually knows. You’d hope the two climb together. They don’t.

What we have today is a dangerous peak. This generation of vibe coders, and every fresh AI agent, sits right at the top of it: maximum confidence, minimum understanding. Meanwhile the senior engineers are all the way down in the valley. Quiet, calm, mildly terrified. Not because they know less, but because they’ve been burned enough times to respect what they don’t know.

Which gives us lesson one, and if you take nothing else home, take this: confidence is not competence. The AI sounds exactly the same whether it’s right or completely wrong. Same tone, same swagger. There’s no wobble in its voice to warn you. You are the warning system.

Why it keeps breaking working code

Underneath all of that sits one root cause. You and the agent never agreed on the boundary. What’s fair game to change, and what has to stay exactly as it is. Nobody drew that line, so the agent drew its own, somewhere you didn’t expect.

Everything else in the talk comes down to drawing that one line.

The fix, in a single sentence

Get it to write the plan before it writes the code.

Almost every mess I’ve made came from doing the opposite. No plan, vibes only, and a diff I had to clean up afterwards. Plan first, and the agent has to show you its thinking before it touches anything that matters.

Don’t ask Kiro for code. Ask it for the plan.

This is where Kiro earns its place. Don’t open with “write me the code.” You’ll get something that looks right and quietly hides every assumption it made to get there.

Ask for the plan first. A plan is something you can argue with before a single line exists. You can poke holes in it, fix the boundary, catch the assumption that would have cost you an afternoon. Then, once you’re happy with it, let it write the code.

Same tool. Completely different outcome. The only thing that changed is the order you did things in.

Key takeaways

If you skipped to the bottom, here’s the whole talk on one slide:

Ask for the plan, not the code. A plan is something you can argue with. A diff is something you have to clean up.
Understand it, test it, then change it. In that order. Never change what you don’t yet understand.
Spec what ships, vibe only what you’d throw away. Spec-driven for anything going to production. Vibe coding is fine for the prototype you’re going to bin.

Teach it your rules once, in steering. Put your standards in Kiro’s steering files so you’re not repeating yourself every prompt.

A gate only counts if it exits 2. A check that always exits 0 can’t fail the build. That’s not a gate, it’s decoration.
It sounds the same when it’s wrong. So you stay the reviewer. Always.

Thank you, and see you next year

The event is only as good as the people in the room, and this year’s crowd was something else. The questions after the session were sharp, and a few of you stuck around to argue about whether your gate actually exits 2. That’s exactly the conversation I wanted.

Thank you to James Hickman for the incredible keynote, and for opening the Partner Summit the previous day. Catching up with you, and experiencing that true customer obsession, the energy, the passion, and the love you have for the brand, was a real highlight. Thank you for being an incredible human, and for always doing it with a smile.

The AWSome community

Huge thanks to the AWS teams, Natalia Stones, Echo Pan, Francesca Sassi, Veliswa Boya, and Olivier Leplus. Working with you on this event has been an incredible experience. Special thanks to you, the customers, the builders, and everyone who came through the talk.

Always so grateful to spend time with the special connections I’ve made over the years: Phyllis Madaba, Thoko Mathenjwa, Rejoice Mucheri, and Henri Zietsman.