Requirements for AI
Writing Requirements for AI-Assisted Development
AI coding assistants do not reduce the need for detailed requirements. They make vague requirements more expensive, because an agent fills every gap with a guess instead of asking a question. An AI-ready requirement states the user problem, current and desired behavior, business rules, edge cases, data constraints, testable acceptance criteria, test expectations and non-goals.
There is a persistent myth that AI coding assistants reduce the need for detailed requirements. The logic goes something like this: if the tool can generate code from a brief description, why spend time writing elaborate specifications? Just tell the AI what you want and iterate.
This reasoning is backwards. AI coding assistants can generate code from vague instructions, and that is the problem. A vague requirement given to a human developer produces a conversation: "What do you mean by 'admin export'? Which fields? What format? What about permissions?" A vague requirement given to an AI agent produces working code that answers all of those questions, plausibly but often incorrectly. There is no conversation. The agent fills in the blanks with its best guess, and the result is a feature that compiles, passes basic tests and does the wrong thing.
This chapter explains how product managers and business analysts need to adapt their requirements practices for AI-assisted development. The core principle is simple: AI does not remove the need for requirements. It exposes weak requirements faster.
Why Requirements Quality Matters More Now
In a traditional development workflow, the gap between a requirement and a working implementation is bridged by human developers who ask clarifying questions, make judgment calls and flag ambiguities. The feedback loop is informal but effective. A developer reads the ticket, realizes the acceptance criteria are vague, walks over to the product manager's desk (or sends a Slack message) and gets clarification before writing any code.
AI agents do not do this. When Claude Code or Copilot receives a task, it executes based on what it knows: the prompt, the codebase and any context files it can access. If the requirement is ambiguous, the agent resolves the ambiguity by making assumptions. Those assumptions may be reasonable. They may also be completely wrong. Either way, the team only discovers the mismatch during review, if it catches it at all.
This is not a hypothetical risk. Some AI implementations actually increase completion time, not because the AI is slow, but because the time saved on implementation is consumed by rework when the generated code does not match intent. The root cause in most cases is the same: insufficient specification.
Thoughtworks identified spec-driven development as one of the most important practices to emerge in 2025, specifically because it addresses this problem. The workflow is straightforward: teams write a living specification that captures the full scope of a change, the AI generates an implementation that follows the spec, and the spec doubles as acceptance criteria for validation.
What an AI-Ready Requirement Looks Like
A good requirement for AI-assisted development is not fundamentally different from a good requirement for human development. It just needs to be more explicit about things humans would typically infer.
Consider the difference between these two requirements:
Inadequate: "Add admin export."
AI-ready: "Admin users need to export filtered customer records to CSV from the customer list page. The export must respect the current filters, include only fields already visible to admins, exclude deleted accounts, support up to 50,000 rows, and return a clear error if the export fails. The change is complete when unit tests cover the filter logic, integration tests verify permissions, and QA can validate the export from the staging admin account."
The first requirement gives a human developer enough to start a conversation. It gives an AI agent enough to build something that might export all customers to an unfiltered CSV without permission checks: a feature that works but creates a data privacy incident.
The second requirement removes ambiguity at the points where an AI is most likely to guess wrong: scope (which users), data boundaries (filtered, visible fields, no deleted accounts), performance constraints (50,000 rows), failure handling (clear error) and verification criteria (specific tests).
The Structure of an AI-Ready Requirement
Based on the patterns that produce the best AI-assisted outcomes, a well-structured requirement should include these elements:
User problem. What specific problem is the user experiencing? Not "the admin needs export functionality" but "admins currently have to manually copy data from the screen to analyze customer records, which is error-prone and time-consuming for lists over 100 records."
Current behavior. What does the system do today? This prevents the AI from reimplementing existing functionality or conflicting with current logic.
Desired behavior. What should the system do after this change? Be specific about inputs, outputs and state changes.
Business rules. What logic governs how the feature should work? Include data validation, permission rules, calculation formulas and conditional behavior.
Edge cases. What happens when input is invalid, data is missing or the user does something unexpected? Listing edge cases explicitly prevents the AI from ignoring them.
Data constraints. What are the volume limits, format requirements and data sensitivity considerations? Include performance expectations and privacy boundaries.
Acceptance criteria. What specific, testable conditions must be true for the requirement to be complete? They should be precise enough that a test can be written against each one.
Test expectations. What types of tests are expected: unit, integration, end-to-end? Which scenarios should they cover?
Non-goals. What is explicitly out of scope? This is one of the most underrated elements for AI-assisted development. Without non-goals, an AI agent may solve adjacent problems you did not ask it to solve, creating scope creep within a single implementation.
Specifications as Living Documents
The spec-driven development approach, as described by Thoughtworks and implemented in tools like Kiro, takes this further. Instead of writing requirements as ticket descriptions that are read once and forgotten, teams maintain specifications as living documents, often as Markdown files checked into the repository alongside the code.
This approach has several advantages for AI-assisted development. First, the specification is always available to the AI agent. When an agent reads a spec file in the repository, it has the full context for the change it is implementing. It does not need to parse a Jira ticket through an integration. The context is local.
Second, the specification evolves with the implementation. As the team discovers edge cases or refines business rules during development, the spec is updated. This prevents the common problem of requirements documents that diverge from reality within days of being written.
Third, the specification serves as acceptance criteria for both human and automated testing. When a QA engineer validates the feature, they test against the same document the AI used for implementation. When the team runs automated tests, the tests can reference the spec for expected behavior.
Research from Augment Code found that code generated with explicit technical specifications, including technology stack, architectural style and coding conventions, was measurably higher quality than code generated from plain-text descriptions. Chain-of-thought prompting and few-shot examples within specifications produced even better results. This is consistent with what Addy Osmani, an engineering leader at Google, recommends: specifications should explicitly define external behavior, including input/output mappings, preconditions, postconditions, invariants and interface types.
The Azumo SDLC puts the spec in the same place. Its feature workflow runs clarify → spec → plan → build → validate → review → deliver, and the agent stops for a person's approval after the spec, before any plan or code exists. A requirement that is still vague gets caught at that gate, not in review.
The PM's New Discipline
For product managers, this shift requires a change in habits. The traditional PM workflow might involve writing a user story with a brief description and acceptance criteria, discussing it with the team during planning, and relying on developers to fill in technical details during implementation.
In AI-assisted development, the PM's output needs to be more precise. Not longer: more precise. A well-written AI-ready requirement can be shorter than a traditional requirements document because it strips out narrative and context that the AI does not need. But it must be unambiguous about behavior, boundaries and verification.
This does not mean PMs need to write technical specifications. It means they need to write behavioral specifications: clear statements of what the feature should do from the user's perspective, with explicit boundaries and success criteria. The engineering team then translates those behavioral specifications into technical constraints and context file updates.
AI can help with this process. PMs can use AI assistants to draft acceptance criteria, identify edge cases they might have missed and generate test scenarios from the requirement. The PM's job is to review and refine these drafts, not to accept them uncritically. AI is a useful thinking partner for requirements, but it cannot substitute for product judgment about what matters to the business and the customer.
Common Mistakes to Avoid
Several patterns consistently produce poor outcomes in AI-assisted development:
Requirements by reference. "Do it like the billing page" assumes the AI understands what "like the billing page" means. Unless the billing page is explicitly documented in the context layer, the AI will interpret this differently than you expect.
Implicit permissions. "Only admins should see this" is not enough. Which admin roles? What happens when a non-admin tries to access it? Is the restriction at the UI level, the API level or both? AI agents will implement the path of least resistance unless told otherwise.
Missing failure modes. "Export customer data to CSV" does not address what happens when the export times out, when the data includes special characters, when the file exceeds the browser's download limit or when the user triggers two exports at once. Each missing failure mode is a potential production incident.
Acceptance criteria that cannot be tested. "The export should be fast" is not testable. "The export should complete in under 10 seconds for lists of up to 50,000 records" is testable, and an AI can generate a performance test against it.
Scope without boundaries. "Improve the admin dashboard" gives an AI agent permission to change anything on the dashboard. Without non-goals, it may reorganize layouts, add features and refactor components that were not meant to change.
Getting Started
Teams moving to AI-assisted development should start with a requirements template that includes the elements above. Keep it simple: a Markdown template with sections for user problem, current behavior, desired behavior, business rules, edge cases, acceptance criteria and non-goals. Use it for every new feature. Refine it based on what works.
The initial investment is small. Writing a good AI-ready requirement takes longer than writing a vague ticket, but that time prevents hours of rework when the AI generates code that misses the mark. As teams get used to the format and as context files capture more of the project's conventions, requirements become faster to write because less context needs to be restated each time.
When clients bring us in for custom software development services, our project managers and business analysts work with client stakeholders to define AI-ready requirements as a standard part of delivery. In the Azumo SDLC they also write down what they know as skills (how to do a step) and rubrics (what good looks like), so the standard for a good requirement is shared across the team rather than held by one person. We have found this discipline to be one of the highest-leverage activities in AI-assisted development. The requirements are not perfect, but they create a shared standard for what "done" means that both human developers and AI agents can work against. When the requirement is clear, code review is faster, the QA cycle is shorter, and the UAT session surfaces real issues instead of basic misunderstandings about what the feature was supposed to do.