“The AI just works” is the most expensive sentence a founder will say during scoping. Said in week one, it sounds like vision. Said in week fourteen, it is the line repeated to a salvage team explaining why the first build cost three times budget and still cannot ship. The phrase is the load-bearing scoping bug of 2026 AI MVPs — works without an eval threshold means every person in the room is holding a private definition, none aligned, and nobody can prove on any given day whether the system is ready. The fix is to retire the phrase and replace it with one specific sentence that names the threshold, the eval set, and the model — so the build has a falsifiable definition of done from day one.
This piece develops the eval-first build playbook, part of the idea-to-product manifesto. Read it alongside the quality-first scoping method for AI features and the eval rubric template every non-technical founder should ask for. The polemic version lives at stop scoping AI projects in features, scope them in evaluations.
Table of Contents
- What the founder means when they say it
- What the engineer hears
- The four unstated assumptions
- The eval-hour cost of catching them late
- The replacement phrasing
- A worked example — the same idea, both ways
- Why the phrase persists despite costing so much
- Frequently Asked Questions
- Closing
What the founder means when they say it
When a founder says “just works,” the founder is describing a user experience. They have rehearsed a demo in their head — the user types the input from the last pitch deck, the assistant produces the output they got experimenting in Claude, the room lights up. Works is shorthand for “the demo in my head, available 24/7.” It is a feeling, not a specification.
That feeling has three implicit components: cosmetic plausibility (the output looks competent), demo-input fidelity (on the 3–5 inputs the founder tested, the output matches what the founder would have written), and no visible failure (the system does not refuse on in-scope inputs and does not crash).
For a founder pitching a board at a fundraise, that is the only meaning that matters. The bug is that this meaning never survives the trip into engineering acceptance criteria — and the trip is silent. A worked diagnostic: ask the founder who has just used the phrase, “on which inputs, measured how, would you say it has stopped working?” If the answer is “I’d just know,” the spec is still in the founder’s head.
What the engineer hears
A competent AI engineer hears the opposite: “I have not thought about the eval threshold, the test set, the failure-mode budget, or the latency floor. I want you to make those decisions, but I will judge the result against an unstated bar and reject it without being able to tell you what would be right.”
A senior engineer will not say that out loud — saying it ends the engagement. They defer the question to discovery, write a scope that implicitly accepts their own private definition of “works,” or attach a clause reading “subject to engineering judgment.” All three produce the same artifact: acceptance is private to one party, and the other party can reject without a defensible reason.
This is the asymmetric-information problem underwriting the 2026 salvage market. The founder thinks they are buying a product. The engineer thinks they are buying time to figure out what product the founder will accept. The fix is for the founder to finish the sentence before they say it, with the threshold and test set already named.
The four unstated assumptions
When a founder says “just works” without an eval threshold attached, four assumptions get smuggled into the build. Each collapses on contact with production traffic.
Assumption 1 — Perfect input
The founder tested on inputs the founder typed. Real users type in caps lock, with typos, in mixed languages, with attachments the founder forgot to test, on mobile with autocorrect, and occasionally with prompts designed to break the system. Stack Overflow’s 2025 Developer Survey shows that even developers — the most input-disciplined population on the internet — produce inputs malformed enough that AI assistants fail visibly; only about a third report trusting the output. Rebuilding a test set that mirrors the real input distribution is ten times more expensive in week eight than week one.
Assumption 2 — Single user
The demo was tested by one user at unhurried pace on one browser tab. The product will be tested by hundreds of concurrent users, often during a launch spike. A model at $0.02 per query at single-user pace costs the same per query at peak — except there are 4,000 of them in a fifteen-minute window, and the founder discovers the unit-economics ceiling on a Product Hunt Sunday. Writing a load profile into the rubric in week one takes two hours; discovering it broken in week ten costs a re-architecture.
Assumption 3 — No edge cases
The founder’s mental demo runs on the modal input. Production runs on the long tail. McKinsey’s State of AI tracks the pilot-to-production gap as the dominant failure mode — over 78% of organizations report adoption, only a small fraction capture material value. Structurally, that is an edge-case-failure gap. Edge cases “just works” never specifies: the user whose name the tokenizer mangles; the PDF that is 40% scanned image; the conversation that exceeds the context window; the jurisdiction with a different ground truth than the team assumed. Anthropic’s Building Effective Agents makes the same point from the engineering side — the eval is the only artifact that catches the long tail before users do.
Assumption 4 — Infinite latency
When the founder tested, the founder waited. Users will not — they have a task to finish and ten tabs open, and they close the tab if the response takes longer than doing the task by hand. A reply-drafting assistant that produces a great draft in 14 seconds is a worse product than one producing an acceptable draft in 3 seconds. The right axis of the rubric is p95 (or p99) latency at production payload size, on the provider tier the team is paying for. None of that survives “just works.”
The eval-hour cost of catching them late
Each assumption has a catch cost — engineering hours to detect, specify, and remediate. The cost is asymmetric: catching in week one is an order of magnitude cheaper than catching in week eight. The table is a planning heuristic, but the ratio is roughly conserved across every team I have worked with.
| Assumption | Week 1 catch | Week 8 catch | Ratio |
|---|---|---|---|
| Perfect input | 2 hrs: transcribe real inbox into eval set | 20–30 hrs: collect logs, label, rerun priors | ~10x |
| Single user | 1 hr: write cost-per-query budget into rubric | 15–40 hrs: re-architect retry/throttle, rerun pricing | ~20x |
| No edge cases | 4 hrs: red-team session with 30 hard inputs | 60+ hrs: incident triage, customer comms, backfill | ~15x |
| Infinite latency | 1 hr: specify p95 latency tier | 10–25 hrs: profiler runs, prompt slimming, batching | ~15x |
A founder who spends a working day converting “just works” into four named eval thresholds saves on the order of 100–150 engineering hours over a 12-week MVP — at 2026 senior-engineer rates, a six-figure number. BCG’s AI at Work survey traces the same pattern at the org level: companies that define quality measurement before implementation capture materially more value.
The replacement phrasing
The fix is one sentence the founder uses every time they would have said “just works.” The shape:
“It passes the eval at threshold X on test set Y, on model M, at latency tier L, within failure-mode budget B.”
Concretely, for a customer-support reply assistant:
“It passes 85% of the 24-message eval, with zero factual contradictions, on Claude Opus 4.8 at temperature 0, at p95 latency under 4 seconds, with refund-vs-feedback miscalls under 1%.”
That sentence is ugly. It is also unambiguous. Every word does work:
- “Threshold X” — the quality bar as a number the founder will defend in writing.
- “Test set Y” — the specific inputs, drawn from the founder’s real workflow, not synthetic data.
- “Model M” — locks the model so a silent vendor change cannot move the goalposts.
- “Latency tier L” — moves latency into the rubric, not into a follow-up ticket.
- “Failure-mode budget B” — names the asymmetric errors that are not just wrong but actively expensive.
The sentence is the verbal short form of the eval rubric template every non-technical founder should ask for. Anyone on the team — founder, engineer, vendor, investor — should be able to ask “is it done?” and receive the same sentence from any of the others. Two different sentences means the team is building two products in parallel. For the founder-side method, see the quality-first scoping method for AI features.
A worked example — the same idea, both ways
Idea: an AI assistant for a 22-person B2B SaaS company that triages ~120 inbound sales emails per day into qualified-now, qualified-later, and not-qualified, and drafts a first-touch reply for qualified-now.
Scope A — “just works” (the trap)
“The assistant just works on inbound sales emails. It triages and drafts a reply. Quality should be production-ready. Acceptance: the founder approves a 2-week pilot.”
What this hides: no threshold; no test set; “production-ready” undefined; “founder approves” un-falsifiable.
Twelve weeks later, the team has shipped something that demos. It mis-classifies an email on the founder’s largest customer’s brother-in-law, and the draft hallucinates an SLA. The founder withholds approval. The contract becomes a renegotiation; the budget overruns; the assistant ships in week 18. Salvage cost on this pattern is 2–4x the original budget when there is a salvage team. Most of the time the assistant is quietly shelved.
Scope B — eval-anchored
Task 1 — Triage classification. Eval set: 60 sales emails from the last 90 days, hand-labeled by the founder. Threshold: 88% pass on three-bucket classification, on GPT-5, temperature 0. Failure-mode budget: qualified-now → not-qualified miscalls ≤ 2%; not-qualified → qualified-now miscalls ≤ 5%. Latency: p95 under 3 seconds.
Task 2 — First-touch reply drafting (suggestion mode). Eval set: 18 qualified-now emails with hand-graded reference drafts. Threshold: 70% pass on rubric (CRM-fact-grounded, no fabricated SLA, ≤120 words, brand-voice match), zero factual contradictions. Mode: suggestion only — every draft routes to a human-review queue. Latency: p95 under 6 seconds.
Out of scope: auto-send mode (factual-contradiction risk exceeds budget); multi-language drafting; calendar-link insertion.
Acceptance: Tasks 1 and 2 pass thresholds on a held-out 20% slice on three consecutive runs.
Twelve weeks later the team has shipped something that passes the eval — or has failed it by exactly how many points on which task. The founder either accepts or knows what is short and what it would cost to close. No salvage call.
Scope A had four sentences and no numbers. Scope B has two tasks, six numbers, two model names, two latency budgets, one explicit out-of-scope line. Founder-time to write Scope B: one afternoon — for 40–60% savings against the Scope A salvage path. For more on what gets cut, see the AI feature scope test — when to cut, when to ship.
Why the phrase persists despite costing so much
Three reasons, all structural.
It feels safe. Saying it lets the founder defer hard decisions to the team. Naming the threshold means committing to a number — and any committed number can be wrong. Wrong number feels worse to the founder than no number, even though the inverse is true on the build.
It mirrors how consumer AI is marketed. The major LLM labs pitch their assistants as if they just work. That language migrates into the founder’s mental model and from there into the scope. The marketing is the noise; the eval threshold is the signal.
Engineers reinforce it. A senior engineer can read between the lines, and the good ones do — but they charge for the risk-absorption. The average team cannot read between the lines, and the founder will not know which team they hired until week six.
The fix is cultural before it is technical. Retire the phrase. When it slips out, pause and ask the five questions: threshold, test set, model, latency, failure budget? Five minutes, five answers, one contract.
Frequently Asked Questions
What if my vendor uses “just works” in their pitch back to me? Treat it as a warning. The vendor is signaling they have not decided what to commit to. Ask the five questions: threshold, test set, model, latency, failure budget. The good vendors have answers; the rest say “we’ll figure that out in discovery.”
Is one afternoon of founder time worth it? Four hours of focused founder thinking typically saves 40–60% of the build budget against a “just works” scope. No other four-hour block has the same ROI.
What if I genuinely do not know what the threshold should be? Make the day-1 baseline the first deliverable. The team runs the candidate model on the eval set in week one, reports the baseline, and the founder sets the threshold from there.
Does this apply to internal tools, or only customer-facing products? Both, arguably more for internal tools. Internal users tolerate failure once or twice and route around the system permanently.
Can a small team afford the eval infrastructure? A test set is a spreadsheet. A rubric is a one-pager. A runner is a script. The 2026 tooling (promptfoo, OpenAI Evals, LangSmith, Inspect) lets one engineer stand up the harness in a day. For the engineering arc, see the eval-first build playbook.
What if my product surface is too small for a 24-input eval set? Then it is too small for a full eval contract — but the founder should still name the threshold and the inputs. Even a 6-input eval is a real eval.
Does this make scoping slower? It makes the scoping conversation longer by one afternoon. It makes the build dramatically faster.
How do I know if my current scope is in the trap? Read every acceptance sentence aloud. Ask: what is the number, the input set, and the model? Any sentence resisting those is “just works” in disguise. Common camouflage: “production-grade,” “high quality,” “enterprise-ready,” “reliable performance.”
Is the replacement sentence supposed to be ugly? Yes. A pitch deck can be elegant; a contract is ugly on purpose.
Closing
“The AI just works” sounds like a specification but functions as a deferred negotiation. Every week the phrase sits in scope, the price of replacing it goes up by an order of magnitude. Replace it once, in week one, with the threshold-test-set-model-latency-budget sentence — and the build becomes a series of verifiable milestones instead of disagreements.
If your current MVP scope contains the phrase, send it back today. Ask the team for the replacement sentence per task. If they cannot produce it, the project is not yet scoped.
Get the AI MVP scoping worksheet — a one-page template with the capability inventory, threshold table, latency tiers, failure-mode budget, and acceptance contract pre-formatted.
Dirk Jan van Veen, PhD
