This week, spec-driven development (SDD) landed as a product and a production case study at the same time. AWS’s Kiro got covered as a system that generates requirements, design, and code in sequence, and Tokio Marine & Nichido was reported to have put it into production, with prototyping time dropping from six months to a single day. It even came with a billing: the third development methodology, after waterfall and agile.

What was I doing that same week? I had just turned my spec-driven writing workflow into a skill — the piece where I ran a spec through adversarial review the way you would code, and killed holes like a missing SSRF guard before implementation. The industry had productized the thing and put it into production. I was cranking it by hand.

The ideas are nearly identical. And once I dug in, the bottleneck lands in the same place too. The difference is whether you build a detour around it, or wall it off yourself.

“Spec first” is a shared antithesis

Kiro’s pitch and my workflow start from the same place: an antithesis to vibe coding, where you toss prompts at an AI and let it write code straight away. Fix the spec first, then implement. On that point we agree completely.

Kiro turned that into a product. Requirements get structured in EARS notation, a fixed syntax, and flow down from there into design and code. The choreography humans used to run by hand every time — “requirements first, now design” — got built into the tool itself. Six months to one day is, I think, what automating that choreography buys you.

I hold the choreography by hand. Claude Fable 5 writes the spec; then I switch to Sonnet 5 for implementation. The judgment-dense stage and the mass-production stage go to different models. Up to this point, granularity aside, I’m doing the same “spec first” that Kiro is.

The fork: whether you can skip the review

When I started writing this, I assumed productized SDD was the side that skips spec review to sell speed. I was going to frame the contrast that way. Then I read the official docs, and it was the other way around.

Kiro’s standard flow (Feature Specs) lets you place human approval checkpoints at each stage — requirements, design, tasks. On top of that, there’s Analyze Requirements, an official spec-review feature that flags logical inconsistencies, ambiguities, and gaps across your requirements. The product doesn’t just fix the spec first; it ships a stage for doubting the spec it just fixed.

But it’s optional. Kiro also has Quick Plan, a mode that generates requirements, design, and tasks in one pass with no approval gates — positioned, the docs say, for when you’re on familiar ground and want speed. So Kiro holds spec review as a feature and leaves whether to use it up to you.

My workflow doesn’t make it a choice. Once a spec is written, it goes through an adversarial subagent review before anything reaches implementation. In the last piece, that review turned up three Highs: a missing SSRF guard that passed yt-dlp’s external URLs straight into the next stage, a loose host check that matched youtube.com as a substring and would wave spoofed hosts through, and a regression that would treat video-less pages as videos and break existing behavior. All three were found at the spec stage, before a single line of code. A hole in a spec, caught before implementation, costs nothing but a spec edit.

Deciding whether to skip is already part of the review

Since a piece from a while back I’ve been writing that AI-written code is bottlenecked by review. In the last piece, the same thing held one level earlier, at the spec. The faster and more abundantly you can generate requirements, the further forward the bottleneck moves, into spec review. That jam lands in the same place whether you hand-crank or use the product. Analyze Requirements exists, I think, because the product side can see that bottleneck too.

Same spec review, different angle of attack, though. Analyze Requirements cross-checks requirements against each other — contradictions, ambiguities, gaps. The adversarial review I run reads the spec from the breaker’s side. A missing SSRF guard registers as a gap only when you read the spec asking how an attacker would use the URLs yt-dlp returns.

Skipping the review isn’t wrong in itself. The docs say as much: for a well-understood feature where you trust Kiro’s output, speed-first Quick Plan is fine. A path you’ve walked many times doesn’t need the same weight of review every single time.

The reason my workflow still has no such option: judging whether a spec is safe to skip requires reading the spec. Whether it’s well-understood, whether the output deserves trust — you can only say after looking. That judgment is already doing part of the review you meant to skip. Cheaper, then, to throw the judgment away and run the review every time. However many specs in, there’s no room left to waver.

Side by side

Closing

Watching Kiro get called the third development methodology, I’d say that in the war of ideas, the spec-first side won. The antithesis to vibe coding became a product and reached production. Even the jam — spec review becoming the bottleneck — was already visible from the product side. The thing that missed was my own assumption that they were selling speed by skipping review.

But having the feature and running it every time are different things. The faster requirements pour out, the more attractive the detour of skipping review becomes. What my hand-cranked workflow actually does is wall that detour off from the inside. The bottleneck sits in the same place; what differs is what you do about it. That, it turned out, was the whole story.