How to Use Kiro IDE: Setup, Specs, Steering and a Python Walkthrough

In short: Kiro is AWS's AI IDE built on a VS Code-style interface. Instead of writing code straight from a prompt, it first turns your request into three documents (requirements, design and tasks), and only starts coding once you approve them. Steering files hold the rules you would otherwise repeat in every chat. Details below were checked against Kiro's official docs on 2026-10-12, since plans and features change quickly.

Install Kiro and sign in

Kiro is a desktop IDE with a VS Code-like layout and agent-based coding built in. According to the installation docs, the IDE runs on macOS, Windows 10/11 and supported Linux distributions, on both x64 and ARM64.

1. Download the installer for your OS from kiro.dev.
2. Run the installer.
3. Sign in when prompted.
4. Optionally import your VS Code settings and extensions.
5. Open a project folder from the welcome page.

The authentication docs list these sign-in options: Google, GitHub, AWS Builder ID, AWS IAM Identity Center (you need your organization's Start URL and Region), and an external identity provider through your work email. An AWS Builder ID is a free personal ID that is separate from an AWS account, so you can use Kiro without owning an AWS account.

After sign-in you get the familiar layout: a file explorer on the left, the editor in the middle, and the chat/agent panel alongside it. If you have used VS Code, most shortcuts carry over, for example Ctrl+P (Cmd+P on macOS) to open a file, Ctrl+Shift+P for the command palette, and Ctrl+B to toggle the sidebar.

What does Kiro cost?

As listed on the pricing page on 2026-10-12, credits are the unit that limits usage:

Paid plans can buy extra credits at $0.04 per credit. The Free plan includes Claude Sonnet 4.5 and some open-weight models, subject to rate limits. Prices and credit amounts have changed before, so check the pricing page before you subscribe.

Create your first project

There are two ways to start.

Option 1: open an empty folder. Choose Open Folder from the welcome page, then describe the project in the chat panel. Kiro proposes a file structure and creates it.

Option 2: start from a template. Create a new project from the welcome page and pick a language or framework template. Kiro generates the basic folder structure and config files for you.

Once a project is open, type a request such as "Build a to-do API with FastAPI" in the chat and the agent gets to work.

Core idea 1: specs

Specs are what set Kiro apart from most AI coding tools. For a feature, Kiro does not jump straight into code. Per the specs documentation, each spec produces three files:

1. requirements.md covers what to build: user stories and acceptance criteria. Kiro writes requirements in EARS notation, in the form "WHEN [condition] THE SYSTEM SHALL [behavior]," which makes them testable.
2. design.md covers how to build it: architecture, data model, sequence diagrams, error handling and testing strategy.
3. tasks.md is the implementation plan broken into trackable tasks. Each task can be run individually or all at once, and its status updates as work completes.

You can choose a Requirements-First flow (requirements, then design, then tasks) or a Design-First flow (design first, which suits projects with strict architectural or non-functional constraints). There is also a bugfix spec for fixing a bug with root-cause analysis, and a Quick Spec option that generates all three files without approval gates.

The documents open as ordinary Markdown in the editor, so you can read and edit them. In the standard flow you review each stage before moving on, which helps prevent a misunderstood requirement from turning into a large pile of wrong code.

Core idea 2: steering

If a spec is the plan for one feature, steering is the set of standing rules for the whole project. This is what people searching for "Kiro instructions" or "Kiro rules" are usually looking for.

According to the steering docs, steering files are Markdown files in two places:

• Workspace:.kiro/steering/ in the project root, for that project only.
• Global:~/.kiro/steering/ in your home directory, for every workspace. If the two conflict, the workspace file wins.

A steering file can set one of four inclusion modes in its front matter: always (the default), fileMatch (loads for files matching a pattern such as components/**/*.tsx), manual (loads when you reference it in chat with #file-name) and auto (loads when your request matches the file's description). Note that the docs say IDE 1.x loads only always files automatically, so check which version you run before relying on the other modes.

Kiro can also generate three foundation files for you, product.md, tech.md and structure.md, covering the product's purpose, the tech stack and the project layout. It reads AGENTS.md files too, which are always included.

Typical things to put in steering files:

• Coding conventions: "Function names are always snake_case."
• Architecture rules: "Database access always goes through the repository layer."
• Stack constraints: "Use httpx instead of requests for HTTP calls."
• Testing rules: "Every new function gets a matching pytest test."

With these in place you stop retyping the same instructions in every chat.

Python walkthrough: a CLI expense tracker

Here is the whole flow with a small Python project.

1. Create the project

Pick a Python template, or open an empty folder and type: "I want to build a console expense tracker in Python."

2. Set up a virtual environment

Kiro has an integrated terminal, just like VS Code.

python -m venv venv
venv\Scripts\activate     # Windows
source venv/bin/activate  # macOS/Linux

3. Describe the requirements in chat

Be specific: "Build a CLI program that takes expense entries, saves them to CSV, and prints monthly totals. Include input validation." Kiro first generates requirements.md and shows it to you.

4. Review requirements.md

Read the requirements and fix gaps, either by editing the file or by replying in chat, for example "Also allow refunds as negative amounts." Approve to move on.

5. Review design.md

The design document usually covers the file structure (for example main.py, expense.py, storage.py), the data model (date, amount, category, note) and the function and class outline. If you want the standard-library csv module instead of pandas, say so at this stage.

6. Approve tasks.md and generate code

Once the task list is approved, Kiro works through the tasks in order and writes the actual .py files. You can watch the files fill in, and task statuses update as it goes.

7. Run and debug

python main.py

If you hit an error, paste the message into the chat and ask Kiro to fix it. It finds the relevant files, explains the cause and proposes a change.

8. Add tests

If your steering file already says "always write tests," new features come with pytest files. Otherwise ask directly: "Write pytest tests for expense.py."

Common sticking points

• The approval steps feel slow. For a tiny script, you can ask for code directly and skip the spec, or use Quick Spec. Review the output more carefully in that case, since nothing was reviewed along the way.
• Credits run out fast. Large requests use more of your monthly credits than small ones. Splitting work into smaller tasks makes usage easier to track.
• Adding Kiro to an existing repo. Ask Kiro to analyze the project structure first, then write the existing conventions into a steering file. New features can each get their own spec, and over time .kiro/specs/ becomes a record of design decisions.
• Working in a team. Commit the .kiro/ folder, including specs and steering files. Teammates then share the same design documents and rules, and code review can ask whether the implementation matches design.md.

Connecting external tools with MCP

Kiro supports the Model Context Protocol (MCP), so the agent can use external tools such as databases, APIs or internal documentation search. Per the MCP configuration docs, you register servers in .kiro/settings/mcp.json (workspace) or ~/.kiro/settings/mcp.json (all workspaces). When both define the same server, the workspace file wins. In the command palette, search for "Kiro: Open workspace MCP config (JSON)" to open it.

Git and source control

The source control panel works the way VS Code's does: changed files appear in the sidebar, you review the diff per file, then stage, commit and push. When the agent edits many files at once, read the diff line by line. If tasks.md ran several tasks in a row, committing per task makes it easy to revert one change later.

Summary

Three things matter on day one. First, sign in (Google, GitHub or AWS Builder ID all work) and start from a template or an empty folder. Second, expect documents before code: requirements, then design, then tasks, and review each. Third, put repeated rules in .kiro/steering/ so you do not repeat them in chat. The flow is the same for Python or any other language, and a useful side effect is that even solo projects end up with design documents.