Build, Buy, or Vibe-Code? · For engineers

The prototype cliff: AI fills the last 30% with guesses

We asked an AI for the same clinic booking API twice. The "production-ready" one closed weekends and capped patients at three bookings. Nobody asked it to.

By Agentum R&D · 4 min read
Published Oct 26, 2026 · Updated Oct 26, 2026

Short answer The last 30% of an AI-built app is mostly decisions: opening days, time zone, limits, roles. Asked for "production-ready", an AI model made those decisions itself, with plausible defaults nobody requested. Decide them before the first prompt, confirm every default, and test each rule.

Lovable, the vibe-coding platform, says it now hosts 60 million projects^{Source 1}. Most will stay prototypes, and that is fine. The ones that get real users hit what Addy Osmani called the 70% problem: AI gets you most of the way fast, and "the final 30% - the part that makes software production-ready, maintainable, and robust - still requires real engineering knowledge"^{Source 2}.

We wanted to see what that last 30% looks like today, so we asked an AI model for the same small app twice: once plainly, once "production-ready". Both versions handled the engineering basics. The production-ready one also decided when the clinic is open, how far ahead patients may book and how many appointments each may hold. Nobody had asked it to.

The app is a booking API for a dental clinic with one dentist and 30-minute slots from 9:00 to 17:00: patients book, list and cancel. Both prompts asked for Node.js 24, Express and the built-in SQLite module, in one file. The second added one sentence: "Real patients will use it from next week, so make it production-ready." We ran Claude Sonnet 5.5 once per prompt through Claude Code from an empty folder, with all hooks and our coding-style plugin switched off and no shell, file or web tools, so it could not run its own code. Then we used each version as one patient would, on Node 24.21 with Express 5.2.1.

Rows 6 to 9 are decisions about the clinic that the prompt never made. The model chose Monday to Friday, a 90-day booking window, three upcoming appointments per patient and UTC as the default clock. To its credit, it put each one at the top of the file: opening days and time zone as environment settings, the 90 days and the three as commented constants. Each is a reasonable guess, and each can be wrong. A clinic open on Saturday mornings loses those bookings. A patient with a six-visit treatment plan can book only three, and one who loses the one-time token cannot book online again with that phone number; the error says to call the clinic. A clinic in Chicago that never sets the time zone checks "already passed" against UTC: at 10:00 in Chicago the server reads 15:00, so an 11:00 slot that day is refused as already passed.

The plain version made none of the first three decisions, so it accepts a Sunday booking for 2027. It also uses the server's clock without saying so, which gives a Chicago clinic on a UTC server the same problem. That is the prototype cliff as it looks in our test: the missing 30% is less about missing code and more about missing decisions. In our run, asking for "production-ready" was enough for the model to fill them in with plausible defaults. Osmani listed this among the parts that still need people: "understanding requirements, designing maintainable systems, handling edge cases, ensuring security and performance"^{Source 2}.

Plausible defaults are hard to spot, because they look right. In Stack Overflow's 2025 survey, the top frustration with AI tools, cited by 66% of developers, was solutions that are "almost right, but not quite", and 45% said debugging AI-generated code takes more time^{Source 3}. A Monday-to-Friday clinic is almost right for most clinics. Google's 2025 DORA report makes a related point: AI "becomes most useful when it's pointed at a clear problem"^{Source 4}.

The cheapest moment to close the gap is before the first prompt. For any app that will have real users, answer these in writing and paste the answers into the prompt:

1. Who uses it, in which roles? Patients, front desk, dentist, owner. What does each one see and do?
2. When and where? Opening days, holidays, time zone, and how far ahead people may book.
3. What are the limits? Bookings per person, cancellation cut-off, what happens on a no-show.
4. How sure must you be about who someone is? A phone number, a code sent by SMS, a login.
5. What must never be lost, and how would you restore it? Backups you have restored at least once.
6. Who can see what? Write it as a table and test it; the Lovable incident shows what happens when that table lives only in someone's head.

If the code already exists, read the top of each file the AI wrote and list every constant and default it chose. Confirm each one with whoever runs the business, then write one test per rule. For an owner deciding whether to build at all, our cost comparison of vibe-coding, hiring and buying puts numbers on the same gap.

1. 1Roles and what each one sees are written down
2. 2Opening days, booking window and limits are decided, not defaulted
3. 3The clinic time zone is set on the server
4. 4Every default the AI chose has been confirmed by the business
5. 5Each rule has a test

Sources

1. Lovable confirms new $13.3B valuation, raises another $400M (TechCrunch, Aug 12, 2026). Retrieved Oct 2026. ↩
2. The 70% problem: Hard truths about AI-assisted coding (Addy Osmani, Dec 4, 2024). Retrieved Oct 2026. ↩ ↩
3. AI, 2025 Developer Survey (Stack Overflow). Retrieved Oct 2026. ↩
4. Announcing the 2025 DORA Report (Google Cloud, Sep 24, 2025). Retrieved Oct 2026. ↩

Published Oct 26, 2026 · Updated Oct 26, 2026Report an error (support@agentum.cloud)