'Just export it' is the most expensive advice in vibe-coding

"Just export the code when you outgrow it." It is the most repeated reassurance in vibe-coding, and it is 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 weeks of your AI agent guessing.

The export button works. The export is the problem.

Export hands you bytes, not a codebaseCopy Anchor Link

A code export is a snapshot. You get the files as they existed at the instant you clicked the button — and nothing else. This is not speculation about a missing feature: Lovable's own documentation describes the handoff as producing "a codebase that can be synced to GitHub or GitLab with Git sync." Synced files. A snapshot of files is exactly what arrives — and a snapshot is where the trouble starts.

What you do not 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 are about to open it in.

This is fine if you are 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 filesCopy Anchor Link

Here is 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. Anthropic's own best-practice guide for Claude Code explains the mechanism: the context window is the scarcest resource, performance degrades as it fills with undifferentiated files, and the guide's central advice is to give the agent verifiable checks — tests, builds, linters — instead of judgment calls. An export is the opposite of that setup: maximum undifferentiated files, zero checks, and every structural decision left as a judgment call.

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 did not end the regeneration tax. It moved it into your repo and made it permanent.

If you want the full treatment of what makes a repo legible to an agent — layout, naming, docs placement — read our agent-readable repository structure guide. It is the companion piece to this argument.

The regeneration tax follows the code homeCopy Anchor Link

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 does not. It changes the currency.

Now you pay in agent confusion. The model burns context re-reading inconsistent files to figure out what is 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 cannot read.

Make the repo legible before you leave the sandboxCopy Anchor Link

If an export is unavoidable, there is a way to cut the tax dramatically: author the missing layer yourself, before the agent touches the code. This is a weekend of human judgment that pays back on every prompt afterward.

First, write the CLAUDE.md (and mirror it in .cursorrules): the stack, the canonical paths for features, screens, and state, and the non-obvious rules like "never add a dependency without removing the old one." Our Cursor rules for Next.js guide shows exactly what that file should contain. Second, pick one feature pattern and retrofit the exported screens to it — one way to add an entity, one way to add a screen — so "do it again for X" becomes a copy instead of an invention. Third, consolidate the design surface: one Button, one Card, one Form, shared everywhere, which is why a design system doubles as agent context. None of this is glamorous. All of it is the difference between an agent that extends and an agent that invents.

Ownership your agent can build on is a different thingCopy Anchor Link

"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 does not 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 task 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 does not 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 itCopy Anchor Link

Take any vibe-coded app you are 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 kits beat 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, 20+ task 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 is the conventions — and a snapshot cannot snapshot something that was never written down.

Start from a repo, not a snapshotCopy Anchor Link

If you have not exported yet, skip the migration entirely: start from a repository that already has the conventions layer. Browse the OTF templates — every one ships with the CLAUDE.md, prompt library, and deploy scripts this post argues for, so your agent extends from day one instead of guessing from day one.

SourcesCopy Anchor Link

• Anthropic, Best practices for Claude Code — context-window management, verifiable checks, and convention-driven agent behavior; confirms agents need structure, not just files.
• Lovable, Welcome to Lovable — confirms sandbox-to-GitHub handoff produces synced files (the snapshot this post critiques).

Originally published at otf-kit.dev — full-stack kits your AI coding agent can actually ship to production. See the kits →