Vibe Coding

Vibe coding is building software by describing what you want to an AI model and steering the result, rather than writing the implementation yourself. Andrej Karpathy named it on 2 February 2025, describing a way of working where you give in to the vibes and forget the code exists.

The name is deliberately unserious and the capability is not. For a class of work — prototypes, internal tools, the first version of something whose shape is unknown — it collapses a week into an afternoon.

What it is genuinely good at

Answering a question with a working thing. A clickable artefact beats a description, and prototyping with real interaction used to cost enough that most questions went untested.

Exploring several directions. When a version costs an hour, three versions is a reasonable Tuesday. Committing to the first idea was always a budget decision rather than a design one.

Internal tools. Software with ten known users, no adversaries and no compliance surface is exactly where the generated happy path is sufficient.

Getting to a decision faster. The fastest way to find out that nobody wants something is to put a working version in front of them.

What it does not produce

The model generates what it was asked about, and nobody asks about the unglamorous nine-tenths.

States. Empty, loading, partial, error, permission-denied. A generated screen assumes data exists and the request succeeded. See the state table under UI design.

Consistency across screens. Each screen is generated in isolation, so the same control appears in three forms, spacing drifts, and a dialog behaves differently in each place. One screen at a time it looks fine; as a product it reads as incoherent. This is what a design system exists to prevent.

Behaviour at real volume. The generated table holds six rows. The customer has ninety thousand.

Permissions. An admin, a member and a read-only viewer see different products, and the generated version usually knows about one of them.

Accessibility. Keyboard navigation, focus management, contrast, screen-reader behaviour. Generated markup is frequently divs where controls should be, and that is a rebuild rather than a fix.

The decision about what to build. The model is very good at making the thing you described and has no opinion about whether it was the right thing.

The gap this creates, and why it matters commercially

The characteristic situation is now common enough to have a shape. Somebody builds something with an AI tool over a weekend. It demos well, and on the strength of the demo it gets shown to customers, or to investors, or to a board.

Then it has to become a product a company can actually run. That transition is not a polish pass. It usually means deciding the structure that was never decided, building the states that were never drawn, imposing consistency across screens that were each invented separately, and doing the accessibility and permission work from scratch.

Teams reach this point genuinely surprised, because the visible ninety per cent was free and the invisible ten per cent is where the work was. The honest framing is that vibe coding moved the starting line, not the finish.

Using it well

Prototype with it, decide with it, then decide again about the build. The prototype answered a question. Whether its code is the foundation is a separate question with a different answer most of the time.

Give it the constraints you already have. Pointed at existing design tokens and components, a model produces output that fits the product. Given nothing, it invents a new visual language every session.

Ask for the unhappy paths explicitly. They will not appear otherwise, and they are most of the screens.

Review it as a design, not as a diff. The question is whether this is the right arrangement, not whether the code runs. It usually runs.

In practice

A founder builds a working dashboard over a weekend, shows three prospects, and gets two signed letters of intent. On that basis the company commits to shipping in a quarter.

The build takes two. Not because the generated code was bad, but because none of the following existed: any handling of an account with no data, a permissions model, a consistent table component across the five screens that each had their own, and a way for the interface to survive a customer with forty thousand records. The prototype also had no concept of who was logged in.

None of that was visible in the demo, and none of it was a failure of the tool. The weekend was a genuine saving on the part that used to take a week. The quarter that followed was the part that had never been done.

Where teams get it wrong

• Treating the prototype as the foundation. It answered a question; that was its job.
• Reviewing code instead of design. It runs. That was never the risk.
• Generating without constraints. A new visual language every session.
• Assuming the happy path is the product. It is perhaps a tenth of the screens.
• Skipping accessibility until procurement asks. Retrofitting it across generated markup costs more than building it in.