"Just export the code when you outgrow it." It's the most repeated reassurance in vibe-coding, and it's the one that costs the most.

The pitch makes sense on paper. You build your MVP in a sandbox — Lovable, Bolt, v0 — and the moment it gets too big for the sandbox, you hit the export button, drop the code into your own repo, and carry on with Cursor or Claude Code. No lock-in. The code is yours.

Then you actually do it, and the weekend you budgeted for "carry on" becomes three weeks of your AI agent guessing.

The export button works. The export is the problem.

Export hands you bytes, not a codebase

A code export is a snapshot. You get the files as they existed at the instant you clicked the button — and nothing else.

What you don't get:

• Git history. No commits, no "why did this change", no bisect. The repo starts at one giant initial commit.
• Conventions. Why is auth in lib/auth.ts here and utils/session.ts there? Nobody decided. The generator drifted across sessions.
• A dependency story. The sandbox pinned versions you never chose, mixed three state libraries because three prompts each reached for a different one, and left dead code from features you asked it to remove.
• Any context for the next tool. The export knows nothing about the IDE you're about to open it in.

This is fine if you're going to read every line yourself. Nobody using a vibe-coding tool is going to read every line themselves. That was the whole point.

Your agent reads conventions, not just files

Here's the part the "just export it" advice misses entirely: a file-system agent — Cursor, Claude Code, Codex — is only as good as the conventions it can infer.

Give Claude Code a repo with a clear structure, a CLAUDE.md, and a consistent pattern for how a feature is built, and it extends that pattern. Give it an export, and it does what it always does with ambiguity: it invents.

You: add a settings page with the same layout as the dashboard

Agent (on a clean repo): reads app/dashboard/page.tsx, copies the
  AppShell + Section pattern, matches the existing route convention,
  reuses the Card primitive. One file, done.

Agent (on an export): can't find "the pattern" because there isn't one.
  Invents a new layout. Imports a Card from a path that half the app
  doesn't use. Adds a third state library because it couldn't tell
  which of the two existing ones was canonical.

Every inconsistency in the exported code becomes a fork in the road the agent has to guess at — and it guesses on every prompt, forever. The export didn't end the regeneration tax. It moved it into your repo and made it permanent.

The regeneration tax follows the code home

In the sandbox, you paid the tax in credits: every session re-derived the auth flow, and you paid tokens for it. People assume exporting ends that.

It doesn't. It changes the currency.

Now you pay in agent confusion. The model burns context re-reading inconsistent files to figure out what's canonical. It ships code that matches one half of the app and breaks the other. You spend your review time being a human linter for conventions that were never written down.

A subscription you cancelled still bills you — in the time your agent wastes on a codebase it can't read.

Ownership your agent can build on is a different thing

"You own the code" and "your agent can extend the code" are not the same claim. The first is about a license. The second is about structure.

For a file-system agent to actually accelerate you, the repo needs the things an export structurally cannot contain:

• A CLAUDE.md (and .cursorrules) that states the stack, the conventions, and the non-obvious rules — so the agent doesn't infer them wrong.
• A consistent feature pattern — one way to add an entity, one way to add a screen — so "do it again for X" is a copy, not an invention.
• A prompt library (ai/prompts/) — the tested prompts that already know how this codebase wants a feature built.
• Deploy scripts that encode the project-specific dance (env sourcing, build, ship) so the agent doesn't reinvent it and break it.

None of that survives a snapshot, because none of it was ever there. It has to be authored — by a human who decided what the conventions are.

The test that settles it

Take any vibe-coded app you're thinking of exporting. Export it. Open it in Cursor. Type one prompt:

add a billing page that matches the rest of the app

If the agent ships something consistent in one shot, you had a real codebase — keep it. If it invents a new layout, imports from a path nothing else uses, and you spend the afternoon reconciling it, the export gave you bytes, not a foundation. And every feature after this one costs the same afternoon.

That test is why we ship kits as repos, not exports. Every OTF kit is full-stack code you own outright, but the part that matters is everything around the code: a CLAUDE.md your agent reads first, a .cursorrules that mirrors it, 40+ tested prompts in ai/prompts/, one consistent way to add a feature, and the deploy scripts that get it to a real domain or the App Store. You buy it once. Your agent reads it the way it reads code it wrote itself.

"Just export it" assumes the hard part was getting the bytes out. The hard part was never the bytes. It's the conventions — and a snapshot can't snapshot something that was never written down.