What is vibe coding

The plain definition

Vibe coding is building software by describing intent to an AI assistant and accepting the code it produces, without hand-writing or fully reviewing that code yourself. You say what you want, it appears, you try it, you say what is wrong, and it changes. The name comes from steering by vibe: you are going on whether the result feels right, not on reading the implementation line by line.

The term was popularized in early 2025 by Andrej Karpathy, and it describes something real that had just become possible. A person with an idea and no programming background can now produce a working website or app in an afternoon. That is not a small thing. It is the largest drop in the cost of making software in a generation.

It helps to separate two things that get blurred together. There is vibe coding as a mode of building, fast and loose on purpose, and there is AI-assisted development, where a professional uses the same models but reviews, tests, and owns the result. The first is a way to start. The second is a way to ship. Confusing them is where the trouble begins.

Where it genuinely shines

Vibe coding is not a lesser way to work. In the right situations it is simply the right way, and it beats the old approach outright.

• Prototypes and demos. You have an idea and you want to see it running before you spend money proving it. An afternoon beats a month.
• Personal tools. A script to rename your files, a page to track something only you care about. If the only user is you, the bar is yours to set.
• Learning by doing. Watching a model build something is a fast way to learn what the pieces are called and how they fit, even if you do not yet write the code.
• Getting unstuck. When you know what you want but not how to say it in code, describing it and reading the result is a legitimate way forward.
• Marketing and content sites. A clean site that says who you are and how to reach you is mostly presentation, and models are very good at presentation.

Where it quietly breaks

The danger is not that vibe-coded software is bad. It is that it looks finished before it is. A generated app runs, looks polished, and passes the one path you tried by hand. The failures live in the paths you did not try, and they stay invisible until a real user, or a real attacker, finds them.

The patterns are consistent enough to name:

• It handles the happy path and assumes the rest. A form that works with normal input may throw on empty input, on a very long string, or on a value it never expected.
• Secrets end up in the code. A key pasted into a file to make something work is a key that ships to the browser and into your git history.
• Nobody owns it. There is no spec, no tests, and no notes. The first person who has to change it, including you in six months, has to reverse-engineer it from scratch.
• It is invisible to search. A generated single-page app often ships no real HTML, so search engines and AI answer engines see an empty page.
• It is unusable for some people. Missing labels, unreadable contrast, and keyboard traps are common, and they are real barriers, not nitpicks.
• It is only half yours. Built inside a closed platform, the app depends on that platform. If the terms change, the price rises, or the company folds, the app goes with it.

The part people miss: lock-in

The most expensive problem with vibe coding is not a bug. It is ownership. Many of the platforms that make vibe coding easy keep the application in their own environment, in their own format, running on their own servers. That is fine until it is not.

The risk is easy to underestimate because it is invisible while everything works. You find out you do not own your app the day the platform changes its pricing, pivots its product, or shuts down, and by then the app is the thing running your business. The code you cannot export is the code you do not own.

This is the problem we built Migrare for. It detects the lock-in signals in a project built on Lovable, Bolt, Replit, or v0, and applies automated transforms to extract a clean codebase you can run anywhere. The point is not to avoid these platforms. It is to make sure that when you outgrow one, leaving is a decision rather than a crisis.

A sane workflow: start fast, land it somewhere you own

You do not have to choose between speed and solidity. The trick is to let each one do the job it is good at, and to be deliberate about the handoff between them.

A workflow we actually use looks like this:

• Start from a real repository, not a locked platform. Our forge stamps a working starter repo from a few brand details, so day one is already code you own, on infrastructure you control.
• Put it on GitHub from the start. A repository is the thing that makes your work portable. If the code lives in a git repo you control, it can move to any host, any platform, and any future you. If it lives only inside a product, it cannot.
• Build with the agent in the loop. Describe what you want, let it generate, and keep going. This is the fast part and it should feel fast.
• Keep the guardrails on as you go, not at the end. Prerender for search, adversarial tests for the handlers, a visual memory for the layout, and accessibility checks. They catch the gaps generation leaves while the change is still small.
• Hand off the hard parts. The data model, the security surface, and the failure paths are where a human review pays for itself. Do them once, properly, before real users and real data arrive.
• Own the exit. Everything lives in your accounts and your repo, so the platform you built with is a tool you used, not a place you are stuck.

What to do with the forge tgz

If you stamp a starter from our forge, you get a tar.gz file, a real repository with a working site and a git history that starts the day you made it. The most useful thing you can do with it is hand it straight to your agent.

Here is the short version. Unpack it with the command tar -xzf, or skip the command line entirely and give the archive to your agent, then say something like: "This is my new project. Unpack it, read the readme, install dependencies, and run it. Then build out the homepage from this description." An agent that can read the files, run the commands, and make changes will take it from there, which is exactly the workflow this guide describes.

Then push it to a repository you own. The readme inside carries the specifics, including how to get it onto GitHub. The point is that you start from a repository that is already yours, so nothing you build on top of it is trapped in a platform you cannot leave.