Prototype First: Using AI Tools to Validate Requirements Before Engineering Begins

When I write “the user should be able to filter results by date range,” everyone nods. The product owner nods. The engineering lead nods. The client nods.

But everyone’s picturing something different.

One person imagines a simple dropdown with preset ranges. Another expects a calendar date picker. A third assumes the filter is global and affects every panel on the screen. A fourth has never thought about what happens when the end date is before the start date.

That ambiguity sits undetected in the requirements document until development is underway. Then it surfaces as a question, a rework request, or a missed expectation. At best it costs a sprint. At worst it damages trust.

This is the problem with text-based requirements. Words are abstract, and abstractions let people project their own assumptions onto them.

For years, the BA toolkit for addressing this was workshops, wireframes, and carefully worded acceptance criteria. These still matter. But there’s now a faster, more effective tool in the mix: AI-powered rapid prototyping.

What Changed

Tools like Replit, OpenAI Codex, and Claude have made it possible for a BA, without deep front-end development skills, to produce a functional, interactive prototype in a matter of hours.

Not a static mockup. Not a PDF of annotated screenshots. Something you can actually click through.

When there’s something in front of a stakeholder that they can interact with, the conversation changes completely. They stop saying “yes, that sounds right” and start saying “actually, I’d expect this button to be here” or “wait, what happens if I select more than three items?”

Those are exactly the questions you need answered before engineering begins.

How I Use It in Practice

In discovery, once I’ve got a reasonable understanding of what a feature or flow needs to do, I build a quick prototype before writing the detailed requirements.

I’m not building something production-ready. I’m building something good enough to have a useful conversation. A functional UI with realistic-looking data, the core interactions working, and enough fidelity that stakeholders are reacting to the actual concept rather than mentally filling in blanks.

My typical approach starts with Claude. I describe the feature in plain English: the user journey, the data involved, the constraints. Claude is good at reasoning through the logic of a flow and, usefully, it often spots the questions I haven’t asked yet. From there, I use Replit to run and share the prototype instantly. No local setup, just a shareable link I can drop into a meeting. For anything requiring more structured code generation, Codex fills in the gaps quickly.

None of this requires me to write production-quality code. The goal is speed to conversation, not code quality.

I then walk stakeholders through the prototype, and crucially, I ask them to use it rather than watch me use it. The moments where they hesitate, go back, or try something unexpected are the most valuable data points in the whole discovery process.

What It Surfaces

Honestly? Things I wouldn’t have thought to ask about.

Edge cases are the obvious one. What happens when there are no results? What does the loading state look like? What if the user’s permissions don’t allow them to take an action that the UI implies they can?

But the more interesting discoveries are assumption conflicts. Two stakeholders who’ve confidently agreed on a requirement but have incompatible pictures of what it means. The prototype makes that visible immediately, in the room, while it’s still cheap to fix.

Prototypes also surface scope. When stakeholders see a flow working end to end, they often realise they’d assumed adjacent functionality that was never discussed. Raising that in a discovery session is a much better outcome than raising it mid-sprint.

It Doesn’t Replace Requirements. It Improves Them.

The output of a prototyping session isn’t the prototype. The prototype is a conversation tool. It gets decommissioned.

The output is better requirements: more precise acceptance criteria, edge cases already resolved, a shared understanding the engineering team can build to confidently.

One thing to watch for: stakeholders occasionally become attached to a prototype and start treating it as a commitment. I’m explicit from the start that what they’re looking at is a discovery tool, built to validate thinking, not a preview of the final product. That expectation-setting matters.

What This Means for Engineers

When the engineering team picks up a piece of work that’s gone through this process, the experience is different. The requirements are tighter. The edge cases are documented. There’s a prototype they can reference when something is ambiguous, even though they’re not building to it directly.

Less time spent in clarification conversations mid-sprint. Fewer surprises late in delivery. The back-and-forth between BA, stakeholder, and developer gets compressed into the discovery phase, where changes are cheap, rather than the delivery phase, where they’re not.

A Different Kind of Discovery

This isn’t about replacing the craft of business analysis with AI shortcuts. Understanding what a client actually needs, translating that into something buildable, managing the gap between ambition and constraint: that still requires judgement, experience, and trust built over time.

What these tools do is close a gap. The gap between “we’ve had a conversation about this” and “we have something concrete enough to test our assumptions.” That used to take days of design and wireframing effort. It now takes a few hours.

The result is faster alignment, fewer surprises, and software that does what stakeholders actually meant, not just what they said.

If you’re planning a software project and want to explore how this approach could work for you, get in touch with the Talk Think Do team.