Kiro

You will like Kiro if agents start typing before they understand the task: it turns a prompt into requirements, a design and a task list first, then implements, and the specs stay in the repo as the documentation nobody was going to write. That is the daily trait, and on a shared codebase it is the one that keeps reviews short.

The catch is the meter: credits with no bring-your-own-key, so the bill goes where AWS says. Pick it if you ship on AWS and want structure more than speed. Pick Claude Code for raw agent quality and a bill you can route yourself.

The meter is the worst thing. Credits are consumed per prompt and per task, and the pricing page states that Sonnet 4.6 costs 1.3 times the credits of Auto, so the model picker is a price picker with no label. The headless doc documents --trust-all-tools, which auto-approves every tool call, the only approval gate the CLI has.

The consequence is that a CI job with that flag and a bad prompt spends credits and runs commands with nobody watching. Use --trust-tools with an explicit list instead, always. The spec flow is the one thing it does right: requirements, design and tasks before implementation.

Kiro publishes no benchmark, so there is nothing to audit on outcomes. The documented ordering, requirements, design and tasks before implementation, constrains the search space before tokens are spent on code, which is a principled way to reduce the variance of a nondeterministic model. Whether the model honors the specification during implementation is asserted, not demonstrated.

The consequence is that the spec is a contract only if something checks the code against it, and no such check is documented; the spec is an input, not a verifier. The reader may note that an agent whose main innovation is documentation was built by a cloud provider.

No runway question; the parent is Amazon Web Services and distribution comes through AWS accounts, which is the largest sales channel on this board. A company that meters by model multiplier expects to raise prices without churn, because the multiplier moves and the headline price does not.

The risk is deprioritization, Kiro folding into a broader AWS developer console the way earlier tools did, with the specs surviving as a feature somewhere else. No acquirer; the parent is the exit. Position: buy it if you are on AWS; keep your specs in plain Markdown so they outlive the product.

The demo is spec generation, and it maps onto how a team actually works, because the spec is the thing the tech lead would have asked for anyway. Procurement: Pro at $20 per user is $1,200 a month for sixty seats before overage, and the enterprise tier lists centralized billing, SSO, usage analytics and security controls.

CI fit is the headless CLI, which a pipeline can call with a restricted tool list. Onboarding is an IDE install and a steering file. Approved with conditions: disable automatic overage and set per-team credit budgets first, because a credit meter with an overage switch is a budget with a hole in it.

The GitHub repo under kirodotdev is an issue tracker, not source. No bring-your-own-key, no local models; every prompt is a credit deduction to a vendor I cannot swap. What I can bend: an mcp.json with mcpServers entries, steering files that set project rules, hooks that fire on events, and a headless CLI that takes --trust-tools=read,grep and emits stream-json I can parse.

That is a decent scripting surface on a box I cannot open. Grudging respect for the hooks, which are the part I would have designed the same way. Nothing to fork, nothing to run offline.