A human developer gets a ticket saying "speed up the catalog" and goes asking. In the hallway, in DMs, at the daily. They fill in the blanks: they know the catalog runs on PostgreSQL, that the last import broke, and that "speed up" in this company means p99, not average. Half the requirements are reconstructed from the team's domain experience, and nobody even notices.
An AI agent gets the same ticket and starts writing code. It doesn't fill in the blanks. It reads literally.
Three weeks later, the retrospective produces "AI can't handle architecture." That's false. It handled exactly what was written down.
The Cost of Ambiguity Is Paid in Context Window
If a specification leaves a gap, a contradiction, or an uncovered scenario, the agent doesn't stop to ask. It picks an interpretation and builds everything else on top of it. Incorrect code is actually a lucky outcome in this scenario. Worse case: the agent hallucinates the missing context and constructs architecture around a fabricated assumption.
Context window and budget go to guesses. Not to implementation — to reconstructing what the analyst knew but didn't write down. Then those guesses solidify: generated code becomes the source of truth for a requirement that never existed.
Add the gap between the ticketing system and messaging apps. Formally, the requirement lives in Jira. Functionally, half the context is spread across three Slack threads the agent never sees. Code review becomes pointless beyond checking the diff: arguing whether the task was solved correctly is impossible, because the task was never formulated in a way that could be solved incorrectly.
Three weeks down the drain is not a model failure. It's the bill for absent input control.
Requirements standards became more important once agents started implementing from tickets
Requirements engineering dealt with this long before agents appeared. ISO/IEC/IEEE 29148, which replaced IEEE 830, is widely used as an international requirements standard; BABOK recommendations sit alongside it. Teams that manage requirements formally often use tools such as ReqView, IBM Engineering Requirements Management DOORS Next, Siemens Polarion ALM, Jama Connect. They all perform the same basic function: storing a requirement as a distinct entity with an identifier, links, and change history.
In many non-regulated teams, these practices were often treated as unnecessary process overhead. As long as humans read requirements, weak phrasing was compensated by conversation. The standard was insurance, not a necessity.
An agent usually cannot recover missing context from hallway conversations or team memory. Criteria such as atomicity, verifiability, and traceability become directly tied to implementation quality: they stop being documentation hygiene and become the input specification for a machine that can't ask questions in the hallway.
Requirement checks that matter when an agent implements the ticket
Atomicity. A requirement contains one complete function or business rule. A complex formulation often causes missed branches, mixed responsibilities, or incomplete implementation: asking an agent to simultaneously implement registration, message sending, and account blocking means it will likely miss a detail in one step or mix up the logic of different components. Breaking tasks into isolated subtasks keeps the agent within the boundaries of a single step.
Unambiguity and clarity. "Fast loading" and "user-friendly interface" should be replaced before the ticket reaches an agent. The agent interprets "loading must be fast" at its own discretion — resulting in inappropriate library choices or missing constraints where they are critical. Replace adjectives with numerical metrics, interaction contracts, or technical parameters: max API response time at a given percentile.
Verifiability and testability. Falsifiable acceptance criteria give the agent and reviewers a way to check whether the task was solved. If a requirement is described as a measurable algorithm with a clear result, the agent can work through tests: write the check itself and run the code against it. A measurable criterion looks like: "export ≤ 15 minutes for 50k SKUs", "CSV to s3://…", "no PII". An unmeasurable one looks like "export must work fast and correctly".
Completeness. Agents usually treat omitted behavior as unspecified and may either ignore it or invent a default. If only the happy path of a button click is described, and network errors, repeated clicks, validation, and edge cases are omitted — the agent will either leave those zones unhandled or write naive implementations. For high-risk flows, describe behavior for success, failure, retry, validation, and boundary cases. Organizations use specification templates based on 29148 — SRS, BRS, and others — with mandatory sections, requirement attributes, and filling guidelines to control completeness.
Consistency and coherence. Mutually exclusive instructions in rule files, system prompts, and specs can cause repeated rewrites, conflicting implementations, and unstable output. Contradictory context causes circular code rewrites and looping: the agent faithfully executes both instructions in turn. This is treated with centralized requirement storage with versioning and change tracing — this is one of the functions of enterprise ALM platforms, synchronizing requirements between analysts, architects, developers, and testers.
Traceability. Traceability is useful when the agent must connect a business goal with API contracts, schema changes, tests, and affected files. Clear requirement identification helps it navigate the project and avoid breaking adjacent modules. This matters more when several agents or developers work on related changes in parallel: if a requirement is linked to a user story, architectural decision, test cases, and commits, the agent determines the scope of changes and doesn't spread side effects across the project.
Feasibility and necessity. A requirement must be implementable within the current stack and architectural constraints. And it must be necessary: excess functionality that doesn't serve the business goal clutters the context and increases the error rate. An unnecessary requirement costs not only its own implementation — it costs the agent's attention on everything else.
Put a clarification check before implementation
A checklist helps only if it blocks incomplete tickets from entering development. They become useful when the workflow prevents incomplete tickets from moving forward.
A ticket doesn't go into development without a goal, scope, and falsifiable acceptance criteria — this is a clarify gate. A ticket missing goal, scope, or testable acceptance criteria stays in clarification. I built this mechanics on Jira: a bot intercepts the ticket, asks clarifying questions along axes — scope, actors, data, non-functional requirements, dependencies, acceptance criteria — and doesn't release the task into progress until the answers cover these axes. The code is open: jira-clarify-bot — a reproducible trace of the mechanics and webhook contract, not a boxed product for someone else's Jira.
The useful part is not the question list itself, but the context used to generate each question. A generic question like "Which systems are affected?" is useless — the answer is "well, the catalog and search", and the ambiguity stays exactly where it was. A grounded question sounds different: "Is the storefront SLA of p99 200ms a hard constraint for batch export too?" You can't answer that with generalities.
The difference between these two questions is project context decomposed into layers. L1 — project bible, a compact document about the system. L2 — the project's corpus of materials. L3 — the Jira graph: links between tasks, epics, past decisions. A context pack is assembled from these layers, making the questions specific.
On the other side of that barrier stands the feature specification. In many failed agent experiments, a large feature is handed to the model as one broad prompt: the result is often a hard-to-review diff, unclear rollback path, and a retrospective focused on model failure rather than input quality. A spec-driven workflow changes the order: spec first, then plan, then contracts, and only after that implementation. The [NEEDS CLARIFICATION] marker right in the spec text forbids silent assumptions: where something is unknown, it must be marked, not filled with a guess from the author or the agent. A contracts/ directory appears before implementation. A separate analysis step runs a consistency loop between spec ↔ plan ↔ tasks — turning the consistency check into a repeatable workflow step. The tooling is spec-kit; what this looks like on a live project is visible in ytrader-bybit.
Who validates which part of the requirement
Validation isn't done by one person, and ownership should be explicit, otherwise validation turns into a shared responsibility that nobody performs.
Analysts and product managers close implicit assumptions. The task is to translate business needs into a structured document with logical rules, business constraints, and user journeys spelled out. Unified templates and checklists based on 29148 catch recurring ambiguities such as missing actors, missing constraints, and undefined edge cases before anyone opens an editor.
Architects define module boundaries, data ownership, interface contracts, and allowed implementation patterns. Requirements must rigidly fix module boundaries, data schemas, design patterns, and interface contracts. For APIs, this means contract-first: OpenAPI description first, implementation second. Common tools for this include the Spectral linter, which catches ambiguities and corporate styling violations right in the spec before implementation begins, and Prism, which checks that real requests and responses match the contract. For an autonomously working agent, this helps because contract violations can be detected before acceptance testing.
QA converts acceptance criteria and boundary cases into test cases, contract checks, and regression checks. With quality requirements, an exhaustive set of test cases can be assembled by an engineer or the agent itself — and then automatically checked against contracts.
Where This Breaks
A clarification gate does not improve requirements if teams approve weak answers unchanged.
One common failure mode: hallucinated requirements. While refining a spec, a model may add unsupported assumptions to the spec, and phrases them confidently. If clarifications are accepted without human approval, the spec gains fabricated facts — which then get diligently implemented.
Second: rubber-stamp approval. Answers received, axes covered, acceptance criteria written as "the system must work correctly." The workflow shows a passed gate, but the acceptance criteria still cannot be tested. The status is green, while the requirement remains unverifiable.
Third: stale project bible. The context pack is assembled from L1, and when L1 is six months behind the system, the bot generates questions based on obsolete constraints. A grounded question about an outdated SLA is worse than a generic question — it confirms a constraint that doesn't exist.
Fourth: duplicated clarifications. The bot asks in the ticket, the team discusses the same thing in Slack in parallel, and the ticket and Slack thread start containing conflicting decisions. The gap the gate closed reopens sideways.
The spec-driven workflow can fail in several predictable ways. A spec written only to satisfy the process: a file written because it's required, while code is driven from a prompt. Drift after implementation: spec is frozen, code moves ahead, nobody syncs. A feature too large, where the spec honestly describes three months of work and stops being checkable. Contracts without versions. Duplicated constraints in multiple places, when the same constraint is recorded in the spec and in the agent's rules file — differently. And overhead: running the full spec cycle to fix a typo is likely to make the team bypass the process quickly.
There's also a general limitation. Some studies suggest that large language models can identify certain violations of 29148 quality criteria and suggest improved phrasing, so automated preliminary checks can be useful, but should still be reviewed by humans. This should be treated as assisted review, not as validation authority. A model checking requirements is a participant in the process, not its guarantee.
Why agent-based coding exposed weak requirements
Agent-based development did not remove the need for requirements engineering. It made informal requirement repair harder to rely on. Many teams already had weak requirements before agents entered the workflow — the price was just paid by humans, smeared across DM clarifications, domain experience, and a senior developer's ability to read between the lines. That compensation was invisible and therefore rarely accounted for in planning.
The agent cannot rely on undocumented team memory in the same way a senior developer can. It turns input quality into output quality without amortization — and makes requirement gaps easier to trace to concrete implementation failures. A bad spec is no longer "an inconvenience for the team" but a reproducible failure with a clear cause.
Validation is not just process overhead; it is the main control point before code generation. Atomic, testable, and traceable input generally makes agent output easier to review and reproduce. Code generation becomes easier to manage when incomplete requirements are blocked before implementation, when the workflow includes an enforced clarification step.
Minimal process changes to start with
The initial process can be small.
Set up a gate at the entrance to development: a ticket without a goal, scope, and falsifiable acceptance criteria doesn't get picked up. Make this a workflow rule, not a recommendation. Check criteria for measurability by substituting a number: if you can't replace "fast" with "≤ 15 minutes for 50k SKUs", the requirement isn't ready.
Layer your project context. Without a project bible and a corpus of materials, any clarifying questions will be general, and generic clarification prompts usually produce answers that do not resolve the missing constraint. Assign an owner for L1 and a date for the last reality check — stale context can be worse than missing context because it causes confident but obsolete assumptions.
For APIs — use contract-first for APIs by default, with explicit exceptions for trivial/internal cases if your process allows them. Spec before code, spec linting before implementation, implementation checked against contract. The agent needs the contract as the single source of truth for the interface, otherwise it may infer an interface from incomplete examples or nearby code.
For features — spec before code, with explicit [NEEDS CLARIFICATION] markers where things are unknown. Cut features down to a size where the spec stays checkable. Keep each constraint in a single authoritative place: one constraint lives in one place, or the agent will execute both versions in turn.
Do not discuss model quality before checking whether the input requirement was testable and complete. As long as input requirements don't pass through a barrier, debating whether AI can handle architecture will miss the main failure source.
Requirements always determined the outcome. There used to be a person standing between a bad requirement and bad code, silently closing the gap with their own experience. That buffer is much thinner when an agent implements directly from the ticket. Any omitted constraint may be replaced by the agent's inferred default — and that default may conflict with the team's real expectation. If your retrospective is hearing "AI can't deliver" for the third time, review the original ticket, clarifications, and acceptance criteria before blaming the generated code.