Their Own Team Says It's for Prototyping. Yours Is in Production
The quiet part, said out loud in a comment thread
On July 30, a YC S26 company called Prized launched on Hacker News with a clean pitch: let non-engineer staff build secure internal tools. Seventy-three points, fifty-three comments. A good day.
Buried in that thread was a line worth more than the launch itself. A builder relaying a vendor conversation wrote that "Lovable is used primarily for prototyping, not internal tools" — not a competitor's jab, but a paraphrase of what the vendor's own team had told him.
Read that again, because it reframes the entire category. The prototype/product distinction isn't a talking point invented by people selling process. It's the vendors' own internal understanding of what their tool is for. They know. They say it out loud in sales conversations.
The problem is that nobody says it in the marketing. So founders ship the prototype and call it a product.
You cannot bolt safety onto something that never stated its scope
Here is what makes the Prized launch genuinely interesting: it exists because of the gap. An entire YC-funded company, with real architecture behind it — scoped session tokens, per-tool Postgres roles, an egress proxy, an LLM "judge" reviewing connector calls — built to sit downstream of tools that produce working software without a definition of what that software is allowed to do.
The thread went straight at the weak joint. One commenter described the judge as "a probabilistic control sitting where a capability grant belongs." Another made the same point plainly: LLMs are probabilistic, not deterministic, and are built to make a best guess.
Both critiques are correct, and both stop one step short of the real diagnosis. The judge is probabilistic because the thing it is judging against was never written down. An LLM reviewer has to guess at intent for the simple reason that intent only ever existed in someone's head.
This is the shape of the problem in every vibe-coded internal tool I've seen reach production. The code exists. The behavior exists. The permission model exists — implicitly, accidentally, as whatever the generated code happens to be able to reach. What doesn't exist is any artifact that says: this tool touches customer records and nothing else. This tool never writes to payroll. This tool reads from Stripe and cannot refund.
You can't audit against a document that was never written. So you hire a model to infer it, and now your access control is a vibe too.
A spec is not documentation. It's a permission boundary.
Codalio's wedge is that vibe coding ships prototypes and spec-driven work ships products. The Prized thread is the clearest illustration of the mechanism I've come across, because it shows what the missing artifact actually costs — not in code quality, but in control.
A spec's job isn't to describe what the software does after it's built. That's documentation, and it's worth very little. A spec's job is to state, before anything is generated, the boundaries a reviewer can be dumb about. Deterministic checks don't need judgment. They need a written rule to check against.
That's the reframe worth taking away: you don't need a smarter reviewer. You need a stated scope that makes the reviewer's job trivial.
For an internal tool, a spec that does real work states at minimum:
-
The data it touches — which systems, which tables, which fields, named explicitly rather than "the customer database."
-
The actions it can take — read, write, delete, trigger, enumerated one by one, with everything unlisted defaulting to denied.
-
Who operates it — which roles, and what changes about its permissions when the role changes.
-
What it must never do — the explicit negative space, which is the part almost nobody writes and the part every incident report eventually references.
-
How it fails — what happens on an ambiguous input, because "the model decides" is an answer that will be tested in production whether you wrote it down or not.
None of this requires engineering skill. All of it requires making a decision before a tool makes it for you. That's why this is a founder problem, not a developer problem — every item on that list is a business decision wearing technical clothing.
What to do Monday, if something you vibe-coded is already live
Start with inventory, not rewriting. Pull up every internal tool your team built without an engineer in the loop — the ops dashboard, the onboarding form, the thing that pulls from your CRM. List them. Most teams are surprised by the count.
For each one, write four lines: what data it reads, what it can write, who uses it, and what it must never touch. Four lines. If you can't finish them for a given tool, you've just found the one that needs attention first — the inability to state the boundary is the finding.
Then compare what you wrote to what the tool can actually reach. The gap between the two is your real risk surface, and it's almost always larger than expected, because generated code reaches for whatever credentials were nearby when it was generated.
Only then decide what to do: tighten, rebuild, or retire. Some tools genuinely are prototypes and should be labeled as such and left alone. The failure mode isn't using a fast tool. It's letting a prototype quietly get promoted to production without anyone signing off on the promotion.
Write the boundary before you generate the code
Codalio's spec-driven workflow exists for exactly this moment — turning the business logic a founder already knows into a written, checkable definition of what the software is allowed to do, before a single line gets generated.
You'll come out with a written scope you can hand to any engineer, any auditor, or any reviewer — probabilistic or otherwise.
References
-
Launch HN: Prized (YC S26), July 30 — Hacker News discussion thread
-
Prized (prized.dev)