A vague spec forces a guess, and a human should make it before an agent codes

Rajath Mahendrappa Kotyal of AWS argued on the AI Engineer show that a vague or silent spec leaves a coding agent to guess. A person should settle the question before any code is written. His example was an instruction to remove a record, which could mean two quite different things.

What was said

Kotyal described Kiro, an AWS tool that checks a spec before any design or code is generated. It pairs language models with solvers, which are programs that test whether a set of rules can all be true together.

To find vague wording, the tool asks the model to translate the same rule several times. It groups the translations that mean the same thing. If they split into different groups, that split signals the rule is ambiguous.

He showed that two rules can each look fine alone yet clash once they are read together. He also separated a conflict from a gap. A gap is a case no rule covers, and his example was an idle order.

For the vague instruction, the tool does not let the model choose. Kotyal said: "The LLM can interpret anything it wants but we shouldn't allow that to happen." The user gets two options instead. Either the record is deleted, or it is kept and hidden from users.

He summed up the design in one line: "The LLM translates, the solver checks, and the human decide."

Why it matters

Our reading: the delete-or-hide choice is a business decision, not a technical one. A deleted record may be gone for good. A hidden one is still stored. Each outcome lands on a customer or an owner who never saw the choice being made.

The idle order works the same way. If no rule covers it, something will still happen to it, and whoever placed that order lives with the result.

For teams that use coding agents, the practical question is who reads the spec for silences before the agent starts. Buyers of such tools can ask whether the tool brings these choices to a named person, or settles them quietly.

The other side

Kotyal was open about the limits. He said nothing can confirm a spec is correct except the user, who has to check every part of the rule book before it goes to the model. The tool, he said, can only help.

He also said the user matters because of implicit domain knowledge, which the model lacks. And he noted that evidence for formalization, meaning turning plain-language rules into a form a solver can check, and for its use in agents, is still thin.

One gap remains in what he described. If the user gives no answer, the tool falls back on model judges or declines to implement that piece. A fallback to a judge is still a machine making a call. The talk did not say how often that happens.