Stage Two — Requirements Analysis

11.1 What Changes at This Stage #

Requirements have always been the highest-leverage stage and the most under-invested. Agentic delivery raises the leverage further, in both directions.

The upside is real and underappreciated: agents are unusually good at building exactly what a specification says. The downside is the same sentence. A human engineer receiving an ambiguous requirement typically resolves the ambiguity by asking, by inferring from context, or by noticing that the requirement contradicts something they know about the system. An agent resolves it by generating something plausible. Specification defects that were previously absorbed by human judgment now propagate directly into implementation, at machine speed, across multiple work streams simultaneously.

This inverts a long-standing economic assumption. For thirty years the argument for lightweight requirements was that specification effort was expensive relative to the cost of iterating in code. When implementation cost falls sharply and specification cost does not, the ratio flips: specification becomes the expensive, scarce, high-value activity, and it is where senior engineering judgment now earns the most.

A second change concerns requirements for AI-backed capability. A functional requirement for a deterministic component can be stated as a behavior. A functional requirement for a model-backed component cannot; it must be stated as a distribution with an acceptance threshold, a measurement method, and a defined behavior under failure. “The system summarizes the document accurately” is not a requirement. “The system produces summaries scoring at or above 0.8 on the defined rubric for at least 95 percent of the evaluation corpus, with a defined refusal path below a confidence threshold, measured against a held-out set refreshed quarterly” is a requirement, and it is one an evaluation harness can test.

11.2 Elements to Adopt #

Machine-legible acceptance criteria. Every requirement should carry acceptance criteria expressed in a form that can drive an automated check. This does not mandate a formal specification language; structured natural language with explicit preconditions, postconditions, and error behavior is sufficient and far more likely to be maintained. The test is whether an agent given only the criteria, and no access to the person who wrote them, would build the right thing.

Explicit non-functional requirements, stated numerically. The accessibility evidence in Section 3.5 is the clearest available demonstration of what happens to quality attributes that are not stated as requirements: they degrade, at population scale, without anyone deciding to degrade them.³⁷ Performance budgets, accessibility conformance targets, security requirements by CWE class, resource ceilings, and operability requirements should be stated as testable numbers at this stage, because nothing downstream will introduce them.

Security requirements specified by vulnerability class, not by aspiration. Given measured pass rates of 15 percent on cross-site scripting and 13 percent on log injection against 82 percent on SQL injection, the classes requiring explicit specification and explicit verification are known in advance.¹⁵ A requirements process that says “the system shall be secure” transfers the whole problem to a code review that the evidence says is already saturated. Name the classes, state the controls, and make them acceptance criteria.

Provenance and attribution requirements. Where the system will be distributed, embedded in a regulated product, or contributed upstream, requirements for artifact provenance, AI-authorship disclosure, and bill-of-materials content belong here rather than being discovered at release. This is also where licensing exposure is cheapest to address, and the exposure is real: a study generating more than seventy thousand method implementations against copyleft-licensed source found 1.48 percent of methods showing mean similarity above 0.7 to licensed code, rising with larger context—the finding most directly relevant to agents, which operate with far larger context windows than autocomplete.⁴⁹ The vendor’s own recitation research, dated but the only rigorous first-party measurement available, put verbatim recitation at roughly 0.009 percent of suggestions in 2021-era conditions.⁵⁰ The litigation position remains unsettled: the class action over AI code generation was argued before the Ninth Circuit on February 11, 2026 on whether the DMCA’s copyright management information provision contains an identicality requirement, and no opinion had issued as of late August 2026.⁵¹ A ruling on that question would be the most consequential single development for AI code intellectual property risk, so verify the docket rather than relying on this paragraph.

Requirements for the agents themselves. Where agents will participate at A2 or above, their scope, permitted tools, and expected behavior are requirements and should be specified and reviewed as such—not configured later by whoever sets up the repository.

Traceability that survives generation. Requirement-to-implementation traceability was historically maintained by the humans who did both. When implementation is generated, traceability must be explicit: a requirement identifier carried into the task, into the branch, into the commit, and into the test. This is unglamorous and it is what makes impact analysis possible eighteen months later.

11.3 Controls #

11.4 Evidence to Request #

• A requirement selected at random, traced forward to its implementing commits, its tests, and the release that shipped it.
• The evaluation corpus and threshold for a model-backed requirement, with the date the corpus was last refreshed.
• The non-functional requirement set for a recently shipped feature, and the pipeline check that enforces each item.
• Where a requirement has no corresponding check, that is the finding.

11.5 Failure Modes #

• Ambiguity as an implicit delegation. Requirements that a human would have queried are now silently resolved by a model. The resulting system is defensible against the specification and wrong against the intent, and the gap is discovered in production.
• Quality attributes left unstated. Accessibility, performance, and operability are assumed to be part of “doing it properly.” Under generation at volume, nothing that is not specified and checked survives.
• Behavior specified for a probabilistic component. A requirement written as though the model were deterministic produces a test suite that is either flaky or vacuous, and usually both in sequence.
• Traceability abandoned as overhead. It was already the first thing cut under delivery pressure. It is now the thing that determines whether you can answer a regulator, scope an incident, or safely delete anything.