Kiro Alternative: A Spec Is Not Proof of Done

Kiro puts the written specification at the centre of agent coding. Every spec in Kiro, the agentic development environment built and run by AWS, generates three files: a requirements document with user stories and acceptance criteria, a design document, and a task list the agent works through. For an engineering lead who has watched coding agents drift away from what was asked, that structure is a real improvement. The agent now has something precise to build against.

A spec, though, answers only one of the two questions an engineering lead has to sign off. It says what done should mean. It does not, on its own, record whether the work that came back meets that meaning, who decided it did, and against which version of the spec. Kiro's own correctness documentation is candid about the gap: its property-based testing feature, it says, provides "evidence of correctness, not a proof." This guide is for the engineering lead or VP Engineering who already likes spec-driven development and wants to know what has to sit between a finished Kiro task and a done status the team can stand behind.

The scope is deliberately narrow. What a definition of done should contain belongs to our proof of done guide. Acceptance criteria that drift inside a shared document are covered in our Notion AI agents comparison, how much to trust screenshots, videos and logs is in our guide to coding agent artefacts as evidence, and the argument that a merged pull request is not the same as done sits in our GitHub Copilot coding agent comparison. This post holds one altitude: the distance between a written acceptance criterion and recorded evidence that it was met.

This guide is shipped by the team behind Cognibl, from DILR.AI, the work tracker where a task cannot reach done until proof of work is attached, for people and agents alike. Or see DATS, our five-stage method for placing AI inside an operating business.

What is Kiro, and what do its specs produce?

Kiro is an agentic development environment from a team within AWS, and its specs turn an idea into three files. The requirements file holds user stories and acceptance criteria written in a structured notation, the design file holds architecture and sequence diagrams, and the tasks file holds a plan of discrete, trackable tasks. Kiro moves every spec through three phases, requirements, design and tasks, before the agent builds.

The Kiro specs documentation, updated on 12 November 2026, describes specs as structured artifacts that formalise the development process for features and bug fixes. A bug fix gets a bugfix file with current, expected and unchanged behaviour in place of the requirements file. Feature specs come in two variants, Requirements-First and Design-First, and Kiro's best practices page says a Feature Spec's workflow cannot be switched once it is started; you create a new spec instead.

The requirements notation matters for everything that follows. Kiro writes requirements in EARS, the Easy Approach to Requirements Syntax, in the shape WHEN a condition occurs THE SYSTEM SHALL behave in a stated way. The Feature Specs page lists testability and traceability among the benefits, and that is a fair claim: a requirement written this way can be turned into a test far more easily than a paragraph of prose.

Kiro also runs across several surfaces. Its homepage says Kiro agents plan, build, review and verify engineering work on your machine or in the cloud, from Crew, Web, Mobile, the IDE and the CLI. Not every spec feature reaches every surface, and that detail becomes important when the question is what evidence a finished task carries.

How does Kiro check code against its own spec?

One way Kiro checks code against a spec is property-based testing, which it calls spec correctness. Kiro extracts properties from the EARS requirements, generates hundreds or thousands of random inputs when a developer chooses to run them, and reports any input that breaks a property. Kiro's documentation states that these tests are optional by default and that the feature is available in the IDE only, not the CLI, Web or Mobile surfaces.

The correctness documentation explains the method well. Instead of a test that adds car number five to a favourites list and checks it appears, a property states that for any user and any car, when the user adds the car to favourites, the system shall display it. The tool then generates many combinations, shrinks any failing input to the smallest case that still fails, and surfaces it for review. Kiro can then update the implementation or offer options to fix the spec, the implementation or the test.

Kiro argues this beats example tests, because whoever writes those, human or AI, is limited by their own biases, and our artefacts guide makes the same point about tests that encode acceptance criteria. Kiro is also open about its limits. In the same page it says the method "is not formal verification", and it lists further limits, including these two: a property that is too weak, or that states the wrong invariant, will pass while the real behaviour is still wrong, and not every requirement maps cleanly to a property.

The capability table on the specs page shows how unevenly that evidence is spread. Feature specs, bugfix specs, Quick Spec and parallel task execution run on all four surfaces, while Analyze Requirements runs on two and property-based testing on one.

For an engineering lead, the practical reading is simple. If a task was built from Kiro Web, Mobile or the CLI, the spec correctness step that ties tests back to requirements was not available on that surface, and that task's evidence has to come from elsewhere, such as the repository's own tests or hooks.

What does a completed task in Kiro actually record?

A completed task in Kiro records that the agent finished a step in its plan. Kiro's specs page says its task interface updates tasks as in progress or completed in real time as the agent implements them. That status describes the agent's progress through tasks.md. It is not, on its own, a recorded decision by a named person that the work meets the acceptance criteria in requirements.md.

The distinction is easy to miss because Kiro does a lot around the task. When a developer runs all tasks, Kiro builds a dependency graph and runs independent tasks concurrently in waves. Quick Spec generates requirements, design and tasks in one pass without approval gates between phases, which suits well-understood work. Markdown Review lets a person comment on exact passages of the requirements or design and send those comments back to the agent. Each of these improves how the work is planned and built.

For cloud sessions at least, acceptance happens somewhere else. The Kiro changelog entry for Kiro Mobile, dated 12 November 2026, says each cloud session shows its pull request status and puts it plainly: "You review and merge in your Git provider." So in that workflow the decision that a change is good enough sits in GitHub or a similar host, as a merge, while the spec sits in the repository and the task status sits in Kiro. Our Devin comparison found a similar split in a different product.

The spec also moves. Kiro's best practices page describes iterating on specs: update requirements.md, ask Kiro to revise design.md, then choose Sync Files on tasks.md to create new tasks that map to the new requirements. That is the right behaviour for a living plan. It also means that six months later, a reviewer asking which acceptance criteria a merged change was built against has to reconstruct that from Git history rather than read it from the task.

What does Kiro's CloudTrail logging cover, and what does it leave out?

Kiro's CloudTrail logging covers calls to Kiro's own service tools through AWS CloudTrail. A Kiro changelog entry dated 12 November 2026 says security and audit teams can see who made a request, which tool was called, when it ran and whether it completed. The same entry says events redact tool arguments and omit results, and that logging covers Kiro service tools only, not MCP servers a team adds to Kiro.

That is a useful control and it answers a real question: who did what, and when. It does not answer whether the work met its spec, because the events omit results and acceptance sits in the pull request. Kiro's enterprise documentation also lists monitoring pages that this guide did not review. The logging is available for Kiro profiles in two regions, US East (N. Virginia) and Europe (Frankfurt). For a UK team, where those records sit is part of the UK GDPR transfer and retention picture, which is worth settling with whoever owns data protection before the trail becomes the evidence base for anything.

Kiro adds further controls around the agent. Its hooks documentation describes hooks that run shell commands or agent prompts when the agent saves a file, invokes a tool or completes a task, including a PreToolUse hook that blocks tool execution unless preconditions are met, and a pattern for validating code before the agent finalises changes. Command hooks time out after 60 seconds by default. A team can use a task-completion hook to run its test suite, which is a strong habit, but the hooks page does not describe its result being stored as an acceptance record.

A changelog entry dated 10 November 2026 also introduced an Enterprise Management preview: one policy written in the AWS console that Kiro applies across the IDE, the CLI, Kiro Web and Kiro Crew LTS, available at first to newly created profiles in US East. Policy controls what the agent may do. Proof of done is about what the agent did and whether it was enough, and the two sit at different points in the lifecycle. Our task verification guide separates identity and access controls from verification in more depth.

Where does a spec stop and proof of done begin?

A spec stops at the statement of what done should mean, and proof of done begins when evidence is attached and someone decides against it. A spec is an intent: requirements, design and tasks. Proof of done is a record: the spec version the work was built against, the evidence that each criterion was met, and the decision that accepted it. Kiro covers much of the first half; the second needs a record that outlives the session.

It helps to see the full chain as four steps, each owned by something different. The spec is written, usually by a person with the agent's help. The tests run, ideally including property tests drawn from the requirements. The proof is attached to the task: the test output, a coverage report where tests are part of the claim, and anything else the definition of done asks for. Then done is decided, by a rule that refuses the status without the proof, and by a person where the risk calls for one.

The handover between steps two and three is where the thread is easiest to lose. In Kiro's IDE, hovering over a property shows its connection to the original requirement and linked task, which is a genuine strength. What can still go unrecorded is the step after: tests pass inside a session, the agent marks its task completed, a reviewer merges, and nothing joins the spec version, the test output and the acceptance decision in one place a later reader will find. The same diagnostic logic underpins our AI execution office, our embedded, long-term delivery service, where hand-offs like this one are part of the work.

Two failure modes follow from leaving step three implicit. The first is the weak property Kiro itself warns about: a test that passes while the behaviour is wrong, with nobody recording which criterion it was meant to cover. The second is spec drift, where the requirements file is edited after the work merged and the evidence no longer lines up with what the spec now says. Both are cheap to prevent at the moment of done and expensive to unpick at audit time.

How does Cognibl, from DILR.AI, handle the same work?

Cognibl, from DILR.AI, puts the evidence rule in the status change itself. A task in Cognibl cannot reach done until proof of work is attached, and without it the move is refused, for people and agents alike. The proof is a CSV describing the run, the documents it references and, for code, a coverage report. Cognibl keeps a reference and a content hash of each file, and editing proof creates the next version.

On the Cognibl product page, agents run on Claude Code or Codex, each in its own microVM, take a task from the board, open a pull request and attach proof of work, and only a person can merge. A run that ends without proof stops at Blocked with the comment "Run ended without proof." so somebody looks at it. For code, the Harness workflow fits a spec-driven team: build, test and prove until done, chosen when the work is code and the definition of done is a test suite. Our microVM isolation guide covers the run environment.

Proof is checked in three layers, cheapest first. Deterministic checkers decide what a machine can decide outright, such as the template format, the required files and the thresholds. An AI verification flow then reads the proof against the definition of done line by line and writes the summary a reviewer starts from. Finally a person reviews a share of the passes, and the agent's score sets how large that share is. Cognibl's homepage adds that the AI flows summarise and flag problems but never decide.

The record around the task is designed to survive. Every gateway call, allowed, refused or failed, is written to an append-only, hash-chained trace that is redacted at capture, and tools are read-only by default. Skills and agent instructions live as versioned SKILL.md files where every edit is a new version, which our skills library governance guide explains. That is the part this guide did not find in Kiro's documentation: a task that carries its own evidence and refuses to close without it.

There are concessions, and they are real. The Cognibl pages describe no spec-authoring workflow like Kiro's, no generation of property-based tests from requirements and no EARS notation. Its agents run Claude Code or Codex, not the Kiro agent. A team that wants the spec authoring experience should keep Kiro for that and judge Cognibl on the record it keeps at the end. Our what is Cognibl overview sets out the product in full, and the AI developer productivity page shows where it fits in a wider engineering programme.

Kiro and Cognibl side by side

The table below compares the two on the points this guide covers. Kiro facts come from Kiro's specs, correctness, hooks and best practices pages and its changelog, fetched in November 2026. Cognibl facts come from the live Cognibl pages on dilr.ai and cognibl.com.

Neither column is a verdict. A team that already writes careful specs in Kiro and wants the record kept beside the task is the team for which the right-hand column matters most.

Can Kiro and Cognibl be used together?

Kiro and Cognibl can be used side by side as a working process, though neither product's pages describe a direct integration between them. A team can author and refine specs in Kiro, commit requirements.md to the repository, and create the Cognibl task with a definition of done that references the requirements file and the commit it was written at. The proof then cites which requirements the tests covered.

In practice that means three habits. First, pin the spec: the Cognibl task names the requirements file and the commit, so later edits to the spec do not quietly change what the work was accepted against. Second, carry the test evidence across: where Kiro's property tests ran, their output and the requirements they map to belong in the proof, alongside the repository's own tests and a coverage report. Third, keep the acceptance decision on the board, not only in the merge, so that the done status and the merged change point at the same evidence.

Kiro's best practices page notes that requirements can be imported from systems such as JIRA or Confluence through an MCP server or a manual copy. In that setup the planning artefact and the record of acceptance live in different tools, much as tickets in Jira or Linear sit apart from the code host, and the work is in joining them deliberately. Our LangGraph comparison shows the same join for a framework rather than an IDE, and our DATS consulting methodology is where we look at the operating side of that join.

The join is also where an evidence trail gets built. The reason an engineering team might want a pinned spec and attached proof is ordinary rather than regulatory: a change that broke something can be traced back to what was asked, what was tested and who accepted it, without relying on anyone's memory of the session. Our AI placement diagnostic looks at where AI belongs in a workflow, including what record that work should leave behind.

What is the best Kiro alternative in 2026?

The best Kiro alternative in 2026 depends on what a team wants Kiro to do. For spec-driven authoring with property-based tests, Kiro remains strong and may not need replacing. For a done status that refuses to close without attached evidence, Cognibl fits better. Teams should judge any candidate on four criteria: spec authoring, test evidence, a stored acceptance decision and an audit trail that holds results.

Applied honestly, those criteria split the field rather than crown one tool. On spec authoring, Kiro's three-phase workflow, EARS requirements and Analyze Requirements check are its strengths, and Cognibl does not compete there. On test evidence, Kiro's property tests are a genuine advantage where the IDE is in use; Cognibl's contribution is to require the evidence before done rather than to generate it. On a stored acceptance decision and an audit trail that holds outcomes, Cognibl is built for exactly that, while Kiro's cloud session notes leave acceptance to the Git provider and its CloudTrail events omit results from its CloudTrail events.

Other coding agents sit on the same map and each has its own comparison on this blog: our Cursor cloud agents comparison, the Devin and Copilot comparisons linked above, and our Google Jules alternative guide, which looks at plan approval as a control point. For teams whose bottleneck is review capacity rather than evidence, our engineering review queue guide is the better starting point.

A sensible test for any shortlist is to take one feature that is already specified, run it through each candidate, and then ask a colleague who was not involved to answer three questions from the records alone: which acceptance criteria did this change claim to meet, what evidence shows it met them, and who accepted it. The tool whose records answer all three without a conversation is the one that suits a team that has to defend its done.

Frequently asked questions

Is Kiro's property-based testing proof that the code is correct?

No. Kiro's own correctness documentation says property-based testing provides evidence of correctness, not a proof, and that it is not formal verification. Passing property tests raise confidence across many generated inputs, but a property that is too weak or states the wrong invariant will pass while behaviour is still wrong, so Kiro's test output is evidence to attach, not a sign-off.

Does Kiro store who accepted a finished task?

The Kiro pages reviewed for this guide do not describe a stored acceptance decision on the task. Kiro updates tasks as in progress or completed while the agent works, and its November 2026 changelog says, for cloud sessions, that you review and merge in your Git provider. Acceptance therefore sits in the pull request history, which a team has to join to the spec and the tests itself.

Building with specs and want a done you can defend? Read our proof of done guide, open Cognibl on cognibl.com, see our DATS methodology, or browse more AI strategy guides. If sign-off is the sticking point, talk to our engineers, read our approach to placing AI, or learn more about Dilr.ai.

Written by the Dilr.ai engineering team, practitioners who ship enterprise AI in production. Follow us on LinkedIn for shipping notes, or subscribe via the RSS feed.