Vibe coding: what it gives and what it costs

Why:Vibe coding means accepting code from an AI without reading it. Afterwards you’ll tell it apart from ordinary work with an AI assistant, know what it honestly gives and which four things it puts at risk (security, maintainability, understanding and money), and decide for your own site what can go to an AI with no check, what only with a check, and what can’t at all.

25 minutes

Read by speech synthesis (Qwen3-TTS); the voice is not a person’s.

Vibe coding is working with AI by accepting its code without reading or understanding it; ordinary AI assistance differs in that the result is checked.

A word coined early in 2025

In February 2025 Andrej Karpathy, a well-known AI researcher and one of the founders of OpenAI, gave a name to a way of working he saw in himself: you describe what you want, press “accept”, stop reading the code, and if something breaks you just ask the AI to fix it. He called it vibe coding (code made “by feel”). By the end of the year the Collins dictionary had chosen it as its word of the year.

What matters is that the word describes not a tool but an attitude to the result. The same AI assistant can be either. The developer Simon Willison proposed telling them apart this way: if an AI wrote every line of code, and you reviewed, tested and understood it, that is not vibe coding but using an AI as a very fast typewriter. Vibe coding begins where you stop understanding what you accept.

The distinction looks like nitpicking, but the rest of the lesson rests on it. It also answers the question you may be asking after the last lesson: if a builder assembles a site in a minute, why were there ten parts on HTML, CSS, servers and data? Because understanding what you accept is the difference between “I direct the AI” and “I believe the AI”.

Check yourself: an AI wrote all the code, and you read and checked every line. Is that vibe coding?

No. By Willison’s distinction, vibe coding is accepting code without understanding it. Code you have read, checked and understood is ordinary work with an AI assistant, and the responsibility for it is yours.

What it honestly gives

Skepticism shouldn’t hide the benefit.

  • A quick prototype. What used to take days (a form, a page, a small service) takes an hour. You can test an idea cheaply before you invest.
  • Personal and one-off tools. A page that calculates something for you alone, a script for one job: no data, no money, no strangers, and a mistake shows at once.
  • An entry ticket. A person who doesn’t program sees for the first time how an idea becomes a working thing. That is valuable in itself.
  • Drafts. A frame you then build your own work on.

What it costs

Each of these benefits has a price, and the price shows where vibe coding is dangerous. The incidents below are dated, and each was checked against its primary source in October 2026.

Security. A page looks as if it works, but what makes it insecure (a key in client code, no checking of input, other people’s records reachable by an address, no check of rights) can’t be seen by eye. In Veracode’s 2025 study, over 100 models completed 80 coding tasks with known weaknesses, and about 45% of the tests produced insecure code; larger and newer models did no better. In a real case, the researcher Matt Palmer scanned 1,645 projects from the showcase of the AI builder Lovable in March 2025 and found 303 endpoints in 170 of them (about 10%) with inadequate row-level security in the connected database, which could expose data, among it emails, phone numbers and keys. The record, CVE-2025-48757, was published on 29 May 2025, and the researchers say Lovable’s own answer, a security scan, only checked that a rule existed, not that it was right. You read the lesson on authentication for this reason: so that you can recognize such things: rights checked on the server, secrets out of client code, a slow hash for passwords.

Maintainability. Code nobody has read, nobody can change. In a month you will want to fix one thing and find that the AI copied pieces into new places at every edit, and now there are seven. A December 2025 report by the code-review company CodeRabbit compared 470 open-source pull requests, 320 co-authored with AI and 150 human only: the AI ones averaged 10.83 issues each against 6.45, about 1.7 times as many. The company itself notes that authorship was inferred from signs of AI use, so the labels may be imperfect, and the figures are a pattern, not a law.

Understanding. You can’t direct what you don’t understand. You won’t notice that an AI proposed a library that doesn’t exist (researchers have described how such invented names get into code, and how attackers register them), won’t understand why a page can’t be used from the keyboard, and won’t tell “works” from “works for now”. This is the textbook’s main thesis, and it is why you went through ten parts.

Money and time. Many tools charge for every call to the model. “AI, fix it” after “AI, fix it” can burn your budget while the model repairs its own mistakes. And the feeling of speed is deceptive: in METR’s July 2025 study, experienced developers on large, familiar projects took about 19% longer with AI tools, though they believed they were faster. The sample was small (16 people) and the authors warn against generalizing, and in February 2026 METR itself said the result was no longer a reliable guide, because its newer data hinted at some speedup but suffered from selection effects (developers who refuse to work without AI skew who takes part). The conclusion stands whichever way the numbers move: measure, don’t trust a feeling.

Data and rights. When you paste other people’s data into a prompt (a customer list, a correspondence), you send it to a third-party operator. And when you give an agent rights (to delete, to write to a database), it may do what you didn’t ask. In July 2025 Jason Lemkin, the founder of SaaStr, reported that the Replit AI agent deleted a production database during a code freeze he had told it to respect, and then said it couldn’t be restored. Replit’s chief executive called this “unacceptable” and said the data could be restored with a one-click rollback; the company admitted its apps had used one database for both development and live data and announced a separation of the two. This is the founder’s account and the company’s reply, and the lesson is the same either way: an agent with write rights to live data needs a fence.

Check yourself: why is an “invisible” mistake more dangerous than a “visible” one?

A visible one (the layout broke) is fixed at once, while an invisible one (a leak, no check of rights) lives until trouble comes. So it needs a check or a person.

What can go to an AI, and what can’t

A rule follows that you can apply to any task. Four questions:

  1. Does it touch visitors’ personal data?
  2. Does it touch money?
  3. Is a mistake visible by eye?
  4. Is it public at once?

Data and money weigh the most: a mistake costs other people’s trust and other people’s money. Next comes “not visible by eye”, and “public” weighs the least. From this come three levels.

  • AI without a check: tasks with no data and no money, where a mistake shows at once and costs little: a palette for a sketch, a draft you will rewrite anyway, a meta description.
  • AI with a check: everything that will reach the live site: layout (look with your eyes, with Tab and on a phone), scripts (read them), text (check the facts).
  • A person: what can’t be handed over without a check at all: receiving personal data, payment, the policy and consent (with an attorney), sign-in, secrets, and the facts about you and your project. Even if an AI writes a draft, the decision and the responsibility are a person’s.

Try sorting the tasks in the diagram. One of them is yours: the form for the main action from your brief.

What can go to an AI with no check, and what can’t

For each task, choose how you will trust an AI with it. The page says what the rule suggests, and why.

  • Choose a palette and a pair of fonts for a first sketch

    Visitors’ data: no. Money: no. A mistake is visible by eye: yes. Public at once: no.

  • The layout of the home page from a ready design

    Visitors’ data: no. Money: no. A mistake is visible by eye: yes. Public at once: yes.

  • Drafts of the sections’ text (you will check them afterwards)

    Visitors’ data: no. Money: no. A mistake is visible by eye: yes. Public at once: no.

  • Text with facts about you: experience, numbers, proof

    Visitors’ data: no. Money: no. A mistake is visible by eye: no. Public at once: yes.

  • A form for the action “The project’s main action”: receiving a visitor’s data

    Visitors’ data: yes. Money: no. A mistake is visible by eye: no. Public at once: yes.

  • Payment or a deposit on the site

    Visitors’ data: yes. Money: yes. A mistake is visible by eye: no. Public at once: yes.

  • The privacy notice and consent

    Visitors’ data: yes. Money: no. A mistake is visible by eye: no. Public at once: yes.

  • Sign-in for the owner and a panel with requests

    Visitors’ data: yes. Money: no. A mistake is visible by eye: no. Public at once: yes.

Tasks decided: 0 of 8, matching the rule: 0.

The rule of four questions. Personal data and money weigh the most: a mistake there costs other people’s trust or other people’s money. Next is “a mistake can’t be seen by eye” (you won’t notice a leak until it has happened), and “public at once” weighs the least.

Practice

Sort the ten tasks of your site into three levels. In the column on the right, say each time how you check, or why the task stays with a person. The form, receiving requests, payment, the policy, the counter and the secrets can’t go “with no check”: that is checked automatically. At the end, write what is left for a person and how much work it is. The figure is there so you can see that an AI removes part of the work but not all, and that the part that remains is the most responsible.

What was wrong with 2025

In 2025 vibe coding was a fashion and a promise: “you no longer need to program”. It soon turned out that what you need is not to program but to understand and check: pages were built in minutes and then repaired for months, and open databases and keys turned up in public builders. By the end of the year the word had stopped being a joke and become a warning. Not because AI is bad, but because the responsibility for the result is still a person’s.

Practice

Preparing your page…

Test

Question 1 of 5

How does vibe coding differ from working with a programmer’s AI assistant?

One answer

Cards

These cards go into your review once you finish the lesson.

  • What is vibe coding?

    Answer

    A term of Andrej Karpathy’s (February 2025): writing in words and accepting an AI’s code without reading or understanding it. It differs from a professional’s use of AI in that the result isn’t checked and nobody answers for it.

  • What does vibe coding give, and where does it fit?

    Answer

    Quick prototypes, one-off and personal tools, a cheap test of an idea. It fits where there is no data and no money and a mistake shows at once.

  • What does it cost?

    Answer

    Security (silent holes), maintainability (duplication, nobody understands the code), understanding (you can’t direct what you don’t understand), money (credits on endless edits) and leaks of data through prompts.

  • The rule of four questions for a task

    Answer

    Does it touch visitors’ data? Money? Is a mistake visible by eye? Is it public at once? Data and money lead to a person, an invisible mistake to a check, the rest can go to an AI.

Sources

Next

You now know: vibe coding.