Requirements Engineering with AI: The Task Shift Created by Coding Agents
When a coding agent reduces implementation effort, the requirements work remains. A recent research review describes engineering effort moving away from code creation and toward expressing, curating, verifying, and evaluating requirements (Requirements are All You Need). The shift is conditional rather than a universal reduction in software-delivery effort, and the review is neither systematic nor comprehensive.
Three groups of actors shape this mechanism. Stakeholders hold domain needs and acceptance expectations. Engineers turn those needs into constraints and implementation assignments. A coding agent produces a reviewable change using the information and authority it receives. It may accelerate a bounded implementation step, but people still decide what the system should do and whether the result is acceptable.
System boundary: What lower implementation cost means
The trigger is lower implementation effort under particular conditions. In a controlled JavaScript HTTP-server task, developers with an AI pair programmer completed the task 55.8% faster than the control group, with a 95% confidence interval of 21–89% (Peng et al.). Across three field experiments involving 4,867 developers, use of an AI coding tool was associated with a 26.08% increase in completed tasks in the combined analysis (Microsoft Research). Acceleration occurred in these studied settings. That does not make it universal.
Other settings can produce the opposite result. In a study of 16 experienced developers working on 246 real issues in familiar open-source repositories, developers took 19% longer with AI tools. The researchers identified high quality standards and implicit requirements as possible explanations (METR).
Faster coding does not automatically improve delivery as a whole, either. In DORA survey data from nearly 3,000 professionals, higher AI adoption was associated with slightly faster code review and approval but lower delivery throughput and stability. These organizational associations are not causal proof that AI produced those outcomes (DORA). The mechanism described here begins only when an agent makes a bounded implementation task less expensive. It does not assume that the entire value stream becomes faster.
Prerequisites: Explicit intent, not simply more context
Acceleration starts when the next goal is sufficiently clear. Research on programmer interaction with Copilot distinguishes an acceleration mode, in which developers already know what to do next, from an exploration mode, in which uncertainty leads to slower interaction, explicit prompting, and more validation (Barke et al.). If the engineer has not resolved the objective, AI interaction can move the uncertainty around without resolving it.
A business requirement is rarely the same thing as an executable assignment. Interviews with 18 practitioners from 14 companies found that documented requirements were generally too abstract for direct LLM input. Practitioners first decomposed them into programming tasks, then added design decisions and architectural constraints (Requirements Engineering for LLM-Based Systems). What matters is not a longer prompt, but a bounded task with explicit behavior, interfaces, constraints, and acceptance expectations.
Context also needs selection, not accumulation. In one benchmark, developer-provided context files improved performance by 4% on average, while LLM-generated context files reduced it by 3% on average. Both forms increased exploration, testing, reasoning, and costs by more than 20% (Evaluating AGENTS.md). Relevant context can support an assignment. Context volume alone cannot reliably replace requirements work.
From a clarified assignment to agentic implementation and back to acceptance
The sequence begins with intent. Stakeholders and engineers establish the desired outcome, resolve important ambiguities, and name constraints. Engineers then turn that outcome into a programming task the agent can act on. This decomposition belongs to requirements engineering: it translates desired behavior into a bounded change without giving the implementation system authority over that behavior.
The engineer then supplies the task and curated project context. A background coding agent can continue delegated work with background coding agents without a developer driving every interaction. This changes who performs the implementation loop, not who owns stakeholder intent or acceptance.
The agent returns code and other reviewable artifacts. At that point, the workflow moves from implementation back to evaluation. People inspect the change, test relevant behavior, correct mismatches, and decide whether to merge it. In a study of agent-assisted pull requests, 83.774% were eventually accepted and merged; among merged pull requests, 45.052% required human revision (Agentic Pull Requests). Documented human review and merge gates for agent work preserve consequential decisions even when execution is unattended.
This is where the work shifts. When the implementation loop gets cheaper, the information entering it and the evaluation applied to its output matter more. Ambiguity that once surfaced during manual implementation must be resolved before delegation or found during review. Implementation may shrink while clarification, decomposition, context curation, verification, correction, and acceptance remain.
GenAI capability and limits in requirements engineering
GenAI can use missing information after people make it available. In experiments on underspecified instructions, interactive access to missing information improved model performance by as much as 74% over non-interactive settings. The same work found that models struggled to distinguish well-specified from underspecified instructions and tended not to seek clarification without explicit encouragement (Models Need to Ask). The demonstrated capability is using supplied clarification, not reliably recognizing that stakeholder intent is absent.
LLMs can revise requirement text as well. In one evaluation, participants reported that revisions surfaced additional aspects in 43% of evaluations. Yet 7 of 130 revisions introduced factual or logical inaccuracies, and participants also reported loss of meaning, focus, or thematic alignment (LLMs for Requirements Revision). Revision can support analysis, but it does not transfer authority over intent or correctness from the people responsible for the requirement.
The useful distinction is between assistance and ownership. A model may suggest a clearer statement, expose an overlooked consideration, or implement a clarified assignment. The supplied evidence does not support treating it as the reliable source of stakeholder intent, a reliable detector of every missing requirement, or the final judge of acceptance.
Observable signals of the task shift
The first signal appears before delegation, as requirements gain implementation-facing detail. Teams answer open questions, split broad outcomes into tasks, make design decisions explicit, and move architectural constraints into the assignment. These artifacts make the handoff visible.
A second signal appears after generation. Human revisions to agent-assisted pull requests reveal correction and acceptance work that generation did not remove. Verification may also appear as additional search, validation, deletion, and rewriting. In a laboratory study with 28 participants across three projects, awareness of code provenance increased search effort and cognitive workload and was associated with deleting and rewriting generated code (Code Provenance Study).
You can look for this mechanism in one existing assignment with a small observation:
- Before delegation, record the information added to make the requirement programmable: resolved questions, task boundaries, design decisions, constraints, and acceptance expectations.
- After the agent returns output, record human search, testing, revisions, validation, and acceptance work.
- Compare that pre- and post-work with the implementation effort for the assignment, without inferring a general productivity effect from one observation.
This observation does not prove causality. It shows where work occurs and whether a locally faster implementation step comes with more explicit requirements and evaluation activity.
Counterconditions: When the shift does not produce acceleration
The mechanism weakens when an assignment depends on tacit knowledge that is difficult to express. The study of experienced open-source maintainers shows that familiar repositories, implicit requirements, and high quality expectations can coincide with slower work when AI tools are used. In that setting, discovering and communicating what “correct” means can take more time than generation saves.
Context overload can weaken it too. Automatically generated repository instructions may add exploration and cost without improving task success. More context increases both the surface the model must interpret and the surface a person must verify.
A local gain can also disappear downstream. Faster code production or review does not establish higher delivery throughput, stability, or customer value. Integration, testing, coordination, and release constraints may remain unchanged or become the new bottleneck. Requirements Engineering with AI should therefore be assessed across the handoffs around implementation, not by generated-code volume or coding speed alone.
Where agentic implementation works, the defensible conclusion is narrow: effort can move from writing code into expressing intent, decomposing work, curating context, verifying results, and accepting changes. To find out whether that shift is occurring, follow one real assignment from clarification through acceptance and account for the work on both sides of generation.