If prototypes replace documents as the source of truth for requirements, the natural next question is practical: what does that actually look like week to week? Not as a manifesto, but as a workflow — who does what, with which tools, in what order.
This is a walkthrough of how an AI-native SI team runs an engagement from first conversation to sign-off, contrasted at each stage with the document-first process it replaces.
Stage 1: Discovery — Conversation to Working Draft, Same Day
Old way: Workshops are scheduled across two to three weeks. A business analyst takes notes, then spends days turning those notes into a draft BRD. The client reviews it a week later, often finding that half of what they said got lost or flattened in translation.
AI-native way: The discovery workshop is recorded and transcribed live. An AI meeting assistant produces a structured summary within minutes — decisions, open questions, and stated requirements separated out automatically. Before the workshop even ends, someone on the team is already feeding that summary into a prototyping tool to rough out the first screens in real time, so the session closes with something visual on screen, not just a promise to write it up later.
The BRD, if one is needed at all for governance reasons, gets generated from the prototype and the transcript afterward — not the other way around. It's documentation of a decision already made visually, not the mechanism by which the decision gets made.
Stage 2: Requirements — Built, Not Described
Old way: Requirements get itemized as numbered statements in a document — "the system shall allow users to filter orders by status" — reviewed line by line in a workshop, often by people who find it hard to picture what the numbered statement actually means until they see it built.
AI-native way: Requirements get expressed as working screens. A product-minded team member uses an AI UI generation tool to turn a rough description or a hand-drawn sketch into a functioning interface within the hour — real components, real interaction states, not a static wireframe. Client stakeholders click through it themselves rather than reading about it. Ambiguity that would have taken three email threads to surface in prose ("wait, does 'filter by status' include archived orders?") gets caught the moment someone tries to use the filter and it doesn't behave the way they expected.
Where data behavior matters — validation rules, edge cases, calculation logic — an AI coding assistant wires up real logic behind the prototype rather than leaving it as a clickable mockup. The distinction between "prototype" and "early build" starts to blur deliberately, because the earlier real logic enters the picture, the earlier real requirements gaps surface.
Stage 3: Scope and Estimation — Priced Off the Build, Not the Paragraph
Old way: Estimation happens against the document. A project manager or solutions architect reads through the BRD and sizes each requirement, often disagreeing internally about what a given sentence actually implies for effort.
AI-native way: Estimation happens against the prototype, screen by screen and interaction by interaction, because effort is far easier to judge against something concrete than something described. Teams increasingly use AI-assisted estimation — feeding the prototype's components and flows into a model trained or prompted on the team's own historical delivery data — to get a first-pass estimate that a human lead then sanity-checks, rather than starting estimation from a blank sheet.
Scope gets locked by tagging a specific prototype version, not by finalizing a document. "This is what we're building" means "this is v7," full stop, with every screen and flow inside it implicitly in scope and everything outside it implicitly not. There's no ambiguous middle ground for a scope dispute to hide in.
Stage 4: Build — Continuous, Not Phased
Old way: Agile-in-name teams still run something closer to mini-waterfall: a sprint of design, handed to a sprint of build, handed to a sprint of test, with the "sprint" label doing more marketing than describing an actual iteration loop.
AI-native way: Because the prototype already contains real logic from Stage 2, "build" is less a separate phase and more a continuation of refining what already exists. AI coding assistants pair with developers to extend the prototype into production-grade code, generate test cases directly from the interaction flows already validated with the client, and flag inconsistencies between what the prototype does and what the underlying data model supports — often before a human notices the gap.
Client stakeholders keep access to a live, evolving build throughout — not a demo environment refreshed every two weeks, but the actual thing, updating continuously. Feedback loops shrink from "next sprint review" to "this afternoon."
Stage 5: Change Management — Diffed, Not Debated
This is where the earlier scope-drift argument becomes operational rather than theoretical. Every meaningful change to the prototype or build is versioned. When a client requests something new, the request gets logged against a specific version, and the delta between "what was agreed" and "what's being asked for now" is visible as an actual diff — screens added, logic changed, flows modified — rather than an interpretive argument about a sentence.
Change orders get generated off that diff automatically: what changed, estimated effort, updated cost. The negotiation that used to consume a week of back-and-forth over document language becomes a same-day conversation over a concrete, visual delta.
Stage 6: Sign-Off — The Prototype Is the Record
Old way: Final sign-off is a signature on a document that was frozen months earlier and may no longer accurately describe what got built, because change requests along the way were tracked in email rather than folded back into the source artifact.
AI-native way: Sign-off is against the current, live version of the build itself, with full version history attached as the audit trail. If a formal document is still required for procurement, compliance, or legal reasons, an AI tool generates it directly from the final build and its change history — accurate by construction, because it's derived from the thing that was actually delivered rather than drafted in parallel and hoped to match.
What This Requires From a Vendor, Not Just a Toolset
None of this works if it's treated as a tooling upgrade bolted onto an unchanged process. It requires:
- Roles that blend design, product, and engineering earlier. The old handoff chain — BA to designer to developer — collapses when one person can go from conversation to working prototype to real logic in a single sitting.
- A tolerance for the prototype being imperfect early and often. Document-first culture optimizes for looking finished before it's shown. Prototype-first culture optimizes for being shown before it's finished, because that's when feedback is cheapest to act on.
- Client-facing comfort with ambiguity resolving faster than expected. Some clients are used to a discovery phase that takes weeks and will need to be walked through why a rougher, faster first pass is actually lower-risk, not higher-risk.
The vendors who make this shift aren't doing something exotic. They're doing what the tools now make cheap and obvious — and treating the document, if it survives at all, as an output of the process rather than its engine.