From AI prototype to production product: the eval-driven path
Every prototype demoed beautifully. Six months later nothing has shipped, and "our AI strategy is basically a list of pilots" stops being a confession and starts being a diagnosis. Here are the eight stages that move a prototype into production.
The pattern arrives in board meetings now, and the executive sitting across the table can hear it before the slide deck loads. The first AI prototype demoed beautifully in week two. The second one demoed beautifully in week four. The third was deemed "production-ready" in week six. Six months later, the same executive is being asked why nothing has actually shipped, why the dashboard says "active pilots: 14" and the user-facing product surface looks exactly as it did before any of it started.
I keep coming back to a sentence I've heard from heads of engineering, CIOs, and AI transformation directors more times than I can count: "Our AI strategy is basically a list of pilots." It is meant as a confession. It always lands as a diagnosis. Somewhere between the prototype that demoed well and the production system that nobody trusts enough to give real users, the work falls into a gap that classical software development never had, and most product orgs do not yet have the operating discipline to cross it.
The internal narrative shifts from "we're building AI" to "we're stuck building AI", and the team itself starts to lose the thread on why. This article is about the discipline that closes the gap. It is not a tools list. It is not a vendor comparison. It is the operating model: eight stages of work, each with a load-bearing artifact, an exit criterion you can name out loud, and a failure mode that quietly kills products at exactly that stage if you skip it. In the R&D team I lead, this is the sequence I keep coming back to. The teams that ship treat each of the eight stages as non-negotiable. The teams that stall almost always skipped one of them, usually the second.
Scoping is where most AI products silently fail
The first stage is scoping the use case. It sounds trivial. It is the stage where the most ambitious AI initiatives quietly fall apart, because scope drift in AI work is not the same as scope drift in classical software. In classical software you build the wrong feature. In AI you build a system whose behavior nobody can predict, including the people who built it, because the behavior changes with every input.
A scoped AI use case has a one-page spec. The spec names three things: the inputs the system will accept, the outputs it will produce, and the decision boundary it will respect. The boundary names what the system will refuse to do, defer to a human on, or escalate. A non-technical reviewer should be able to read the spec and predict, for any given input, what the system should do. If they can't, the scope is not yet tight enough to build against.
The exit criterion is that prediction test. Hand the spec to someone outside the team (a senior product manager, a domain expert, a service-design partner) and run them through five sample inputs. If they can predict the system's response on all five, the scope is real. If they hedge on more than one, the scope is still narrative, not specification.
The failure mode is the sentence "we'll figure out which use case as we go." It is almost always said with the best intent: a desire to stay flexible, to let the model surprise the team. What actually happens is the opposite. The team writes prompts that work for the demo, then discovers six months in that the demo input distribution covered maybe 20% of what real users send. Every prompt change after that point becomes a negotiation between fixing the new failure and breaking the old success. Without a scoped use case, there is no eval set worth building, no baseline worth measuring against, and no release criterion that could ever fire.
Most AI products fail in production not because the model is wrong but because nobody built an eval set
This is the gravitational center of the article. It is also the discipline that separates teams that ship AI products from teams that ship AI demos.
In the prototypes I have watched make it to production versus the ones I have watched stall, the single most reliable predictor was not the model choice, the framework, the prompt-engineering sophistication, or the team's machine-learning background. It was whether the team had an eval set before they had a prompt, and whether they treated that eval set as the team's most important shared artifact rather than one engineer's side project.
A real eval set contains six distinct kinds of cases. Typical cases are the inputs that represent the most common user behavior the system will see. These are easy to gather and they are necessary, but they are the floor, not the ceiling. Edge cases are the inputs near the decision boundary, where reasonable humans might disagree about the correct answer. These are where most production failures actually happen. Adversarial cases are the inputs a hostile or careless user might construct, including prompt injection attempts, malformed inputs, and cases designed to elicit the system's most embarrassing failure mode. Drift cases are inputs that look slightly different from anything in the original training or design context, anticipating the gradual change in user behavior the production system will encounter. Cost cases are inputs that are unusually expensive to process, because cost-out-of-distribution is its own production risk you can't see until the invoice arrives. And ground truth is the explicit, agreed-upon correct answer for each of the cases above, written down by a human and reviewable by another human.
Most teams ship something else entirely. They ship vibes. Or, more charitably, they ship a handful of cases somebody on the team remembered from the last demo and ran by hand before the release call. There is no curation, no coverage discipline, no ground truth document, and certainly no shared artifact the team can look at together to decide whether a proposed prompt change is an improvement or a regression. When the prompt is changed, somebody runs the same three or four examples by hand, eyeballs the output, and ships. This is not evaluation. It is hope with a Git commit attached.
What surprises me, every time, is how late this discipline arrives. The teams that eventually build a real eval set almost always build it after a production incident the team could not explain: a regression they couldn't reproduce, a customer complaint they couldn't triage, a prompt update that fixed one thing and broke another invisibly. The eval set, in other words, gets built when the absence of it has become impossible to ignore. The teams that ship cleanly build it before that incident, on the strength of having watched another team go through it first.
The discipline shift here is the part executives find surprising, and it is the part that matters most for the operating model. The eval set is a team artifact, not an engineer's artifact. The QA who used to write test cases against deterministic acceptance criteria now curates eval cases against probabilistic behavior. The business analyst who used to write user stories now specifies ground truth: what the right answer actually is, under what definition of right, with what tolerance for variance. The data scientist who used to build models now generates adversarial cases and drift cases the rest of the team would never think of. The product manager who used to triage bugs now triages eval failures, deciding which are real defects, which are scope changes, and which are ground-truth errors. Eval set construction is the work that re-routes half a product organization's existing roles into new shapes, and it is the work most orgs are still treating as something the engineers will figure out on their own.
Built right, the eval set pays compounding dividends. Every prompt change runs against it. Every model swap runs against it. Every drift event triggers an eval run that tells the team which slice of behavior has regressed before users get to find out. Every release criterion can refer to it by score and by case coverage. The eval set is the only artifact in the AI product development lifecycle that gets more valuable with every shipped version. It is also the only artifact that, once you have one, makes every subsequent question about the AI product answerable in evidence rather than vibes.
The exit criterion for this stage is direct: the eval set can disqualify a prompt change before a human reviews it. If a junior engineer can submit a prompt update and have it automatically scored against a suite of cases, with the result blocking merge below a threshold, the eval set is real. If the team is still emailing prompt diffs around for review by Slack consensus, the eval set is not yet the load-bearing artifact.
The baseline isn't the answer, it's the floor
Once the eval set exists, the third stage is the baseline. The team picks a model, writes a system prompt, drafts the few-shot exemplars, and runs the first end-to-end pass. The scores come back. They are almost certainly mediocre, and that is entirely the point.
The artifact this stage produces is a reproducible first-eval-passing configuration: model name and version, system prompt, exemplars, generation parameters, and the recorded baseline scores on the eval set. The exit criterion is that any team member can reproduce those baseline scores from the configuration alone. If they can't, if the only way to get the baseline scores back is to ask the one engineer who originally ran it, there is no baseline. There is a screenshot of one engineer's afternoon.
The failure mode at this stage is treating the baseline configuration as the final configuration. Teams that fall into this pattern build all of their subsequent infrastructure around the assumption that the model and prompt are now fixed. Then the model changes (a new version ships, an old version is deprecated, a cost-cutting decision swaps the baseline model for a cheaper one) and the team discovers that the entire harness, the entire telemetry layer, the entire monitoring approach was built against a model that no longer exists. The baseline is meant to be a starting line, not a destination. The whole point of having an eval set is that you can swap the model and immediately know whether the swap helped or hurt. Teams that skip this discipline turn every model change into a months-long re-validation project.
A harness is what makes the system a product, not a notebook
The fourth stage is where the AI system stops being a notebook somebody can run on their laptop and starts being a system the team can operate. The artifact is the harness: a test and evaluation CI that runs the eval set against any proposed configuration change, structured logging on every production request, per-request telemetry that captures the inputs, the outputs, the model version, the cost, the latency, and the eval-relevant metadata. The full discipline behind that artifact is quality harness engineering, the emerging reliability stack.
The exit criterion is simple to state and surprisingly hard to meet: any team member should be able to take a production failure (a real user's real failed interaction) and replay it offline against the eval set within an hour. They should be able to reproduce the failure, modify the prompt or swap the model, re-run the case, and see the score change. If a production failure is an opaque event that only the engineer who built the system can investigate, the harness does not yet exist as a product artifact.
The failure mode is the demo that lives in someone's notebook while production runs blind. Telemetry is either absent or so unstructured that nobody can answer simple questions like "how often does the model refuse to answer?" or "what does an average user session cost us?" When a user complains, the team has nothing to work with except the user's screenshot and their own apologies. The system is in production by every formal definition, but the team is operating it the way they would operate a research demo: by intuition, by recent memory, and by hoping the same problem won't reappear before they have time to think about it.
The harness is the stage where the AI work most resembles classical engineering operations, and it is also the stage where AI teams who come from a pure research background most often underinvest. The instinct is to treat operability as something you will add later, once the system is "really working." The pattern I keep seeing is that systems without a harness never really work, because the team never builds the muscle of investigating, fixing, and verifying production behavior in a disciplined way.
User beta is where the eval set learns what you didn't think of
The fifth stage puts the system in front of real users: a small, deliberate group, with explicit communication about the system's limitations and an open feedback channel back to the team. The artifact is the flow of real user traces feeding back into the eval set. Every interesting interaction, every failure, every near-miss, every unexpected use of the system gets considered as a candidate case for the eval set, with the right ones added.
The exit criterion is bidirectional. Every new failure mode that surfaces in beta gets a corresponding eval case AND a corresponding prompt or model fix. Beta users have a channel to raise issues. Not "email someone if it breaks", but a real, observed, triaged channel that closes the loop back to them. If failures from beta go into a backlog that nobody works through, the beta is not actually informing the system. It is just inconveniencing the users who agreed to help.
The failure mode is putting beta users in the role of patient-zero in production. The team learns about failures the same way the users do: through the failures themselves, often through public escalation, often only after the same failure has hit several users. The beta then stops generating value and starts generating risk, and the team's confidence in the broader release erodes without any structured signal about what to actually fix.
The right disposition for beta is humility plus instrumentation. The team should expect to be surprised, and the system should be built so that the surprise is captured, analyzed, and converted into a permanent artifact (an eval case) within days, not weeks. Beta is where the eval set you built in stage two actually learns the shape of the world.
Drift is what kills the AI product after launch, not at launch
The sixth stage is what most teams discover they did not build until the AI product has been live for several months and the scores everybody was so proud of at release are no longer the scores the system is achieving in production.
The artifact is a drift monitoring layer with three signals at minimum. Input distribution shift: the inputs users are sending now look meaningfully different from the inputs the system was designed and evaluated against. Model output quality regression: the outputs are still being generated, but they are subtly worse, on a dimension the eval set can measure. Downstream user behavior change: users are abandoning sessions earlier, escalating to human agents more often, retrying more frequently, or simply using the product less. Each of these signals is a kind of drift, and each has a different root cause and a different remediation.
The exit criterion is that the drift detector fires before users complain. If the first time anybody on the team learns that the AI product has regressed is when a customer-support ticket lands, drift monitoring is not yet operational. It is also a criterion that the team has a rollback playbook: a defined sequence for what to do when drift is detected, including which version of the configuration to revert to, what the communication to affected users looks like, and what the criterion will be for declaring the regression understood and resolved.
The failure mode is quality regressing silently while nobody owns the regression. Drift is hard to notice from the inside. The team that built the system is the team most acclimated to its current behavior; they will adapt to the regression before they perceive it as one. Without an owner (a person whose explicit job it is to look at the drift dashboards weekly, ask the awkward questions, and escalate when the numbers move), drift detection becomes a piece of infrastructure that exists in the system architecture diagram but is functionally absent from the operating model.
Cost is a first-class metric, not an afterthought
The seventh stage is the one finance teams ask about first and AI teams remember last. The artifact is per-request cost telemetry. The system records, for every interaction, how much it cost to serve. A dashboard surfaces this in aggregate, broken down by user segment, by feature, by model version, by time window. Budget alerts fire when the system's spend trends materially away from the modeled unit economics. A cost-quality tradeoff view lets the team reason explicitly about which interactions are worth what cost, and where the budget headroom for adding capability lives.
The exit criterion is that the team can answer one specific question to within a 20% confidence band: "what does one user interaction cost us?" If the team cannot answer this, and it is astonishing how many teams cannot, then the unit economics of the AI product are not yet legible to anyone, including the executives who will eventually be asked to defend them.
The failure mode is the surprise invoice. The team ships the product, the product gets used more than expected, and the next month's bill from the model provider arrives at a number nobody had modeled. There is no relationship between any individual feature the team built and the cost it generates, no view of which user segments are profitable and which are not, no understanding of which prompt changes also changed the cost basis of the product. Cost lives in a separate domain from quality, and decisions about quality are made without reference to their cost implications.
Cost as a first-class metric does not mean cheapest-wins. It means that quality decisions and cost decisions are made in the same conversation, by people looking at the same dashboard, with the same eval-set context informing both. Teams that treat cost as something the finance team will worry about later end up with AI products that get pulled in a quarterly cost review long before they get pulled for quality reasons.
Release is the discipline, not the milestone
The eighth and final stage of the operating model is the one most organizations treat as the celebration and least as the discipline. The artifact is a release-criteria checklist. The eval-set pass thresholds the system must clear for each release. The drift baseline the system establishes at release, against which subsequent drift will be measured. The cost ceiling the team commits to operating within. The user-trust calibration: what the system is and is not allowed to claim, how it handles low-confidence answers, how it escalates. The rollback path that names the exact configuration the system reverts to if the release fails any criterion within the first week.
The exit criterion is that each item on the checklist has a numeric or behavioral pass/fail, the same checklist is reused for every subsequent release, and the team treats a failing criterion as a release block rather than a release footnote. If release criteria are a recommendation, they are theater. If they block ship, they are discipline.
The failure mode is the release as ceremony. The team gathers, somebody pushes the deploy, the product is now "in production", but nobody can name the criteria the release actually satisfied. When the product breaks two weeks later, the team has no baseline to compare against, no rollback target to revert to, no agreed definition of what "working" means. This is the inverse of the prototype-to-product gap I described in the opener. It is the gap where the team has all the engineering substance of a real product but none of the operational rigor that lets a real product be operated.
This is also where the prototype-versus-product distinction lands most sharply. Vibe-coding an AI feature in two weeks does not mean you have an AI product. The two-week demo and the eighteen-month production system share the same model, often the same prompt, sometimes even the same code. What they do not share is the operating discipline that surrounds them. The demo can be impressive without any of stages one through eight. The product cannot exist without all of them.
The teams I have watched cross this gap successfully have one quiet trait in common: they stopped talking about the moment of release and started talking about the criteria of release. The vocabulary shift is small. The org consequences are significant.
