What is vibe coding

Vibe coding means writing software by describing what you want in natural language and accepting whatever the model produces, with little or no inspection of the underlying code. The engineer steers by feel rather than by reading and reasoning about the output.

Where the term comes from

Andrej Karpathy coined the phrase in early 2025 to describe a mode of working where you "fully give in to the vibes" and stop worrying about the code itself. The intent was partly descriptive, partly ironic. It stuck because it named something that was already happening.

What it looks like in practice

A developer prompts a model, runs what comes back, describes the error if something breaks, and iterates. No reading the diff. No asking why the model made a particular choice. The code is treated as an opaque artefact. It works until it doesn't.

This is distinct from agentic coding, where a coding agent takes multi-step actions inside a codebase and a human still reviews the result. Vibe coding is about the absence of that review, not the presence of automation.

Why it produces prototypes quickly

For a throwaway proof of concept, the approach is truly fast. The model handles boilerplate, wiring, and obvious structure. The human focuses entirely on whether the thing behaves as described. Feedback loops are short.

For that use case, the tradeoff is often worth it.

Why the prototype rarely survives contact with production

Problems accumulate in the parts that weren't inspected.

Security. Models reproduce common patterns, including common vulnerabilities. If you haven't read the code, you don't know whether input is validated, secrets are handled properly, or access controls exist. Prompt injection is one specific risk; there are many others.

Maintainability. Code that nobody understood when it was written is hard to change later. The next engineer, or the same engineer three months on, has no mental model to work from.

Correctness at the edges. Models are confident. They produce code that looks right and handles the obvious case. Edge cases, domain-specific constraints, and interactions between components are where the errors hide. These are exactly the things that don't surface in a quick demo.

Debugging. When something breaks in production, you need to reason about the code. If you never read it, you have nothing to reason from.

The transition problem

Moving a vibe-coded prototype to production is not a matter of "cleaning it up." It usually means reading every line, understanding what it actually does rather than what you intended, finding the places where the model made a plausible-but-wrong choice, and deciding what to rewrite. In practice that often takes longer than writing it properly from the start.

This is not a criticism of using AI to accelerate development. It is a description of what review-free generation costs you later.

What competent AI-native development looks like instead

A senior engineer using AI tools well still reads the output. They treat generated code as a capable first draft, not a finished product. They catch the places where the model was confident and wrong. They understand the context window the model was working from and where it might have gone astray.

That is a different skill from either vibe coding or traditional line-by-line authorship. It is also the skill that makes AI-assisted development safe to put in front of users. See how to review AI-generated code for what that process involves.

What we test for

Vibe coding behaviour is what our vetting is designed to surface. In the AI-native assessment, candidates work through tickets using whatever tools they normally use, and we watch whether they read what comes back. The scorecard criteria that bear most directly on this are AI output verification, which tests whether someone catches hallucinated APIs or subtly wrong logic before it ships, and judgement by risk, which tests whether generated code gets the same scrutiny regardless of how confident the tool sounds. Full details are at how we vet.

Short answers