Every AI coding tool eventually runs into the same tension: move fast with loose natural-language prompts, or slow down and get precise about what's actually being built. Most tools pick a side. Kiro, the agentic IDE from AWS, refuses to. Instead, it gives developers two distinct working modes — Vibe and Spec — and lets the shape of the task decide which one to reach for.

Kiro is built on Code OSS, the open-source core of VS Code, so it feels familiar from the first launch: existing VS Code settings, keybindings, and Open VSX–compatible extensions carry over. What's different is what happens when you start talking to the agent living inside it.

Vibe Mode: Say It, See It, Ship It

Vibe mode is the conversational, low-friction side of Kiro. You describe what you want in plain language — "refactor this function for readability," "add unit tests for this service," "create a Lambda handler for this use case" — and the agent reads your current files and context, proposes changes, and applies edits once you accept them.

It's the mode that feels closest to pair programming with a fast, literal-minded collaborator. There's no upfront planning step, no document to review before code appears. That makes it well suited to:

1. Small, well-scoped refactors

2. Writing or updating tests

3. Generating boilerplate for a component or function

4. Quick prototypes, static pages, or one-off scripts

5. Asking questions about existing code

The trade-off is the same one every vibe-coding tool carries: the less precise the prompt, the more the AI has to guess, and guesses compound quickly once a codebase grows past a single file or a single afternoon.

Spec Mode: Plan on Paper Before You Plan in Code

Spec mode is Kiro's answer to that compounding-guesswork problem. Rather than jumping straight to edits, it walks a request through a structured, three-phase workflow that turns a vague idea into a reviewable plan — and only then into code.

Every spec lives in .kiro/specs// as a small set of Markdown files:

.kiro/specs/my-feature/
requirements.md   # or bugfix.md for bug fixes
design.md
tasks.md

1. Requirements. Kiro turns your request into user stories with acceptance criteria written in EARS notation (Easy Approach to Requirements Syntax) — a structured pattern such as: WHEN a user submits a form with invalid data, THE SYSTEM SHALL display validation errors next to the relevant fields. This format forces clarity: each requirement is unambiguous, testable, and traceable back to a specific behavior, instead of living as a fuzzy paragraph of intent.

2. Design. With requirements agreed on, Kiro drafts design.md — system architecture, component breakdown, sequence diagrams, data flow, error handling, and a testing strategy. Kiro also supports a design-first variant for cases where the technical approach is already known and requirements should be derived from it, with a choice between high-level design (for teams splitting the work) and low-level design (for checking feasibility fast).

3. Tasks. The design is broken into tasks.md — discrete, trackable implementation tasks with clear outcomes. Kiro can execute these one at a time or all at once; when running everything, it builds a dependency graph and runs independent tasks concurrently, tracking each as in-progress or complete in real time.

Because every phase produces a reviewable file, you can stop and edit at any point — Kiro respects the changes you make before moving to the next phase. There's also a Bugfix Spec variant, which swaps requirements.md for bugfix.md, structured around current behavior, expected behavior, and what should stay unchanged — useful for surgical fixes where scope creep is the real risk.

Choosing Between Them

The two modes aren't competing philosophies so much as different gears for different terrain:

Vibe Mode

1. Best for small, contained changes

2. Starts from a prompt

3. You review the diff

4. Fast, but guesswork compounds at scale

5. Good fit for refactors, tests, boilerplate, and exploration

Spec Mode

1. Best for multi-step features and team-facing work

2. Starts from a reviewable document

3. You review requirements → design → tasks, at each phase

4. Slower start, but far less rework

5. Good fit for new features, architecture decisions, and anything multiple people need to agree on before code exists

A common pattern among teams using Kiro is simple: default to Vibe for anything you could describe and verify in under a minute, and reach for Spec the moment a task touches more than one file, more than one person's expectations, or more than one edge case worth arguing about.

Beyond the Two Modes

Vibe and Spec sit on top of a few other pieces that round out Kiro's approach to agentic development:

1. Steering — persistent, versioned context about your architecture, conventions, and standards, so the agent doesn't need to relearn your codebase's rules every session.

2. Hooks — automations that trigger agent behavior on events in the editor or repository, reducing manual busywork around specs and tasks.

3. Autopilot vs. Supervise8d execution — a choice between letting the agent make and apply changes autonomously, or reviewing each change before it lands.

4. MCP support — the ability to connect the agent to external tools and systems via the Model Context Protocol, extending what it can act on beyond the local repo.

The Bigger Idea

Kiro's real pitch isn't "AI writes your code faster." It's that the bottleneck in most software work was never typing — it's the thinking that happens around the typing: clarifying requirements, aligning with a team, documenting a design, catching edge cases before they become bugs. Vibe mode speeds up the typing. Spec mode speeds up the thinking, by giving it a shape an AI agent can actually execute against.

Used together, they let a developer move at vibe-coding speed on the small stuff, while keeping spec-driven rigor in reserve for the work that actually needs it — which, for most teams, is most of the work that matters.

Note: Kiro is an actively evolving product from AWS; specific workflows, pricing tiers, and available modes may change. Check the official Kiro documentation for the current state of the product before standardizing team workflows around it.