AI Requirements Gathering: Capturing Intent Before an AI Agent Writes Code

Every engineering organization already knows that badly-scoped requirements cause rework. What changes once an AI agent can turn a vague request into working code in minutes is the cost of skipping the step that used to slow everyone down enough to notice the gap. When a feature took two weeks to build, there was implicit time for a requirement to be questioned along the way. When it takes twenty minutes, that implicit check disappears — the agent will happily build the wrong thing quickly if nobody separated verified facts from hypotheses before it started.

A ticket describes a solution. An intent record describes a problem — in the words of the person closest to it, before anyone commits to how it gets solved. That distinction is not academic: a ticket that says “add a CSV export button to the billing page” has already made three decisions (CSV format, button placement, billing page scope) that might all be wrong once someone asks what the customer actually needed. An intent record that says “customers can't reconcile their invoices without contacting support” leaves those decisions open for design to make deliberately.

An intent record is a short, version-controlled document — it can live in your repo, your tracker, or a linked combination of both — capturing an idea, a support ticket, a production signal, or a strategic initiative in the originator's own words. It is created once, close to the source of the signal, rather than being reconstructed secondhand by whoever eventually picks up the ticket.

An AI agent can help draft and structure that record from a conversation, an escalation thread, or an alert — clarifying scope, prompting for the affected users and systems, and surfacing open questions the originator hasn't thought through yet. What it cannot do is decide the problem is real or worth solving. That stays a human, product-owner decision, and the acceptance or rejection is recorded, not implied by silence or by a ticket simply moving to the next column.

This matters more, not less, once AI is involved in drafting the record. An agent under pressure to produce a convincing document can smooth over genuine uncertainty — turning “we think this might be the issue” into a confident, well-formatted paragraph that reads like established fact. The discipline of separating verified facts from hypotheses in the template exists specifically to resist that smoothing.

A support ticket arrives: “customer confused about their invoice.” Handed directly to an AI coding agent, that sentence could produce almost anything — a UI tooltip, a redesigned invoice page, an email template. Captured as intent first, it looks different: the verified fact is that three customers this month opened tickets asking what a specific line item meant; the hypothesis is that the line item's label is unclear, not that the invoice layout is broken. The proposed outcome is that a customer can identify what each charge is for without contacting support. The affected system is the billing line-item renderer, not the whole invoice page. That framing alone prevents an AI agent from redesigning a page nobody asked it to touch.

This is also where AI-generated intent needs an explicit rule that a purely human process didn't need spelled out: an agent drafting an intent record must never invent supporting evidence. A fabricated customer quote or an imagined discovery call is worse than an honest gap, because it survives into the specification and gets treated as fact by everyone downstream who trusts the record. If the evidence for a problem is thin, the intent record should say so plainly — “one support ticket, no other signal yet” is a legitimate and useful thing for an intent record to say.

Track the elapsed time from first signal to an accepted intent record — this should fall sharply once AI is doing the drafting, since the bottleneck was rarely the writing, it was someone finding the time to write it down properly. Separately track how often the intent gets materially rewritten after specification or build has already started; a high rework rate usually means intent was accepted without the open questions being resolved first, not that the world changed unexpectedly.

For teams evaluating Codex or ChatGPT Enterprise for this stage, the same evaluation question applies regardless of tool: can the assistant help a non-technical originator structure their own problem clearly, without quietly making design decisions on their behalf.

Treating the AI's first draft as the accepted version. An agent asked to turn a two-line Slack message into an intent record will produce something well-formatted and confident — and that confidence is exactly why it needs a human read before anyone builds against it. A polished document is not the same as an accepted one; the accept/reject step has to be a real, visible decision, not a formality nobody actually performs.

Letting the originator specify the solution instead of the problem. A customer success manager under time pressure will often hand over “we need a button that does X” rather than the underlying problem X was meant to solve. If the intent record just restates the requested solution, it hasn't done its job — a good facilitation prompt (from a person or an agent) asks “what would change for the customer if this shipped” until the actual problem surfaces.

Skipping the record entirely for “obvious” changes. The changes that skip intent capture because they seem too small or too urgent are disproportionately the ones that turn out to have a hidden tenant-isolation or compliance wrinkle nobody thought to ask about. The fix isn't a heavier process for small changes — it's a genuinely lightweight template that still forces the one question that matters: who is affected, and did anyone actually check?