Kiro vs Claude Code: Spec-First IDE or Terminal Agent

Kiro and Claude Code are both agents that read a codebase, edit files and run commands, but they start from different places. Kiro starts from a spec: for a feature it writes requirements.md, design.md and tasks.md, you approve each phase, and then it works through the tasks. Claude Code starts from your prompt and plans only when you ask it to, in plan mode or through the files you give it. Kiro began as an IDE and now also runs as a CLI, on the web and on mobile; Claude Code began in the terminal and now runs in editors, a desktop app and the web. Pick Kiro if you want the structure built in, Claude Code if you want to decide the structure yourself.

What each one is

AWS’s Kiro documentation overview↗ (opens in a new tab) describes Kiro as an agentic coding service that turns prompts into detailed specs, then into working code, docs and tests. Kiro’s docs say one agent harness runs behind every surface: the Kiro IDE, the Kiro CLI, the web, an iOS app and editors that speak the Agent Client Protocol. You sign in with GitHub, Google, AWS Builder ID, IAM Identity Center or your organisation’s identity provider, and its FAQ says you do not need an AWS account. The model picker offers Auto plus a list that includes Anthropic’s Claude models, OpenAI’s GPT models and several open-weight models.

Claude Code is Anthropic’s agent for Claude models, signed in with a Claude or Console account or through Amazon Bedrock, Google Cloud or Microsoft Foundry. Its surfaces are compared in Claude Code desktop vs CLI vs VS Code. Both are billed differently; check each vendor’s current plans.

Specs and plan mode

A Kiro spec lives in .kiro/specs/<name>/. You can go requirements first, or design first when the architecture is already fixed, and approve or edit each file before the next is written; Quick Spec does all three in one pass when you trust the output. Kiro’s feature specs page↗ (opens in a new tab) says requirements.md uses EARS notation, so each requirement reads “WHEN [condition or event] THE SYSTEM SHALL [expected behaviour]” and can be turned into a test. Bug fixes get a bugfix.md that records current, expected and unchanged behaviour instead.

Then Kiro runs the tasks and marks each one in progress or completed as it goes. Run them all and it works out which depend on which and runs independent tasks in parallel waves. For smaller jobs Kiro also has a plan mode, reached with Shift+Tab or /plan in the CLI, which explores and produces an implementation plan without the three formal documents.

Claude Code’s nearest equivalent is its plan mode: Shift+Tab until the status bar shows plan mode, /plan, or claude --permission-mode plan. Claude reads, explores and writes a plan, and edits nothing until you approve it. The plan is one document for one session, with no approval gate between requirements and design and no task runner. What spec-driven development adds on top is explained in spec-driven development, and plan mode itself in Claude Code plan mode.

Steering and CLAUDE.md

Kiro’s standing instructions are steering files↗ (opens in a new tab): Markdown in .kiro/steering/ for the workspace and ~/.kiro/steering/ for you, with the workspace winning a conflict. It can generate three foundation files, product.md, tech.md and structure.md, and each steering file can be included always, only when matching files are in play, manually, or automatically when a request matches its description. Kiro reads AGENTS.md too.

Claude Code reads CLAUDE.md from the working directory and the directories above it at launch, and from subdirectories as it reads files there. It uses AGENTS.md only when no CLAUDE.md exists, and a CLAUDE.md can import other files with @path. Path-scoped rules in .claude/rules/ do what Kiro’s file-match inclusion does. Examples are in CLAUDE.md examples.

Hooks

Both have hooks, and both can stop a tool call before it runs. Kiro’s hooks↗ (opens in a new tab) are JSON files in .kiro/hooks/. Triggers include Prompt Submit, Agent Stop, Pre and Post Tool Use, and, in the IDE, File Create, File Save, File Delete and Pre and Post Task Execution for spec tasks. An action either runs a shell command or adds a prompt to the conversation. File triggers fire only on changes the agent makes, not on your own saves.

Claude Code’s hooks reference↗ (opens in a new tab) lists far more events, among them PreToolUse, PostToolUse, UserPromptSubmit, Stop, SessionStart and SubagentStop. Hooks live in settings files, plugins or a skill’s frontmatter, and can be a shell command, an HTTP request, an MCP tool call, a prompt for Claude to evaluate or a subagent. A PreToolUse hook that exits with code 2 blocks the call. What Kiro has that Claude Code lacks is the spec-task triggers; Claude Code has no spec tasks to trigger on.

MCP

Kiro reads MCP servers from .kiro/settings/mcp.json in the workspace and ~/.kiro/settings/mcp.json for you, merged with the workspace winning. A remote server takes a url, optional headers and OAuth settings; autoApprove and disabledTools narrow what runs without asking. Claude Code adds servers with claude mcp add, private to you by default, or in a committed .mcp.json with --scope project, and signs in to OAuth servers through /mcp.

Autopilot, Supervised and permission modes

Kiro’s IDE has two autonomy settings. Its Autopilot page↗ (opens in a new tab) says Autopilot, the default, works end to end without asking at each step, while you can view all changes, revert them or interrupt. Supervised yields after each turn that edits files and shows the changes as hunks to accept or reject. Under both sits a permissions.yaml of allow, ask and deny rules per capability, where deny always wins and workspace rules are stored outside the repository so a cloned project cannot grant itself permissions.

Claude Code has more steps between asking and acting. Terminal and VS Code sessions now start in auto, where a classifier approves most actions and stops risky ones; Manual asks before most edits, commands and network access; acceptEdits lets file edits through; bypassPermissions is for isolated containers only. Scripted runs with claude -p still start in Manual. Allow and deny rules sit under the modes, as in Kiro. So Kiro acts and lets you review, while Claude Code lets a classifier or you decide before each step. How far to loosen it is in Claude Code auto-approve.

Who each suits

• Teams that want requirements, design and a task list reviewed before code, every time: Kiro builds that into the product.
• People who want to choose the ceremony per job, from a one-line fix to a full spec: Claude Code, with plan mode and your own files.
• Organisations on AWS identity, with IAM Identity Center and centrally managed MCP servers: Kiro fits that estate.
• Anyone who wants Claude models specifically: both offer them. Kiro also offers other vendors’ models; Claude Code is Anthropic’s own agent.
• Terminal-first developers: both now have a CLI; Claude Code has been terminal-first from the start.

Comparing Kiro with Codex instead? The same split applies: Codex, like Claude Code, starts from a prompt, reads AGENTS.md and plans on request. The Codex side is in Claude Code vs Codex.

Using Kiro-style specs with Claude Code

You can borrow the method without the tool. Keep the three files per feature, write requirements in EARS, and tell Claude Code in CLAUDE.md how to use them. Plan mode then works from written criteria rather than a sentence you typed from memory.

## Specs
- Every feature has docs/specs/<feature>/ with requirements.md, design.md and tasks.md.
- requirements.md uses EARS: WHEN <condition> THE SYSTEM SHALL <behaviour>.
- Do not write design.md until I approve requirements.md, or tasks.md until I approve design.md.
- Implement one task from tasks.md at a time, tick it off, and name the requirement it meets.
- If a task shows the design is wrong, stop and propose a change to design.md first.

The part neither tool does for you is keeping the tasks where other people see them. A tasks.md is right for the agent at work and invisible to the person who decides what gets built next. On fenbs, each outcome someone would check becomes a task with a Problem box for the requirement and a Plan box that is rewritten as the work changes. Kiro and Claude Code both connect to https://fenbs.ai/api/mcp, move tasks through To Do, Next Up, In Progress and Completed, and every change is recorded in History under the assistant’s name, on your behalf.