Build App From Text Prompt: What Actually Happens Between Send and Render

Step 1: a sandbox is already waiting

The first thing that happens after you type a sentence is also the first thing that already happened, before you typed anything. When mk0r.com loaded, the React tree fired a fire-and-forget POST to /api/vm/prewarm. That route tops up a Firestore collection called vm_pool, keeping at least one fully booted E2B sandbox ready: Node, Vite, React, TypeScript, Tailwind v4, Chromium, and the Playwright MCP server are already running.

Pressing send runs a Firestore transaction that pops one of those entries and binds it to your session. The full latency from keystroke-to-claim is a single transaction plus an ACP re-initialize, not a five-second cold boot.

We wrote a deeper page about why the no-signup choice is what unlocks this parallelism: Instant AI App Builder. The short version: a builder that gates behind signup cannot warm sandboxes for anonymous visitors, so it pays a serial cold boot every time.

Step 2: the agent reads its system prompt

Inside the sandbox, the Claude agent is wrapped in the agent client protocol (the @agentclientprotocol/claude-agent-acp@0.25.0 package, pinned). Before your sentence arrives, the agent has already received a system prompt. There are two layers worth calling out, and both ship in the open source repo.

The short bootstrap prompt is in src/core/e2b.ts at line 148, exported as DEFAULT_APP_BUILDER_SYSTEM_PROMPT. It tells the agent the project layout, the dev server port, and that Playwright MCP is available for browser testing. It also instructs the agent to read its CLAUDE.md files for detailed workflow.

That CLAUDE.md is the second layer. The actual content is in src/core/vm-claude-md.ts as the globalClaudeMd export, around 320 lines of explicit rules. It covers the agent's role, a memory protocol (when to save user preferences, project context, and corrections), workflow rules, code-quality rules, copywriting rules, and a long block of design constraints.

That sentence is what makes the system prompt unusual. Most prompt-to-app services give their model a permissive instruction ("build a beautiful modern app") and ship whatever average-of-the-internet output comes out. The mk0r agent gets a specific list of things not to do, and a list of aesthetic directions to commit to before writing any code.

The five anti-slop rules baked into the system prompt

Every one of these is verbatim from globalClaudeMd. None of them are novel taste; the unusual part is that they are instructions to a code-generating agent, not a designer brief.

You can verify all five by cloning the repo and reading the file. The Design Constraints section starts around line 97. The Anti-Patterns block is around line 168.

What this changes about the output

A constrained system prompt does not guarantee a good app. It guarantees a different distribution of outputs. Toggle the panel below to see what each rule looks like in practice.

Step 3: files land on a real filesystem

The agent runs as a subprocess inside the same VM as the Vite dev server. There is no remote API translating between the agent and the project; the agent's Write and Edit tool calls hit the real filesystem at /app/src. Vite is already watching that directory. The moment a file changes, the dev server fires an HMR update over a websocket and your browser swaps the changed module in place. End-to-end from file write to repaint is on the order of tens of milliseconds.

This is why iterating feels different from re-prompting a chat model. When you say "make the buttons rounded", the agent reads the actual current contents of App.tsx on disk, not a stale transcription of its previous output. The change is one tool call against a live filesystem the next prompt can also see.

Step 4: the browser frame catches up

The same VM also runs Chromium with a Playwright MCP server attached. The browser is pointed at the dev server. There are two things that use this. First, you see what is happening: the preview frame on mk0r.com is a CDP screencast of the agent's tab. As HMR fires, you watch the layout change. Second, the agent uses it to verify its own work. After UI changes, the system prompt directs it to: navigate to localhost:5173, take a snapshot, check console messages for runtime errors, and not report completion until the browser shows the expected result.

We wrote about that self-test loop in more depth on the AI App Generator page. The relevant fact for this page is that it is part of the same session: the agent finishes the file edits and the browser check inside one prompt-to-response, not as a separate review step.

What "text prompt" can actually be

The input is a string, but it does not have to come from your keyboard. mk0r's landing page wires up a Web Speech API recorder that POSTs the audio to /api/transcribe. That route forwards to Deepgram's Nova-2 model with smart formatting and punctuation, returns a string, and feeds that string into the same prompt path as the keyboard does. Quick mode and VM mode both accept it.

So the practical answer to "build app from text prompt" is: type or speak. The first turn is one sentence. Iteration is also one sentence. The agent keeps the conversation, the file tree, and the browser state across turns.

The honest limits

The system prompt makes the output not look like AI slop. It does not make the output bug-free, and it does not turn a one-sentence description into a production app. A few real limits:

• State and persistence. The default project is client-side React. If your prompt implies real auth, a real database, or real payment, you are still going to need to plumb those in. The agent can do it (the system prompt has a Backend Services skill), but a one-sentence prompt will not.
• Native iOS or Android. The output is a web app. Mobile-first by default, but web. If you need an App Store binary, this is not the tool.
• Ambiguous prompts. The system prompt tells the agent to ask clarifying questions, but on the first turn the agent will usually guess and ask in the same reply. If you want it to ask first, say so.
• Complex multi-screen flows. A todo list, a landing page, a dashboard prototype: yes. A multi-screen real-time collaboration tool with presence and conflict resolution: not from one sentence.

The general shape: anything that fits in a Vite plus React app with a small amount of state and a clear UI is in range. Anything that needs serious backend logic is in range, but you will be iterating with the agent for more than one turn.

Why the system prompt being open source matters

Most prompt-to-app builders treat their system prompt as a moat. You ship a sentence, you get an app, you have no idea what the agent was told to do or not do. If you do not like the output, you re-prompt and hope.

mk0r's system prompt is in src/core/vm-claude-md.ts in the open source repo (github.com/m13v/appmaker). You can read it, fork the repo, change the rules, and run the result. If you want a builder that defaults to dark mode, swap the rule that forbids dark backgrounds. If you want it to favor Material UI instead of plain Tailwind, swap the styling section. The output distribution shifts in a way you can predict.

That is not a moat, but it is a different bet: the system prompt and the surrounding sandbox are infrastructure, the model picks choices the system prompt narrows, and the user gets to inspect both layers. Every other prompt-to-app guide on this topic skips this entirely, which is why this page exists.