Since 2025 I've been the lead engineer on a platform where someone types "build me a page for my shop" into a chat window, and an agent writes the code, runs it in a sandbox, and hands back a live, working app, without ever showing the person a line of code. This is a look at what it actually takes to make that trustworthy in production. The client is private; the engineering is describable without them.
Getting a model to write a webpage is a weekend project. Getting it to do that for many people at once, safely, without a surprise bill, in a way that survives the model handing back nonsense, is a year of work. The platform sits at the infrastructure layer: it owns where the artifacts live, how they run, who owns what, and how every model call is routed, priced, and checked.
A person describes what they want. The agent plans it, writes the files, installs what it needs, runs the result in an isolated cloud sandbox, and returns a live preview embedded right in the conversation, updating itself as it goes. If it needs a real photo it can't source, it stops and asks rather than faking one. If it hits a question only the user can answer, it pauses and waits.
These are the same seven questions I ask of anyone's build, answered for a system that runs for strangers, at scale, on someone else's money.
A cheap model tiers every job first; the expensive one is only reachable by an explicit, reasoned escalation after the cheaper attempts fail. Before each call, a gate estimates the full request size and refuses locally rather than sending something oversized. Every turn is logged with its token count, its cost, and which user it was for.
Anything the model didn't write itself, scraped pages, error logs, uploaded files, gets wrapped and escaped so it can't be read as an instruction. Files the agent downloads are checked for private-network tricks and disguised executables before they ever land somewhere the app can serve them.
Each app runs in its own isolated cloud sandbox, reached only through the platform, so a user never touches a raw machine. The database and file store are the source of truth; the sandbox is a rebuildable copy, so nothing important lives only in a place that can vanish.
Building a real app takes minutes, which is longer than a single request is meant to last. The work runs in the background against a durable record that survives restarts, so a build can pause for a question and pick up exactly where it left off.
Every request carries who it's for. Ownership of each artifact is enforced per user, and organisation identity is derived per request and never stored, so one customer's work and data stay their own.
Infrastructure is defined in code and stood up reproducibly. Every change is type-checked and tested, then deployed on merge with no long-lived credentials. The move from the first quick host onto real cloud infrastructure was done with the data verified on both sides.
The instructions the agent follows are written the way I've written for people for twenty years: for a specific reader, with its failure modes in mind. There isn't one instruction document, there are three, pitched at three different readers: one for the person in the chat, in plain language; one for a generic tool client; and one for the agent itself, structured as laws, then reference, then workflows, then a reinforcement pass placed right before it acts, because a long-context model drifts and needs to be reminded of the rules at the last moment.
Each tool's description is written as guidance, not an API reference, resolving the ambiguities that would otherwise surface as a confused user. The rule against faking a missing photo is stated three separate times, in three places, because it's a plausible thing for a model to do by default and stating it once isn't enough. That's information architecture and progressive disclosure. The reader just happens to be a language model.
It's solo-built, so branch protection is light and the test coverage is deliberately weighted toward the security-critical paths rather than spread evenly across everything. Some session state lives in memory, which is a real ceiling on scale that I've documented rather than hidden, and a known next piece of work. I keep a dated maintainability note in the repo that names the oversized functions and the shortcuts, because the useful version of "it works" is the one that also says where it doesn't.
I mention this because it's the same thing I'd do for you: tell you what's solid and what will bite you, in plain terms, before it does.
Knowing where the sharp edge is, and labelling it, is the expertise. Not pretending there isn't one.
If your prototype works and the questions above are starting to feel real, that's exactly the moment I'm useful. Send me what you've built.