Vibe coding

In short

• Vibe coding means prompting an AI to write software and accepting the code without reviewing it.
• It is a quick way to build prototypes, personal tools, and experiments you plan to throw away.
• It breaks down in production, where security, data, and upkeep depend on someone understanding the code.
• The same tools used with engineering review become AI-assisted development.

Also called: Vibecoding, Vibe-coded apps, Coding by prompt.

What vibe coding is

Andrej Karpathy, an AI researcher and one of the founding members of OpenAI, coined the phrase in a post in February 2025. He described talking to an AI coding tool, accepting whatever it changed, pasting error messages back in when something broke, and mostly ignoring the code itself. He described it as good enough for throwaway weekend projects.

The term spread quickly and is now used loosely for almost any AI-built software. In its original sense the defining feature is that nobody reads the code. Describing an app to a builder tool and launching what comes out is vibe coding. An engineer who uses the same tool and reviews every change is doing something else. That line matters to Choie, where generated code that nobody understands is not merged.

How it works in practice

The loop skips the slow parts of engineering, such as planning the structure, reading each change, and writing tests. For a small app, that can produce something usable in an afternoon. Tools that generate whole apps from a prompt have put this within reach of people who have never written code.

Where vibe coding works

• Prototypes. A working version of an idea to show users or investors, where the goal is learning and the code will be replaced. A prototype is meant to be thrown away.
• Personal tools. A script that renames files, a dashboard for your own data, a small app only you use.
• Experiments. Checking whether an API does what you hoped, or trying an interaction before committing to it.
• Learning. Seeing a working example can show a non-engineer how the parts of an app fit together.

What these cases share is low stakes. Few people use the result, it holds little sensitive data, and nobody has to maintain it for long.

Where it fails

The trouble starts when vibe-coded software gets real users, real data, or a second developer.

• Security. Generated code can leave data exposed, keys in the wrong place, or access rules missing. Nobody notices, because nobody read it.
• Edge cases. The happy path works in a demo. Payments, time zones, bad input, and slow networks are where unread code breaks.
• Maintenance. When nobody understands the structure, each fix risks breaking something else, and the AI may rewrite large parts to solve a small problem.
• Debt. All of this adds up to technical debt, and it tends to come due just as the product starts to work and changes are most urgent.

Review catches most of these before users do. At Choie, a senior person reads every line before it ships, whoever or whatever wrote it.

Vibe coding vs AI-assisted development

Many products start the first way and need to move to the second. That is a reasonable path if you plan for it. A vibe-coded prototype that proves the idea is a good brief for a real build, because it shows what the product should do. It is rarely a good foundation, and a team taking it over will often write the production code fresh.

In Choie's builds, AI drafts implementation from a design that is already decided, generates repetitive parts, proposes tests, and does mechanical refactors. The choie.co site is built the same way, and our guide to AI-accelerated development explains how it works.

Common questions