AI Prototyping

Core thesis

AI prototyping is not faster mockups. It is a new learning system. Working software is now a decision artifact, not a deliverable. The advantage is not building more demos. It is reducing learning latency: the time between forming a hypothesis and receiving customer signal that confirms or kills it. The teams that learn fastest win. The teams that prototype without a specific decision to answer are producing artifacts, not learning.

The decision-first principle

Every prototype must answer exactly one decision. If the team cannot state the decision the prototype will resolve before building it, the prototype is waste. A decision is specific, binary, and time-bound. "Which pricing model will convert better?" is a decision. "Explore what users might want" is not. I have seen teams generate fifteen prototypes in a week and learn nothing because none of them were wired to a decision. The decision-first rule also means the prototype stops the moment the decision is answered. Continuing to polish a prototype that has already resolved the question is the most common prototyping mistake I see.

Why AI changes prototyping economics

Before AI, a working prototype cost a team one to three weeks of engineering time. That cost meant teams had to be selective. They prototyped once or twice per quarter. With AI, a working prototype costs hours or days. The LangChain State of Agent Engineering survey found that 57.3 percent of organizations already have AI agents in production. Coding agents like Claude Code and Cursor are the most commonly cited daily-use agents. When a prototype costs a day instead of a sprint, the economics invert. The constraint is no longer build cost. It is decision throughput: how many hypotheses can the team formulate, test, and evaluate per week. Most teams are not limited by how fast they can build. They are limited by how fast they can decide what to build next.

Prototype type selector

• Concept prototype: which direction deserves more investment? Used when the team has multiple paths and needs to narrow. Timebox: one to two days.
• Design prototype: what experience do we mean? Used when direction is chosen but the interaction model is unclear. Timebox: two to four days.
• Research prototype: do users understand it, want it, or can they use it? Used when behavioral signal is needed. Must be tested with real users, never internal stakeholders. Timebox: three to five days.
• Technical prototype: does the hard thing work? Used when a specific technical assumption needs validation. Most commonly: can the model produce acceptable output for this specific input class? Timebox: one to three days.

Concept prototypes in practice

A concept prototype answers "which direction?" without answering "how exactly?" A team I worked with had four competing ideas for an AI feature in their analytics product. Instead of debating for two weeks, they built four concept prototypes in three days using Cursor and v0. Each prototype demonstrated the core interaction in under two minutes of user time. They tested all four with eight customers in one afternoon. Three ideas died, one got funded. Total learning cycle: four days. The alternative, the meeting-and-mockup cycle they had used before, would have taken six weeks and produced a weaker signal. The concept prototype does not need to work at the edges. It needs to communicate the core idea clearly enough that a customer can say "I would use this" or "I would not."

Design prototypes in practice

A design prototype answers "what experience do we mean?" after the direction is chosen. The distinction matters. A concept prototype shows the idea. A design prototype shows the interaction. When a team moves from concept to design prototype, they shift from "does this idea make sense?" to "does this interaction feel right?" The design prototype must be interactive enough that a user can complete the primary task without hand-holding. It does not need pixel perfection. It needs to expose where the interaction breaks. I have watched teams skip the design prototype and go straight to build, only to discover during QA that the interaction model created confusion the concept prototype never surfaced. That rework costs weeks. A two-day design prototype would have caught it.

Research prototypes in practice

A research prototype answers "do users understand, want, or can use it?" with real behavioral data. This is the most skipped and most valuable prototype type. Internal demos do not count. The team looking at their own prototype is not research. Research means putting the prototype in front of someone who has never seen it, giving them a task, and watching what they do. Not what they say. What they do. The Writer 2026 AI Adoption survey found that 97 percent of executives deployed AI agents in the past year, yet only 29 percent saw significant ROI. The gap between deployment and ROI is often a research gap. Teams build what they think users want. Users interact with what was built. The two rarely match without research prototypes in between.

Technical prototypes in practice

A technical prototype answers "does the hard thing work?" The hard thing in AI products is rarely the UI. It is the model output quality for a specific input class. A technical prototype isolates the model call and tests it against a representative sample of inputs. The LangChain survey found that quality is the number one barrier to production, cited by 32 percent of teams. Most of those quality failures could have been detected in a technical prototype costing a few hours of prompt engineering and a small eval set. The technical prototype does not need infrastructure. It does not need a database. It needs a notebook, a prompt, and twenty to fifty real inputs. If the model cannot produce acceptable output on those inputs in a notebook, adding a UI and a database will not help.

The real cost of slow learning

The cost of slow learning is not engineering time. It is market window. Deloitte's 2026 State of AI in the Enterprise report found that worker access to AI rose by 50 percent in 2025 alone. The number of companies with more than 40 percent of AI projects in production is still below 20 percent, but that number is expected to double in six months. The window between "we have a hypothesis" and "a competitor shipped it" is compressing. A team that takes six weeks to validate a hypothesis is validating at one-eighth the speed of the market. The teams I see winning are running three to five prototype cycles per month. Each cycle: hypothesis, build, test, decide. The teams losing are still in the first cycle when a competitor launches.

How to know when a prototype has answered the question

A prototype has answered the question when the team can state what they learned and what they will do differently, and everyone in the room agrees. Not when the prototype looks good. Not when the prototype is complete. When the decision is made. Three signals that a prototype has answered the question. First, the team can articulate the decision in one sentence. Second, the evidence supporting the decision is specific: a user behavior, a performance metric, a completion rate. Third, the decision changes resource allocation. If the prototype does not change what the team does next, it did not answer a question. It was a demo.

The risk of over-prototyping

AI makes prototyping so cheap that teams can fall into a new trap: prototyping as a substitute for deciding. I have seen teams run eight prototype cycles on a single feature direction, each one slightly different, each one generating another round of feedback. They were not learning. They were deferring the hard decision. The prototype cycle should converge. Each cycle should narrow the uncertainty, not expand it. If the third prototype does not produce a clearer signal than the second, stop prototyping and make the decision with the data you have. Perfect certainty is not available. Sufficient certainty is. The rule I give teams: three prototypes per decision, maximum. After three, you are optimizing for comfort, not clarity.

Industry data on prototyping velocity

The data on prototyping velocity is still emerging, but the patterns are clear. A 2026 California Management Review study found that AI-assisted teams develop ideas 13 to 16 percent faster and produce higher-quality, more novel solutions. Procter and Gamble ran a field experiment where AI-augmented teams were three times more likely to produce top-decile ideas. The key variable was not AI access. It was cycle count. Teams that ran more cycles produced better outcomes regardless of AI tooling. AI simply made each cycle faster. The implication: the team that runs twenty prototype cycles per quarter will outperform the team that runs five, even if the slower team has better designers. Volume of learning beats quality of initial hypothesis every time.

Building a prototyping stack that works

A prototyping stack needs three layers. Layer one: a fast build tool. For UI prototypes, v0, Lovable, or Bolt. For backend prototypes, Cursor or Claude Code. The build tool must produce working artifacts in hours, not days. Layer two: a test surface. This can be a staging URL, a shared notebook, or a Loom video. What matters is that real users, not internal stakeholders, interact with the prototype. Layer three: a decision log. Every prototype gets an entry: the decision it tested, the signal it produced, the action taken. The decision log is the team's learning audit trail. Without it, the team repeats cycles without compounding knowledge. After six months, a team with a decision log has a strategic asset. A team without one has a graveyard of abandoned prototypes.

Getting started: the prototyping playbook

Start with the decision you most need to make this week. Not the most interesting prototype. The most important decision. Write it down in one sentence. Choose the prototype type from the selector above. Timebox it: concept prototypes get two days maximum, technical prototypes get one. Build with whatever tools your team already has. Do not spend a week evaluating new prototyping tools. Use Cursor, use v0, use a notebook. Ship the prototype to at least three real users. Ask them to complete a task. Watch what they do, not what they say. Document what you learned in the decision log. Make the decision. Move to the next decision. That is the loop. Run it once this week. Run it twice next week. Learning velocity compounds.