What is vibe coding?

Where the term comes from

Andrej Karpathy gave the practice a name in early 2025 when he described leaning on a model so heavily that you “fully give in to the vibes” and stop reviewing the diff line by line. The phrase stuck because it named something a lot of people had already started doing.

The behaviour is older than the name. People have generated code from descriptions for as long as code generators have existed. What changed is the quality: a person with an idea and no engineering background can now get a working application onto the internet in a weekend, and that is genuinely new.

Why it works

The loop is short. You describe an outcome, get a draft, look at it, and describe the next change. Most of what an application needs is well-trodden, and the model has seen all of it. For a first version, a marketing site, an internal tool or a prototype, that speed is hard to argue with.

• You steer with outcomes instead of syntax, so you do not need to know the language.
• The model scaffolds the boring parts: routing, forms, database calls, styling.
• Changes are cheap, so you can try three versions of a screen before lunch.
• It is genuinely good at the happy path: the demo, the first click, the screenshot for the landing page.

Where it breaks

The speed comes from never reading the code, and the things a careful reader would have caught are exactly the things that cause incidents. AI-generated software tends to fail in a handful of consistent ways, which is why the failure modes have names of their own.

• Placeholders ship. Lorem ipsum, “Company Name” and TODO markers live on the homepage because the model filled every gap and nobody replaced the filler.
• Authorization exists only in the interface. The admin button is hidden from normal users, but the endpoint behind it never checks the role.
• Demo configuration goes live. Sandbox keys, a seeded admin login and sample customer rows are reachable from the browser.
• The second click breaks. Signup works from an empty database and fails the moment a real record exists.

The three kinds of vibe coding

Stakes decide how much process you need. Being clear about which kind you are doing prevents most arguments about rigour, because a weekend prototype and a payments product do not deserve the same review.

1. 01

   A prototype

   Throwaway, private, no real users and no real data. Ship it, learn from it, move on.

2. 02

   An internal tool

   A handful of known users and real data, with low stakes. Review how the data is protected and leave the rest.

3. 03

   A product

   Public, real customers, real money. This one needs a review before launch, the same as any other product.

How to vibe code without shipping a disaster

1. 01

   Keep the demo and the product apart

   Two environments, two sets of credentials, two databases if you can. The fastest way to leak demo data is to have only one of everything.

2. 02

   Put authorization on the server

   Hiding a control is not authorizing it. Every endpoint and every row of data needs a server-side rule that says who may touch it.

3. 03

   Treat anything in the browser as public

   If a key, a table name or an internal URL reaches the client, assume a stranger can read it.

4. 04

   Test the second click

   Create a real record, then do the thing again. The happy path from an empty database proves very little.

5. 05

   Review the running app, not just the code

   Some of the worst gaps are only visible from outside: a public bucket, an exposed endpoint, a page still showing placeholder copy. Look at what the site actually serves.

6. 06

   Write down what you checked

   A launch where nobody can say what was verified is a launch you cannot trust or repeat.

What a review should tell you

A useful review answers three questions: what is wrong, how do you know, and what do you do about it. A list of vague warnings helps nobody. An evidence-backed finding names the URL, shows the response or the copy, explains the risk in plain language and suggests a fix you can hand straight back to the model.

That is the gap PushFix was built to fill. It points at a running site, looks at it the way a visitor and a curious attacker would, and reports what it can prove, without ever reading your repository.