Kiro Requirements Analysis: How AWS Uses an SMT Solver to Kill AI Slop Before It Starts

The worst bugs in AI-generated code aren't in the code. They're in the spec that produced it. A vague requirement becomes a discretionary decision made silently by the model — and you only discover the inconsistency when two features collide in production. Kiro's Requirements Analysis engine, shipped May 12 2026, addresses this at the source. Before Kiro writes a single line of implementation, a three-stage neurosymbolic pipeline checks your specification for logical contradictions — using actual mathematics, not vibes.

The engineering bet is straightforward but the execution is unusual: combine a large language model's natural-language understanding with an SMT (Satisfiability Modulo Theories) solver's ability to mathematically prove inconsistency. The result is a requirements pass that catches conflicts a human reviewer and a standard LLM both miss.

Why vague specs break AI agents

AWS framed the problem precisely in the May 12 announcement: "Every vague prompt produces a vague spec or plan, and the AI agent implementing that spec produces code full of undisclosed decisions made on your behalf, without your awareness or agreement."

This is the core failure mode of spec-driven development done poorly. You write a spec because you want deterministic, auditable behavior. But if the spec contains ambiguous requirements, the agent quietly resolves them by picking an interpretation — and then defends that interpretation forever because it's in the context window as settled truth.

The scenario that trips teams most often isn't a missing requirement — it's two requirements that appear consistent in isolation but are logically incompatible when read together. Soft delete vs. hard delete is the canonical example. Page one of a spec might mandate that user records are permanently removed on account closure. Page ten might describe a deleted-user audit trail that depends on the records still existing. Neither page looks wrong. Together, they're a contradiction. A human reviewer skimming for obvious problems misses it. An LLM asked to summarize the spec misses it. An SMT solver doesn't.

The three-stage neurosymbolic pipeline

Kiro's Requirements Analysis runs as a pre-implementation pass. The pipeline has three stages, each delegating to the tool best suited to that problem.

Stage 1: LLM rewrite

Your natural-language requirements are ambiguous by nature. The first stage uses an LLM to rewrite each requirement into a testable, precise criterion. "Users should be able to delete their account" becomes something closer to "When a user submits an account deletion request, all PII records associated with that user ID must be removed from primary storage within 30 seconds and must not appear in subsequent queries." The LLM is good at this — it has the semantic breadth to understand what you probably meant.

Stage 2: Formal logic translation

The testable criteria are then translated into formal logical statements. This is where natural language gets pinned down into propositions that can be reasoned about symbolically. Each claim becomes a predicate. Constraints become implications. The spec is no longer prose — it's a set of formal assertions.

Stage 3: SMT solver verification

The logical assertions are submitted to a Satisfiability Modulo Theories solver. Unlike an LLM that predicts the next token, an SMT solver operates as a theorem prover: it searches exhaustively for an assignment of values that satisfies all constraints simultaneously. If no such assignment exists, the constraints are unsatisfiable — which means you have a logical contradiction in your spec.

The solver returns the specific conflicting assertions, not a vague warning. You see exactly which requirements are incompatible and which page of the spec each came from.

What an SMT solver actually does

SMT solvers are not new. They've been used in hardware verification, compiler correctness proofs, and security protocol analysis for decades. Z3 (Microsoft Research), CVC5, and Bitwuzla are common implementations. What's new is applying them to natural-language software requirements — which requires the LLM pre-processing stage to bridge the gap between English prose and formal logic.

The key property that makes SMT useful here: it's complete. It doesn't sample a few interpretations and report the most likely answer. It searches the entire space of possible value assignments. If a contradiction exists, the solver will find it. If the solver reports satisfiable, your requirements are logically consistent — not "probably consistent" but provably consistent under the formalization.

## Account Deletion

### Requirement A (§3.2)
When a user submits an account deletion request, all records associated
with that user_id MUST be permanently removed from primary storage.

### Requirement B (§7.8)
The audit trail for deleted accounts MUST be retained for 90 days
to support compliance reporting, including the deleted user's records.

---
# Kiro Requirements Analysis output:

⚠ CONTRADICTION DETECTED

§3.2 asserts: ∀ record r where r.user_id = deleted_id → r NOT IN storage
§7.8 asserts: ∃ record r where r.user_id = deleted_id ∧ r IN storage ∧ age(r) ≤ 90d

These constraints are unsatisfiable. Resolve before implementation:
  Option A: Retain deleted-user records in a separate compliance store (not primary storage).
  Option B: Exclude audit-trail records from the deletion scope in §3.2.

What Kiro catches (with examples)

The pipeline surfaces three classes of problems, each presented differently in the Kiro UI.

Logical contradictions

Two requirements that cannot both be true. Hard delete vs. soft delete is the textbook case, but the pattern recurs in access control (public API vs. authenticated-only endpoint on the same route), caching (always-fresh data vs. cached-for-performance response), and state machines (terminal states that have transitions). These get presented as two-option resolution choices so you can pick the intended behavior explicitly.

Ambiguities

Requirements that can be interpreted multiple ways, where those interpretations lead to different behavior. "Users can update their profile" says nothing about which fields, whether partial updates are allowed, what validation applies, or what happens on concurrent edits. Kiro samples multiple LLM interpretations and flags where they diverge — presenting each fork as a yes/no clarification question.

Gaps

Requirements that reference a behavior without defining it. An error case is described in one requirement but the expected response code, message, and side effects are never stated. Kiro flags these as open questions rather than contradictions — they're not inconsistent, they're just incomplete, and incomplete specs produce discretionary agent decisions.

How it fits the Kiro workflow

Kiro's spec-driven workflow has always had three sequential phases: requirements, design, tasks. Requirements Analysis slots in at the end of the requirements phase, before Kiro generates the design document. This is the right place: design decisions downstream of contradictory requirements will simply inherit and propagate the contradiction.

After Requirements Analysis clears, Kiro runs parallel task execution — the other major 0.12 feature. Independent tasks execute concurrently in isolated contexts. The dependency graph ensures that tasks writing the same files are never run in parallel, setup work runs first, and tests run after the code they validate.

The two features compose well. Clean requirements reduce task-level failures because the implementer isn't making undisclosed decisions. Parallel execution reduces wall-clock time from over an hour to around fifteen minutes for large specifications. The combined effect is faster and more correct — which is rarer than it sounds.

1. Write requirements (or use Quick Plan for auto-generation)
2. Requirements Analysis  ← neurosymbolic + SMT pass
   ├─ Contradictions surfaced as two-option resolutions
   ├─ Ambiguities surfaced as clarifying questions
   └─ Gaps flagged as open items
3. Review and resolve all flagged items
4. Kiro generates design document
5. Kiro generates task list
6. Parallel task execution  ← dependency graph, isolated contexts
   └─ 4x faster than sequential for large specs

The pattern in Claude Code and other agents

Kiro is the only AI IDE with this built in natively, but the underlying pattern — validate requirements for logical consistency before generating implementation — is something any agent can run. The three-stage approach doesn't require an embedded SMT solver; a disciplined LLM pass that explicitly looks for contradictions, ambiguities, and gaps catches the majority of issues.

On skills-hub.ai, the requirements-verification skill runs this pattern for Claude Code and other agents. Install it and point it at any spec file. It won't have the full SMT-backed mathematical proof that Kiro provides, but it will surface the classes of issues that cause the most downstream rework.

# install the requirements verification skill for Claude Code
npx @skills-hub-ai/cli install requirements-verification

# run it against your spec
/requirements-verification ./SPEC.md

The former Microsoft executive Shawn Bice joined AWS as VP of AI Services earlier this year specifically to lead the Automated Reasoning Group responsible for this capability. It's a significant organizational bet: that the path to reliable AI-generated code runs through formal verification of the inputs, not just reinforcement learning on the outputs.

The broader implication for the industry: spec-driven development is becoming the dominant pattern for agentic coding in 2026 not because specs are fun to write, but because they're the only reliable way to constrain what agents do. Kiro's Requirements Analysis is the first production tool that treats the spec itself as a first-class artifact worth formal verification — not just a prompt to feed forward.

Read more: the original Kiro deep dive, the parallel tasks and Quick Plan explainer, or browse all Kiro skills on skills-hub.ai.