Kiro vs. Claude Code: Spec-First Meets Prompt-First

I've run Claude Code in a terminal every working day for about a year. So when AWS Summit New York 2026 put Kiro back in the spotlight this week — a native iOS app to approve agent diffs from your phone, an AWS Security Agent that ships as a Kiro and Claude Code plugin — I didn't read it as "Amazon has a coding tool now." I read it as the clearest head-to-head yet between two genuinely different bets on how you should drive an AI coding agent.

Claude Code is prompt-first. Kiro is spec-first. That one difference cascades into everything else.

The two philosophies

With Claude Code, the conversation is the interface. You describe what you want, the agent plans, edits, runs, and you steer in the loop. The source of truth is the code it produces; the prompt is scaffolding you throw away.

Kiro inverts that. You write a spec — Amazon uses aerospace-grade EARS notation ("the system shall…") — and the spec becomes the source of truth. Code is treated as a build artifact generated from the spec. Under the hood Kiro routes between Claude Sonnet for the reasoning-heavy spec work and Amazon Nova for high-throughput code generation, all through Bedrock as one model plane.

Put plainly:

• Claude Code: prompt → code. The code is what you review, version, and own.
• Kiro: spec → code. The spec is what you review, version, and own; code regenerates beneath it.

Neither is obviously right. They optimize for different pain.

Where spec-first should win

The failure mode of prompt-first agents is drift. You prompt, it builds, you prompt again, and three weeks later nobody can reconstruct why the code does what it does — the prompts that produced it are gone. Spec-first keeps the intent as a living, versioned document. Kiro's event-driven Hooks lean into this: a hook fires on file save or PR open to re-run tests, regenerate fixtures, or cascade a spec change downstream without you re-prompting.

For a team where "what is this code supposed to do" is a recurring argument, a checked-in spec that the code must conform to is a real answer. That's the pitch, and it's a good one.

Where prompt-first still wins for me

Most of my work isn't "implement a fully-specified system." It's exploratory: poke at a bug, try an approach, throw it away, try another. Writing a formal spec before I know what I want is friction exactly when I want none. Claude Code's looseness is the feature — I can change my mind every thirty seconds and the tool keeps up.

There's also the reality I keep hitting on this blog: an agent that can't see the result of its work guesses. Claude Code in a terminal is blind to the running app unless I wire up screenshots or an MCP server. Kiro doesn't magically fix that either — but the spec-as-contract model at least gives you a fixed thing to test against, which is its own kind of verification.

The part I actually like: they're not mutually exclusive

The most interesting Summit detail wasn't Kiro itself — it was the AWS Security Agent shipping as both a Kiro plugin and a Claude Code plugin. Threat modeling and PR scanning that live in whichever tool you already use. That's a tell: Amazon isn't betting you'll abandon Claude Code, it's betting agent capabilities will be portable across IDEs. Which means the realistic future isn't "pick one" — it's spec-first for the systems you'll maintain for years, prompt-first for the work you're still figuring out.

What I'm going to try (and what I'll be testing for)

Kiro has a free tier — 50 interactions a month — and Pro at $19/mo, so this is genuinely triable on the Mac I already have, no new hardware required. I haven't run it yet; it only just landed internationally. Over the coming months I want to put it on a real project and answer:

• Does the spec actually stay the source of truth, or do I end up hand-editing generated code and breaking the loop within a day?
• How heavy is EARS notation in practice? Aerospace rigor is great until it's overhead on a side project.
• Hooks vs. my Claude Code setup. I already lean on hooks and skills in Claude Code — does Kiro's event model do something mine can't?
• The iOS app. Approving diffs from my phone sounds gimmicky; it also sounds exactly like the thing I'd use waiting for coffee. I want to know which.

The honest take going in: I don't think Kiro replaces Claude Code for me, and I don't think it's trying to. Prompt-first is how I explore; spec-first looks like how I'd maintain. The question I'll be testing is whether that line is real — or whether, once a spec is the contract, I stop wanting to prompt my way through anything at all.

Kiro is available now with a free tier; I'm planning to trial it against a real project over the next couple of months. Field report to follow.