What is the difference between RACE Programming and Kiro?

Kiro is an agentic development environment built and operated by AWS, available as an IDE, a CLI and on the web. It supports spec-driven development: a spec has a requirements file written in EARS notation, a design file and a tasks file, plus steering files for persistent project knowledge and hooks that run on agent events. RACE Programming is a prescriptive Agentic SDLC framework for the delivery team: the Team Principal, the Pit Wall (Forward Deployed Engineer and AI Product), the Pit Crew, the Executable User Story, Kanban flow with a client-set release cadence and the share of the backlog the delivery machinery clears. Kiro is a tool an engineer works in; RACE is how the team around that engineer works.

Can a RACE team use Kiro?

Yes. RACE Programming does not prescribe a coding tool. The Forward Deployed Engineer chooses and evolves the engagement's delivery machinery, and Kiro specs, steering and hooks can be part of it. Kiro also writes requirements in EARS, the notation the Executable User Story uses for non-functional requirements.

Is a Kiro spec the same as an Executable User Story?

They overlap. A Kiro spec holds requirements with acceptance criteria, a technical design and a task plan. The Executable User Story also holds those things in its own form (NFR in EARS, architecture in ADR), and adds a working prototype, Gherkin acceptance criteria owned by AI Product as the test source of truth, test data and a delivery cost in dollars, accepted with the Team Principal.

When should I choose Kiro and when RACE Programming?

They answer different questions. Choose Kiro, or another agentic coding tool, for how an engineer works with the agent day to day. Choose RACE Programming for how the team is structured, how it works with the client, how it verifies the agent's output, and how often it ships. Most RACE teams will use some tool of this kind.

Audio brief · 2 min

By Pavel Khodalev, CTO at First Line Software · October 21, 2026

Compare

RACE Programming vs Kiro

Kiro is an agentic development environment from AWS that turns prompts into specs and specs into tasks. RACE Programming is a framework for the team: roles, the Executable User Story, the release cadence and the client contract. Kiro can be one of the tools a RACE team works in.

What Kiro is

An agentic development environment with specs

Kiro is built and operated by AWS. It runs as an IDE, a CLI and on the web, and its site describes it as moving beyond AI coding to agentic engineering: turning prompts into executable specs, checking requirements for contradictions and gaps, and checking behavior with property-based tests.

In Kiro's specs, every feature gets three files: requirements.md with user stories and acceptance criteria, design.md with the technical architecture, and tasks.md with a trackable implementation plan. The feature specs page says requirements use EARS (Easy Approach to Requirements Syntax) notation, and offers requirements-first and design-first workflows. Steering gives Kiro persistent knowledge about the project through markdown files, and hooks run shell commands or agent prompts when specific events happen in a session.

Sources checked October 21, 2026: kiro.dev and the Kiro documentation on specs, feature specs, steering and hooks.

At a glance

A tool, and the team that uses it

Dimension	RACE Programming	Kiro
What it is	Prescriptive Agentic SDLC framework	Agentic development environment (IDE, CLI, web) built and operated by AWS
Specification	Executable User Story: seven components, accepted with the Team Principal	Spec: requirements in EARS, design, tasks
Persistent context	Everything as Code; the Pit Wall holds the domain glossary, decisions and constraints across stories and releases	Steering files in the project
Roles	Team Principal, Pit Wall, Pit Crew, with the AI agent in both tiers	Not prescribed: the developer and the agent
Cadence	Continuous Kanban flow; each Executable User Story production-ready in 2-3 days at the floor; Pit Stops on the client's release cadence	Per spec and task, as the developer runs them

What RACE does differently

It designs the team, not the editor

Roles and topology. The Team Principal owns product direction and acceptance. The Pit Wall, a Forward Deployed Engineer and an AI Product, turns client intent into the specification and a working prototype. The Pit Crew, a Quality Engineer and two Software Engineers, executes. A TPM coordinates across teams.
Executable User Story. Adds what a delivery team needs beyond a feature spec: a working prototype, Gherkin acceptance owned by AI Product, test data and a delivery cost in dollars.
Separation of writing and checking. The Quality Engineer automates the acceptance tests and sets guardrails the agents cannot modify.
Flow and release cadence. Each Executable User Story is production-ready in two to three days at the floor; a Pit Stop releases it on the client's release cadence.
Machinery share of the backlog. The Forward Deployed Engineer is measured by how much of the backlog the machinery clears. RACE scales by raising that share, not by adding people.

Where they combine

Kiro as the workbench inside RACE

A Kiro spec lines up with parts of the Executable User Story: requirements with the user story and NFR (both use EARS), design with the ADR, tasks with the Pit Crew's work. Steering files are a natural home for the engagement's standing context, versioned in the repository as Everything as Code asks. Hooks are one way to wire guardrails and checks into the machinery the Forward Deployed Engineer owns. AWS's own AI-DLC workflows also run in Kiro; see RACE vs AWS AI-DLC.

When to choose which

Not either-or

Choose Kiro, or another agentic coding tool, for how engineers work with the agent day to day.
Choose RACE Programming for how the team is structured, works with the client, verifies agent output and ships.
Use both when a RACE team picks Kiro as part of its delivery machinery.

Working in Kiro already? The framework page shows the team and artifacts that sit around the tool.

Read the framework → · RACE vs Spec Kit → · More comparisons →

FAQ

Frequently asked questions

What is the difference between RACE Programming and Kiro?: Kiro is an agentic development environment built and operated by AWS, available as an IDE, a CLI and on the web. It supports spec-driven development: a spec has a requirements file written in EARS notation, a design file and a tasks file, plus steering files for persistent project knowledge and hooks that run on agent events. RACE Programming is a prescriptive Agentic SDLC framework for the delivery team: the Team Principal, the Pit Wall (Forward Deployed Engineer and AI Product), the Pit Crew, the Executable User Story, Kanban flow with a client-set release cadence and the share of the backlog the delivery machinery clears. Kiro is a tool an engineer works in; RACE is how the team around that engineer works.
Can a RACE team use Kiro?: Yes. RACE Programming does not prescribe a coding tool. The Forward Deployed Engineer chooses and evolves the engagement's delivery machinery, and Kiro specs, steering and hooks can be part of it. Kiro also writes requirements in EARS, the notation the Executable User Story uses for non-functional requirements.
Is a Kiro spec the same as an Executable User Story?: They overlap. A Kiro spec holds requirements with acceptance criteria, a technical design and a task plan. The Executable User Story also holds those things in its own form (NFR in EARS, architecture in ADR), and adds a working prototype, Gherkin acceptance criteria owned by AI Product as the test source of truth, test data and a delivery cost in dollars, accepted with the Team Principal.
When should I choose Kiro and when RACE Programming?: They answer different questions. Choose Kiro, or another agentic coding tool, for how an engineer works with the agent day to day. Choose RACE Programming for how the team is structured, how it works with the client, how it verifies the agent's output, and how often it ships. Most RACE teams will use some tool of this kind.

Developed in the open

Help develop this

RACE Programming is a working framework, not a final answer. If this was useful, I would like your feedback: what you think is right, what you think is wrong, and what you would change. Disagree with any part, send a better version, or use it in your own work and tell me how it went. It improves faster when people develop it together.

Write to me: paul@raceprogramming.com