AI builds apps that skip the middle

The middle is real, and it is specific

When a Reddit thread says "AI built me an app and it skipped the middle," that is not a feeling. It is a measurement. The middle is a list of concrete steps every AI app builder has to deal with somehow, and the choice each one makes is whether to do them at request time or before the user arrives.

Here is the version that runs on most tools that ask for a login first. Every step is a wait or a context switch. Most ideas do not survive seven of them in a row.

That figure is the part nobody puts on a landing page, because nobody wants to admit it is there. The interesting question is what each step looks like when you decide it has to run before the user clicks anything.

The single sentence that pins the stack

On mk0r the framework decision is one constant in one file. src/core/e2b.ts, lines 170 through 171. The variable is DEFAULT_APP_BUILDER_SYSTEM_PROMPT.

export const DEFAULT_APP_BUILDER_SYSTEM_PROMPT =
  "You are an expert app builder inside an E2B sandbox " +
  "with a Vite + React + TypeScript + Tailwind CSS v4 " +
  "project at /app. The dev server is running on port " +
  "5173 with HMR. You have Playwright MCP for browser " +
  "testing. Read your CLAUDE.md files for detailed " +
  "workflow, coding standards, and memory instructions.";

That sentence is doing real work. It is telling the model the framework, the language, the bundler, the styling, the port, the hot reload, and the test runner. The model never picks a stack, never types npm create, never waits for a dependency tree. It opens /app/src/App.tsx, reads the CLAUDE.md sitting next to it, and writes the part of the project that depends on what the user actually asked for.

Removing the framework decision from the request path is the single highest leverage move. Every other middle step fans out from this one.

What the image already contains

The image lives at docker/e2b/e2b.Dockerfile. It is a thin wrapper over a few static COPYs and one meaningful build step:

WORKDIR /app
RUN npm create vite@latest . -- --template react-ts \
 && npm install \
 && npm install -D tailwindcss @tailwindcss/vite

Read that twice. By the time the image is published, the following things already exist on disk inside the box: package.json, node_modules/, the Vite config, the React entry point, Tailwind, and the custom HMR bridge file src/_mk0rBridge.ts that posts message events to the parent iframe so the preview can listen for vite:beforeUpdate, vite:afterUpdate, and reload events.

The image also globally installs three things every agent needs: @playwright/mcp for browser testing, @agentclientprotocol/claude-agent-acp for the agent bridge, and @anthropic-ai/claude-code. Plus Chromium, ffmpeg, Xvfb, x11vnc, and websockify so the box can stream a real browser back to the user. None of that runs at the user's prompt time. All of it is sediment.

The dev server starts the moment the sandbox boots, not the moment the agent decides it should exist. By the time the first prompt lands, port 5173 is already serving an empty React app, the iframe has already loaded it, and the bridge is already posting messages back.

The pool that boots before you do

An image alone does not skip the middle. A sandbox still has to boot, ACP still has to initialize, and the session still has to register. That stack of operations takes about ten to thirty seconds. If you wait until the user submits their prompt, the user feels every second of it. So mk0r does not wait.

The landing page fires this on mount, in src/app/(landing)/page.tsx around line 63:

useEffect(() => {
  fetch("/api/vm/prewarm", { method: "POST" }).catch(() => {});
}, []);

That fire-and-forget POST hits a route that calls prewarmSession() in src/core/e2b.ts. The function boots a sandbox from the template, runs the ACP initialize, runs session/new with the same hardcoded system prompt, sets the model to haiku, and writes a "ready" document into the vm_pool collection in Firestore. The entire stack of setup runs while the user is reading the textarea.

When the user finally clicks submit, the request runs a Firestore transaction inside claimPrewarmedSession that atomically deletes one ready document and hands its metadata back to the request. The user's session is now bound to a sandbox that has been alive long enough that the dev server's first paint is already in the iframe.

The four services that do not need a signup form either

Stack and server are the obvious middle. Services are the one almost nobody talks about. If your app needs a database, an analytics key, a transactional email sender, or a git repo, you usually need four separate accounts on four different platforms. mk0r treats all four as middle and provisions them in parallel from src/core/service-provisioning.ts:

The function that runs the four calls is provisionServices() around line 277. It reads:

const results = await Promise.allSettled([
  provisionResend(sessionKey, name),
  provisionNeon(sessionKey, name),
  provisionGitHub(sessionKey, name),
]);

PostHog is synchronous because it reuses a shared project and just mints an app id. The other three are real network calls to real APIs that create a real audience, a real Postgres database, and a real GitHub repo. The agent does not orchestrate them. The orchestrator runs them while the first model turn is still in flight, then writes the resulting env vars to /app/.env so the agent can read them with process.env the moment it actually needs persistence.

What the model is left with

Once you remove the middle, the agent's job collapses to a much smaller surface. It does not pick a framework. It does not boot a server. It does not install packages (except the few specific to the user's idea). It does not wire HMR. It does not create a database, an email sender, an analytics key, or a repo. It does not run the first git commit, that is done in ensureSessionRepo around line 670 of e2b.ts the moment a session is bound.

What it does is open /app/src/App.tsx and the small set of component files in /app/src/components, read the CLAUDE.md that lives next to them (which lists the env vars that exist and the conventions of the project), and write the part that is unique to the user's description. Then it watches its own work in the iframe via the bridge messages and iterates.

That is the spec for "skips the middle." Not fewer keystrokes from the user, fewer keystrokes from the model. The model is a faster typist than any human, but it is still being charged per token, and every token it spends re-deriving the framework decision is a token it does not spend on the user's actual idea.

The honest cost of skipping the middle

Pre-baking the middle is opinionated. If your idea is a SwiftUI iOS app, mk0r is the wrong tool. If you want SvelteKit, wrong tool. If you need a Laravel backend, wrong tool. The whole point of pinning the framework in a constant in a single file is that the constant is sharp. You cannot have a fast first hour and a flexible framework at the same time, and the design picked the first hour.

The other admission: nothing about the pre-baked middle helps the second hour. Once your prototype is past the point where the agent can keep the whole thing in its head (a few hundred lines, a handful of components), you start hitting state management, real auth, multi-screen navigation, the dozens of small architectural choices that are the actual skill of building an app. mk0r's opinion is that those steps belong in a real engineering process, not in a chat textarea, and the moment you reach them you should be exporting your code to a real repository and continuing in a real editor.

The contract is honest in both directions. The first hour is genuinely faster, by minutes. The second hour is not cheaper than anywhere else. Skipping the middle is a tool for ideas that need to exist quickly so their owner can decide whether to invest more, not for projects that already know they want to ship.