Check Requirements for Contradictions and Gaps Before Writing Code

AI coding assistance has dramatically shortened the path from requirements to an implementation draft. At the same time, ambiguities and contradictions in those requirements now become code faster than before.

When a requirement says “delete,” does it mean removing the record permanently, or hiding it from the user while retaining it for audit? When the normal path is documented, what should happen if the target does not exist or the user cancels the confirmation dialog? People can interpret these points differently, and an AI system may fill the gaps with plausible assumptions and continue implementing. Once the code runs, the mismatch looks like an implementation bug even though it began in the requirements.

Kiro addresses this problem in Requirements analysis: catching requirement bugs before they become code. The article treats requirement granularity, ambiguity, contradiction, and completeness as separate problems and analyzes them before moving to design, tasks, and code. I found one idea especially useful: rather than presenting a detection result only as formal logic, turn it into a choice such as “which behavior did you intend?”

I did not reproduce Kiro’s internal implementation or formalization process. Instead, I built a small verification without external APIs to see how useful this approach is in an ordinary AIDD requirements review.

Specification Problems Are Hard to Recover Through Code Review Alone

Code review can examine exception handling, types, tests, and consistency with existing implementation. After an implementer has selected one interpretation and encoded it, however, it becomes harder to notice that the requirement allowed another reading.

Suppose a deletion feature has these acceptance criteria:

When a user confirms deletion, permanently delete the property record.
Retain deleted property records for audit purposes.
Reject deletion requests from users who do not own the property.

Each sentence looks reasonable in isolation. The first two, however, require the same normal path both to remove the record permanently and to retain it. If the implementer chooses either behavior, the implementation violates the other criterion.

The following paths also have no defined result:

• A deletion request for a property with an active contract
• A deletion request for a property that does not exist
• A user cancels the confirmation dialog

If these requirements are sent to AI with the instruction “implement the deletion feature,” the chosen behavior will depend on the model, the prompt, and context from the existing code. Working code does not prove that the implementation follows the intended requirements.

Applying Acceptance Criteria to Each State

The verification script takes fixed acceptance criteria and five states as inputs, then compares the outcomes of every rule that applies at the same time. It evaluates both the initial draft and a revised version. It does not call an external LLM API, Kiro, or an SMT solver. This experiment therefore does not measure the accuracy of automatically formalizing natural language. It checks the value of translating requirements into state-specific behavior before reviewing them.

npm run verify is not an official CLI. It is a verification script prepared for this article. For fixed inputs covering deletion confirmation, permissions, target existence, and active contracts, the script compares the results required by the acceptance criteria. It fails when one state produces conflicting results or no result at all.

npm run verify

In the initial draft, a normal deletion produced both hard-delete and retain-for-audit. Three paths had no result: an active contract, a nonexistent target, and a canceled confirmation. I rewrote the acceptance criteria as follows:

When a user confirms deletion, mark the property as deleted and remove it from user-facing screens.
Retain deleted properties in a state visible only to users with audit permission.
Reject a deletion request for a property with an active contract and display the reason.
Reject a deletion request for a nonexistent property and display that it was not found.
When a user cancels deletion confirmation, do not delete the property and return to the previous screen.

Rather than prescribing an implementation such as “use soft deletion,” the revised criteria state what each role can see and which result each condition produces. Only then do the requirements become testable while leaving room for multiple implementation approaches.

The report does not show that the revised criteria prevent every possible requirement bug. It confirms only that the enumerated states no longer produce conflicting results or missing responses. If the state model itself is incomplete, the verification will still have blind spots.

Return Clarification Questions, Not an Automatic Rewrite

The greatest risk in requirements analysis is allowing AI to appear to correct requirements automatically. Code and general knowledge cannot determine which behavior is right for a particular business.

The initial draft should produce at least these two questions:

1. After deletion, should the record be removed permanently, or hidden from user-facing screens and retained for audit?
2. What should happen when a property has an active contract, the property does not exist, or the user cancels confirmation?

In this form, AI supports the decision by extracting issues rather than acting as the decision maker. A person chooses the behavior, records the choice in the acceptance criteria, and only then proceeds to design and code. Kiro’s article similarly positions the user who holds the intent as the final authority on requirement correctness, while automation reduces the number of questions that person must resolve.

I consider this boundary especially important. Asking AI to “make a sensible choice for ambiguous parts” keeps implementation moving, but it hands a requirement decision to an invisible assumption. Returning a question creates an additional stop, yet it can reduce much larger rework later in the process.

Make Requirements Review a Short Pre-Implementation Gate

Formal methods are not necessary for every change. A practical starting point is a short gate that checks four items before implementation:

1. Does every acceptance criterion state an input condition and an observable result?
2. Do any criteria require conflicting results under the same condition?
3. Do major non-success paths define behavior for rejection, cancellation, and missing targets?
4. Are the criteria written as behavior visible to users or operators rather than as a prescribed implementation?

AI can list missing information against these four checks. People must still decide priorities, acceptable business exceptions, and which behavior to adopt. The goal is not to perfect every requirement before showing it to AI. The goal is to expose divergent interpretations once before generating code.

What This Verification Did Not Test

This verification did not test Kiro’s requirements analysis feature, automatic formalization by an LLM, search with an SMT solver, or accuracy against requirements from a real product. It also did not prove completeness beyond the five fixed states.

The result is smaller. Contradictions and gaps that are easy to miss when requirements are read only as prose for the normal path become easier for people to decide when converted into state-specific results and clarification questions. In practice, candidates for failure-prone states should be expanded using incident history, support inquiries, existing tests, and reviews by operations staff.

Conclusion

As AI coding becomes faster, code review alone becomes less capable of protecting quality. Ambiguities, contradictions, and undefined exception paths in requirements can flow into implementation in very little time.

In this minimal verification, the initial deletion requirements produced one contradiction and three undefined paths. The revised criteria resolved those findings by specifying observable behavior and exception responses. This does not reproduce Kiro’s system, but it demonstrates the value of returning the questions people must answer before asking AI to implement.

Before sending the next requirement to an AI system, I plan to ask whether the same condition produces conflicting results and what happens on failure. A few minutes before code generation may save hours of returning to the requirement later.