Vibe coding.
From prototype to product.

Describe the change. Run it. Follow the next idea.

Vibe coding is an informal name for a prompt-led way of building software: describe an outcome in ordinary language, let an AI coding tool change the project, run what it made, and keep iterating from what you see.

Andrej Karpathy used the phrase in a February 2025 post about his own deliberately loose workflow, where he accepted generated changes without reading every diff. He framed it as amusing and suitable for throwaway weekend projects. That description captures one end of a broad practice; it is not a standard, a quality label, or a definition of who counts as a programmer.

The useful question is what the software is for. A disposable sketch can optimize for speed. Something other people depend on needs a visible owner, understandable behavior, and checks that match the cost of failure.

It makes the feedback loop shorter.

Prompt-led iteration can turn an idea into something you can click, question, and revise before you know the exact implementation. That is useful for exploring a layout, learning an unfamiliar tool, trying a small automation, or showing a concept to someone who can respond to it.

The early screen is also the easiest part to judge. A result can look finished while hiding unclear assumptions, unhandled inputs, excessive access, brittle dependencies, or behavior that no one has tried to break. A successful demo says that one path worked once; it does not settle whether the whole system is ready for its intended use.

Look for patterns, not a verdict about all AI code.

A 2025 study compared more than 500,000 Python and Java code samples, using human-written functions from GitHub projects and outputs from ChatGPT, DeepSeek-Coder, and Qwen-Coder. Static-analysis tools found different quality profiles: generated samples were generally simpler and more repetitive, with more unused constructs and hard-coded debugging; the human-written set showed more structural complexity and maintainability issues. The study also reported more high-risk security findings in its AI-generated set.

That is a comparison under a particular setup, not a forecast for every codebase. The languages, models, sample construction, prompts, and static-analysis rules all shape what the study can see. A scanner finding is a reason to inspect a path, not proof that a vulnerability is exploitable; a clean scan does not prove that a feature is safe.

A separate repository study looked for public GitHub files whose comments explicitly attributed code to AI tools, then analyzed those files with CodeQL. Its authors note that this misses AI-assisted code without attribution and may overrepresent projects where people choose to document tool use. The evidence supports careful review and task-specific checks, not the claim that code is bad because AI helped write it.

Set the prototype’s boundaries in plain language.

For a local experiment, those boundaries can be lightweight: a disposable project, synthetic data, and no external write access. When a prototype reaches real accounts, private information, or decisions that affect other people, pause and redesign its permissions and review points before expanding it.

Turn “it works on my screen” into evidence.

1. Name the real job. Define who the software serves, the behavior it must deliver, and the cases it should refuse or handle safely.
2. Take ownership of the project. Read the structure, entry points, configuration, dependencies, and data flows. Ask the assistant to explain them, then check that explanation against the code.
3. Review the whole change. Inspect the diff, remove unrelated experiments, and make sure you can explain what each changed part does.
4. Test ordinary and difficult paths. Check expected use, empty or malformed inputs, permission failures, dependency errors, and the behavior after a partial failure.
5. Protect the boundary. Check authentication, authorization, secrets, personal data, external requests, and newly added packages. Give each integration only the access it needs.
6. Make it operable. Decide how errors are reported, who maintains the software, how changes are released, and how to restore service or reverse a bad update.
7. Release in proportion to the risk. Start with a small group or limited capability, observe the actual behavior, and widen use only when the evidence supports it.

This is not a demand for heavyweight process around every experiment. The amount of review should follow the software’s reach and the cost of being wrong. The line changes when the prototype starts handling other people’s information or actions.

Use the model to make more options visible.

Ask for a small change, request the assumptions behind it, and have the tool point to the files and tests it touched. Let it draft tests, compare approaches, and explain unfamiliar code. Keep the decisions that carry consequences in a reviewable human workflow.

A useful rhythm is simple: state the goal, constrain the change, inspect the result, run a check, and decide what happens next. If the project becomes difficult to explain, stop adding features long enough to recover a clear map of its behavior.

• Is this still an isolated prototype, or do people now rely on it?
• Can I explain and reproduce the behavior I plan to ship?
• Have I checked the paths where a mistake would matter most?
• Does someone own maintenance, feedback, and recovery?

Make the next decision with evidence.

Use a focused review checklist for AI-generated changes ↗, then read how to measure the full development workflow ↗. For software agents that take actions in a repository, see why agents need evidence, not confidence ↗.