15 Jun 2026
Over the last few weeks, I’ve been working out how to put a growing fleet of vibe-coded prototypes in front of real users without losing sleep.
In a previous post I wrote about sandboxing AI coding agents. This is the sequel: sandboxing what they build. AI enables us to go from idea to working prototype at an unprecedented pace - sometimes in just a few days. Some of that code is carefully reviewed. Some of it is, frankly, just prompted into existence. Both are valuable. They should not be treated the same, though.
My answer is to stratify prototypes by danger. At the centre sits the core: fully code-reviewed, production-ready, and the only thing allowed to touch sensitive data like logins and passwords. Around it sit lightly reviewed prototypes that I am reasonably confident won't leak anything. And at the outer edge live the pure proof of concepts - hours of prompting, shipped to learn fast.
The trick is reconciling isolation with convenience. The core exposes one simple API. It tells each prototype who the user is (their ID), whether they're logged in, and which prototypes they may access. Nothing more.
Everything else runs in its own little silo: a separate environment, on a cookie-isolated subdomain, in its own frame, with its own strictly budgeted API keys. A prototype cannot see the core, the data, or its siblings. If the wildest experiment misbehaves, the worst it can leak is a user ID.
The user, meanwhile, notices none of this. They log in once, see only the prototypes they're permitted to, and browse everything in one integrated UI. Seamless on the surface, siloed underneath.
The reward is focus retention. Review is a scarce resource, so the wider team and I focus it where a mistake would actually hurt. The core earns deep scrutiny. The outer experiments earn a glance. Nothing waits for a review it doesn't need.
And the timing is good: Anthropic have just released Claude Fable 5, their newest model. More prototypes incoming. We'd better have somewhere safe to put them.
Author: Petr Klus
