AWS Kiro: Why Amazon’s Agentic IDE Goes Beyond Vibe Coding

AWS Kiro is a family of products consisting of an agentic AI IDE, a CLI tool, and a web interface for autonomous agents (AWS frontier agents). Kiro helps developers move from idea to production by transforming natural language requirements into structured specifications, implementation plans, and code.

Its main differentiator is spec-driven development. Rather than jumping straight from prompt to code, Kiro starts by formalising requirements. It then produces a breakdown of design tasks, and only then moves to implementation.

AWS Kiro: What it is

An agentic IDE is an environment where AI does much more than just autocomplete or answer code questions. The AI can plan work, act on tasks, use tools, and maintain context across steps.

Kiro positions itself as an agentic AI development environment going “from prototype to production.” It combines multimodal chat, specs, agent hooks, MCP support, and autonomous task execution. AWS indicates that Kiro aims to offer teams mature engineering practices while using AI agents to accelerate delivery.

AWS Kiro: Key Features

The core Kiro workflow starts from a natural language prompt, which it converts into requirements and acceptance criteria using EARS (Easy Approach to Requirements Syntax) notation. It then analyses the code to propose an architecture, system design, and technical stack choices, generating distinct implementation tasks with their dependencies and optional tests.

Other notable features include:

• Agent hooks that can be triggered by events such as file saves, to automate documentation, testing, and performance work.
• Native MCP support to connect documentation, databases, APIs, and other tools.
• Steering files to define project-specific or global rules on agent behavior. Compatible with Claude’s format.
• VS Code compatibility, including themes and Open VSX plugins.
• An autopilot mode to let agents handle larger tasks with less step-by-step guidance.
• Real-time visibility of credit consumption, image-based context input, commit message generation, and intelligent error diagnostics.

What makes AWS Kiro different

The main difference between Kiro and many other coding agents is that it is built around spec-driven development, rather than simple prompt-driven coding. In this approach, the AI first creates structured artifacts:

• The requirements. What a product owner would give you; we aren’t talking technical here, just the outcome—what do we want?
• Design documents. This is where the architect defines how the feature will be built, technical requirements, diagrams, technologies used…
• Task plan (project steps). This helps keep the implementation aligned with the initial intent and reduces “vibe coding” drift.

This structure is important because the specs remain synchronised with the evolving codebase, limiting discrepancies between documentation and implementation. In practice, Kiro seeks to bridge the usual gap between “what was requested” and “what was actually built,” while allowing for iterative review before applying code changes.

In this process, we will ask the AI to perform a task; it will make a proposal for implementation and slightly “hallucinate” to allow us to include context we might have omitted. It is then up to us to challenge this proposal so that it matches what we want and how we see the feature.

Benefits for developers

For developers, Kiro can reduce prompt engineering load and speed up feature work by turning vague ideas into actionable plans. It is also useful for more complex tasks: bug fixing, code understanding, testing, and architecture decisions, especially in large codebases.

It is particularly suitable when you want:

• Faster end-to-end feature delivery.
• Better habits regarding test coverage and documentation.
• A more structured implementation on complex systems.
• Fewer context switches between the editor, documentation, and task tracking.

Benefits for managers

For project managers, Kiro’s spec-first flow produces clearer requirements, acceptance criteria, and task breakdowns, which facilitates communication and scope tracking. Because the tool generates explicit artifacts before coding starts, it can improve alignment between product, design, and engineering teams.

This is particularly useful when teams need predictable delivery, clear milestones, and fewer surprises during implementation. It also makes it easier to verify that the work still matches the original intent as the codebase evolves.

Benefits for IT Directors

For IT Directors, the appeal lies in governance, consistency, and scalability. AWS emphasises that Kiro combines AI acceleration with enterprise-grade structure, security, and confidentiality, and support for standardised workflows across teams.

This can help organisations bridge the gap between prototype velocity and production discipline, while promoting reusable standards for specs, coding rules, and automation. AWS also presents Kiro as a way to go faster without losing control—crucial for large organisations looking to reconcile speed, compliance, and maintainability.

In summary

Kiro defines itself primarily as an AI coding environment that seeks to make AI-assisted development more rigorous than chat-oriented coding tools. If you want a quick prototype, it helps.

If you are aiming for a production workflow with requirements, design, tasks, testing, and continuous alignment, that is where Kiro’s spec-driven approach truly makes sense.

AWS Kiro Use Case: Sports Performance Analysis

At the AWS Summit, François Dexemple chose a concrete field to experiment with agent orchestration: analysing his own running data.

The goal was not to solve a specific business problem, but to test in real-world conditions what agentic workflows allow: how to assemble specialised agents, make them cooperate, and obtain a consistent and reliable result.

Kiro and Agent Orchestration

Why multiple agents instead of just one?

The natural temptation is to entrust everything to a single agent. As François Dexemple explains, this is a bad idea as complexity increases. The larger an agent’s context becomes (exchange history, transmitted data, intermediate results), the more the quality of its responses degrades.

Comparative studies on large models (Anthropic, Google, Amazon, OpenAI) confirm this phenomenon. Beyond a certain threshold, responses become less relevant or even hallucinated. This is why Kiro includes an auto-compact feature. It automatically compresses context to avoid saturating the window. A takeaway for developers: if your results degrade during a session, resetting the context is often enough to regain quality.

Multiplying agents also allows for mixing models according to needs. For example, using Claude Opus for the orchestrator, which must produce a high-quality summary, and a lighter model for an agent tasked with a simple job like weather retrieval.

Which orchestration pattern to choose?

Several multi-agent architectures are possible:

• Independent MAS: several agents work in parallel, and their results are aggregated. Problem: an error in one agent is amplified in the final synthesis.
• Decentralised MAS: agents communicate with each other and vote. Risky, as some models may be prone to “lying” to hold their own in an inter-agent debate.
• Centralised MAS (the one chosen for this use case): a single orchestrator receives all tasks, delegates them to sub-agents, retrieves their results, and synthesises them. The agents do not know each other. The orchestrator can detect inconsistencies and reduce hallucinations.
• Hybrid MAS: agents can talk to each other directly, in addition to reporting back to the orchestrator.

The centralised pattern is not universal: for a simple task, a single agent is more than enough. But as soon as use cases become complex, centralisation offers more reliability and control.

Architecture and Technical Choices

The four agents

The system developed by François Dexemple consists of an orchestrator (Running Analyst) that drives three specialised sub-agents:

• The Coach: retrieves Strava activity data, aggregates raw GPS points (speed, distance, cadence second by second) into an actionable summary, and evaluates the overall performance of the session.
• The Meteorologist: retrieves weather conditions for the date and location of each outing. A separate agent is launched in parallel for each outing analysed to save time.
• The Librarian: queries a knowledge base consisting of scientific studies and books on running to contextualise the data with expert recommendations.

The Strava problem and its solution

Strava does not offer a native MCP server. François ruled out existing third-party MCPs for security reasons (personal credentials). The official API posed two other obstacles: restrictive rate limiting during the testing phases and the inability to access other users’ public data.

The chosen solution: export all personal Strava data to an Amazon Aurora database, exposed via an API Gateway and a Python Lambda that synchronises data every hour. This custom API is then translated into an MCP server using the Amazon Bedrock Agent Core Gateway service.

An additional obstacle: Strava uses the OAuth authorisation code + refresh token flow, which is not yet natively supported by Agent Core Gateway. Another reason to build his own access layer.

MCP and Amazon Bedrock Agent Core Gateway

This AWS service acts as a gateway that automatically transforms any REST API into an MCP server without specific development. It integrates with several identity providers (Cognito, Entra ID, etc.) via a dedicated sub-service, Agent Core Identity. It can connect multiple sources simultaneously—APIs, Lambdas—to form a centralised MCP hub.

Concrete Usage of Kiro CLI

Kiro is often associated with its IDE, but it comes in three products:

• The IDE
• The CLI (used here)
• Kiro Autonomous (closed preview), which interacts directly with GitHub issues.

Agent Configuration

Everything happens in a .kiro folder, placed either in the project or at the user root for global agents. It contains:

• An agents/ folder with one JSON file per agent (name, description, prompt, allowed tools, associated MCP servers)
• A separate prompts folder (prompts quickly become too long to remain readable inside JSON)
• Skills to provide initial context to agents
• A knowledge/ folder automatically indexed by Kiro

Configuring an agent is simple. You declare the tools it has access to, and you can precisely restrict which ones it is authorised to use, even within the same MCP server.

Creating a knowledge base is done via the command knowledge add, pointing to a folder of files (markdowns, PDFs, books). Two indexing modes: best (slower, better quality) and fast. Several gigabytes of documentation can be indexed in about ten minutes.

To switch from one agent to another, the agent swap command lists available agents (AWS built-in and custom agents).

Experimental features (activatable via /experiment)

• Thinking: displays the agent’s internal reasoning, useful for understanding why a prompt produces an unexpected result and refining it.
• Tangent mode: Kiro’s “incognito mode.”
• Todo list: Kiro reads a task list and executes them step by step.
• Checkpoints: save points that allow you to go back if the agent goes in the wrong direction.
• Delegates / sub-agents: allows an agent to spawn other agents. This feature is moving out of experimental to be natively integrated. The current limit is about six sub-agents in parallel (subject to change).

The key for an agent to be able to create sub-agents: granting it the use_sub_agent tool in its configuration.

Walkthrough of the Kiro Strava Demo

François queries the Running Analyst orchestrator with the request “analyse my last run.” The orchestrator activates the thinking tool, identifies that it needs to delegate, and spawns the Coach. The coach calls the custom Strava API via MCP, retrieves the activity list, isolates the most recent one, extracts details, summarises them into a pace analysis, then closes its task and returns the result.

The orchestrator, now in possession of the date and location of the run, simultaneously launches the Meteorologist and the Librarian. The meteorologist queries the Open-Meteo API and responds quickly. The librarian searches the knowledge base to contextualise the performance with scientific recommendations. This step takes a bit more time. Once both results are received, the orchestrator aggregates the three contributions (coach, weather, library) and produces a final enriched analysis.