AWS Kiro Is Here: Vibe Coding Enters the Discipline Phase

[[IMG:hero]]

“Vibe coding is fun. Genuinely, legitimately fun.”

I’ve been using Cursor and Claude Code almost every day since early 2026 — business tools, side-project prototypes. The moment an idea hits, I can write code. For someone who once walked away from engineering in frustration, this felt like an actual revolution.

But over the past month or two, something nagged at me. “I can build things, but I’m not sure they’ll keep running.” “Code I wrote on a whim is unreadable to me three weeks later.” The same unease started showing up in industry writing — three major pieces in the past month alone. A Cursor Composer 2 review. IBM’s “from build to operate” declaration. AWS Kiro. Reading them side by side, they looked like different answers to the same question.

I noticed: they all point in the same direction. Peak vibe coding is handing the baton to a new “discipline phase.” Today I want to break down AWS Kiro — the centerpiece of that signal — through the eyes of a former dropout engineer.

Vibe Coding: The Joy, and the Growing Unease Behind It

Let me start with a personal failure. I want to stay at the same level as my readers, so I’ll be honest.

In March, I built a customer-support dashboard for my team using Cursor and Claude Code. Slack notifications, auto-import from Notion, filter UI — all taking shape in three days. “This is literally magic,” I told coworkers, showing it off like a proud parent. A CS-background person who had stepped away from code, building this. Of course I was riding high.

The problem hit two weeks later. A spec change came in, I opened my own code, and had no idea what I had been thinking when I wrote it. I asked Claude, “What does this function actually do?” Claude replied: “This could be interpreted in several ways depending on context.” The person who wrote it and the AI both got lost — together.

This isn’t just my problem. Data backs it up.

• METR (Model Evaluation & Threat Research) ran an RCT where AI tool use made development tasks slower than expected (METR official blog)
• GitClear found that AI-assisted code has a higher refactor and deletion rate than traditionally written code
• Security scanners like Cisco CodeGuard and Tenzai reported detecting 10–45% more vulnerabilities in vibe-coded output

My lived experience and that data point the same direction. The bridge between “the joy of making something work” and “the quality that keeps working” still isn’t there.

I’m not here to lecture anyone on spec-driven development. I’m still figuring it out myself. But in the middle of that search, AWS Kiro showed up — and demonstrated what “spec-first” actually looks like in practice. That’s what I want to share today.

What AWS Kiro’s “Spec-Driven AI Development” Actually Looks Like

[[IMG:1]]

AWS Kiro is an AI-first IDE from AWS, built on a Visual Studio Code fork. Its core workflow centers on an interactive dialogue with an AI agent, structured around “spec → design → implementation.” As of May 22, 2026, English-language deep-dives are still sparse; XenoSpectrum published one of the first detailed breakdowns that day.

The key insight of Kiro is that it forces you to produce three files interactively before writing any code.

1. requirements.md — What are you building? Written in EARS notation (Easy Approach to Requirements Syntax), with user stories and acceptance criteria.
2. design.md — How are you building it? Data flow, API sequences, TypeScript interfaces, ER diagrams, and unit test strategy.
3. tasks.md — In what order? Discrete tasks, each referencing its corresponding requirement number.

What makes this work is simple: it just forces you to write things at the right time. The content is identical to what good old-school development always demanded — requirements analysis, high-level design, task decomposition. Experienced engineers know this cold. It’s exactly what was falling through the cracks in the speed of vibe coding. Kiro demands those three things upfront.

The other important concept is Steering Files: Markdown documents containing project-specific rules that Kiro always references — “use Tailwind v4,” “wrap all API errors in an error boundary.” If you’ve been using CLAUDE.md or AGENTS.md, this is the same lineage, baked in as a core feature.

Pricing runs across Free / Pro / Pro+ / Power tiers, published on Kiro’s official pricing page (as of May 2026). The free tier is a valid starting point; check the primary source for current details. Supported OS: Mac, Windows, Linux. Model selection includes Claude Sonnet among others.

Why “Spec-First” Right Now: Three Numbers That Mark the Tipping Point

[[IMG:2]]

“Spec-first is important” has been said in software engineering for decades. So why is a dedicated IDE like AWS Kiro showing up now? Here’s my read.

Vibe coding spiked the speed of writing. That exposed the cost of what happens after you write. When requirements took two weeks to nail down, there was time to iterate mid-build. Now that a prototype materializes in three days, you can arrive at maintenance hell three days after a half-baked spec.

Three numbers:

• METR RCT’s “19% slower” effect: Experienced developers using AI tools trended toward slower outcomes, not faster. One cited cause: “missing ambiguity in specs that you’d otherwise catch”
• GitClear’s “rising deletion rate”: AI-assisted code gets deleted or heavily revised at a noticeably higher rate than traditionally written code — a sign that people are writing before specs are settled
• Cisco CodeGuard / Tenzai’s “10–45% vulnerability rate”: Multiple security scanners reported elevated security defect rates in vibe-coded output, primarily attributed to missing auth, authorization, and input validation at the spec stage

The common thread: missing specifications. Speed increased; the cost of spec gaps became visible. AWS Kiro responds by saying “write the spec before you write the code” — and enforces it at the IDE level. Not a motivational message. A structural change to the development workflow.

When I first saw these three data points, my honest reaction was: “oh no, that’s me.” As a former dropout, there’s something strangely validating about the fact that the same problems professionals are hitting are now the same ones I face. Same playing field. Same tools. Same solutions.

Reading the Maturity Trio: Cursor 2, IBM, and Kiro Pointing One Way

I’ve been calling the three recent moves the “Maturity Trio.”

Event	Timing	Substance	The signal
Cursor Composer 2	April 2026	Enhanced long-horizon agent-driven task execution. SiliconANGLE called it “Cursor becoming the protagonist”; The Register raised code quality concerns. Evaluation criteria now necessary.	The flagship vibe coding IDE started taking execution responsibility
IBM’s “build to operate” declaration	May 2026	Claimed the AI agent battleground has shifted from “building” to “running.” From single prompt execution to long-term agent quality.	Running sustainably outweighs just running once
AWS Kiro (renewed attention)	May 2026	Spec-driven AI development IDE; forces spec, design, and task decomposition before code generation	”Decide what to write before you write” becomes an IDE standard

Three different moves, one shared answer to: “Now that vibe coding made us faster, what’s the new problem?”

• Cursor takes execution responsibility — delegating it to agents and the IDE
• IBM takes operational responsibility — building it into agent design from the start
• AWS Kiro takes spec responsibility — enforcing it through the IDE workflow

The common denominator: clarifying who owns what. Not “does it work?” but “who is responsible, and to what extent?” That’s the discipline phase.

This connects directly to nagi’s argument that “AI you call when needed” is over. When AI shifts from “called on demand” to “always resident,” design carries more weight. Kiro’s spec-first workflow is a natural evolution in that trajectory.

Trying a “Kiro-Style Flow” on My Own Business Tool

[[IMG:3]]

For those not yet ready to install Kiro, here’s the mini-experiment I ran this week — fully replicable with Claude Code or Cursor (this is a simulated three-file structure, not a live Kiro demo).

The project: a bot that reads support inquiries from Slack, auto-classifies them, and saves them to Notion. A natural target for a CS-background person trying to automate their own job.

Step 1: Write requirements.md first (15 minutes)

# Slack-to-Notion Support Bot — Requirements

## User Stories
- As a CS team member, I want incoming messages in #support
  automatically saved to Notion's "Inquiry DB"
- I want each entry auto-classified by type (Bug / Question / Feature Request)

## Acceptance Criteria (EARS)
- WHEN a new post appears in Slack THE system SHALL create a new Notion row
- WHEN post text contains "not working," "error," or "crashing"
  THE system SHALL classify type as "Bug"
- IF Notion API fails 3 consecutive times THE system SHALL
  send a DM to CS Lead with the failure details

Step 2: Design in design.md (20 minutes)

One document covering data flow, error handling, credential storage, and test strategy. Talking through this with Claude before writing a line of code surfaced three “oh wait, I missed that” moments — in my case, how to prevent duplicate saves of the same message.

Step 3: Break it down in tasks.md (10 minutes)

• T1: Slack Bolt SDK initialization (acceptance criteria: 1, 2)
• T2: Notion API call module (criteria: 1)
• T3: Classification logic (criteria: 2)
• T4: Retry + DM notification (criteria: 3)
• T5: Unit tests (criteria: 1, 2, 3)

Step 4: Write the code

Only now do I hand things to Claude Code: “implement starting from T1.” With the three files already shared, output quality felt noticeably higher. More importantly, when I open this code three weeks from now, I’ll know why it was written this way.

Total time: 45 minutes for spec, design, and tasks — 2 hours for the code. Old me would have poured 3 hours directly into code and thrown half of it away. The 45-minute preamble reclaimed 2 hours.

Three Pitfalls (Honest Account)

Kiro-style flow isn’t magic. Here are three places I got stuck.

Pitfall 1: Over-specifying into paralysis

The first time, writing requirements.md got so enjoyable that I produced a 2,000-word document. By the time I got to design and tasks, I had no energy to actually build anything. Target: 3–5 user stories, 10 or fewer acceptance criteria. Leave room to revise — perfection isn’t the goal.

Pitfall 2: Filling design.md with code

The temptation to write long code blocks in design.md is real. Resist it. design.md is for policy; code belongs in tasks.md and beyond. My rule: interface definitions (types) are fine; implementation bodies are not.

Pitfall 3: The burden of keeping three files in sync

Updating all three on every spec change is genuinely exhausting. My rule: major changes get reflected everywhere; minor ones I update only in implementation. Once a week I take five minutes to sync — otherwise the gap between spec and code grows unmanageable.

A note for beginners: If this feels like too much, start with requirements.md alone. Skip the other two. Just writing user stories before writing code, practiced for one week, will noticeably improve what you hand to Claude. As nagi argues, you don’t need to be able to write code anymore — but the ability to write user stories is a muscle worth training early.

Closing: “It Works” and “Spec-First” Aren’t Opposites

Three points to take away from today.

• AWS Kiro is a spec-driven AI development IDE. The core is an interactive workflow that produces requirements.md / design.md / tasks.md before any code is written
• Cursor Composer 2, IBM’s “operate phase” declaration, and AWS Kiro are three signals pointing toward the same next chapter: the discipline phase beyond vibe coding
• You don’t need to install Kiro to start. A mini experiment with Claude Code or Cursor is doable this week. Writing requirements.md alone is a worthwhile first step

One last thing on where I stand. I’m not giving up the “if it works, ship it” mindset. The joy of making something work is what pulled me back to code after I had given up. That stays.

But I learned that “if it works” alone means crying three weeks later. I’m done building on a half-baked spec and patching retroactively. Instead: “write the spec in 15 minutes, build with vibe, and have it keep running.” That’s the whole change.

One homework assignment: write a requirements.md for something you’re about to build (or just built). Give it 15 minutes. Once you write it, you’ll see exactly what was missing. That’s step one into the discipline phase.

I’ll be back next week with more places I got stuck. Let’s get into the weeds together, and get better together.

---

Sources

• AWS Kiro official site: https://kiro.dev/
• AWS Kiro pricing: https://kiro.dev/pricing/
• AWS Kiro specs documentation: https://kiro.dev/docs/specs/quick-plan
• AWS Kiro steering documentation: https://kiro.dev/docs/steering/
• XenoSpectrum “AWS Kiro breakdown” 2026-05-22 (URL pending)
• METR “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity”: https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
• GitClear “AI Copilot Code Quality 2024” (URL pending)
• Cisco CodeGuard / Tenzai security scanner reports (URL pending)
• IBM “The shift from build to operate for AI agents” (URL pending)
• Internal: nagi “AI you call when needed” is over
• Internal: nagi You don’t need to write code to start