Vibe coding: what it is, what it's good for, and where it breaks

Learn in your browser · Chapter 01 of 05

Vibe coding has a name, a real origin and a real trade-off. Knowing all three stops the word being either a compliment or an insult.

Vibe coding means describing what you want in plain words and accepting the code an AI produces with little or no line-by-line review. The name was coined by the AI researcher Andrej Karpathy in a widely shared post in February 2025, where he described handing the small details to the AI and moving on rather than reading every line it wrote. Within months the phrase had spread far beyond programmers, used loosely for almost any AI-written code.

Vibe coding is not a single act, it sits on a spectrum. At one end, an editor suggests the next few words and you approve them one at a time. At the other end, you describe a whole feature and never open the file it lives in. The UK's National Cyber Security Centre (NCSC) frames this as a spectrum rather than a switch: prototypes and throwaway experiments can sit safely towards the vibe-coding end, while anything touching secrets, credentials or other people's data needs a much closer look.

Scroll sideways to see every column.

• Q1: What does vibe coding actually mean?
• A: Describing what you want in plain words and accepting the AI's code with little or no line-by-line review.
• Q2: Who coined the term, and when?
• A: Andrej Karpathy, in a widely shared post in February 2025.
• Q3: Is vibe coding always reckless?
• A: No. On a low-stakes prototype you would throw away, it can be a fair trade-off. The risk rises with the stakes, not the label.
• Q4: What is the one question that tells you whether you are vibe coding?
• A: Did a person read this before it ran? If not, you are vibe coding, whatever the tool calls itself.

Learn in your browser · Chapter 02 of 05

Almost everyone uses these tools now. Hardly anyone fully trusts what they produce, and fewer still check it every time. That gap is the whole reason this workbook exists.

Adoption of AI coding tools is now close to universal among professional developers. Stack Overflow's 2025 Developer Survey found that 84% of developers said they use, or plan to use, AI tools in their work, up from 76% the year before. Trust in the results has not kept pace: only 29% of respondents said they trusted the accuracy of what these tools produce, 46% said they actively distrusted it, and just 3% reported high trust.

Trust is one thing, checking is another, and the two do not line up. Sonar's State of Code developer survey found that only 48% of developers said they always verified AI-assisted code before committing it, which means most developers ship at least some AI-written code without their own full check, at least some of the time. That gap between what people use and what they actually review is the trust gap this workbook is named for, and it applies just as much to a spreadsheet macro or a small business tool as it does to a professional codebase.

• Q1: What does the Stack Overflow 2025 survey say about trust in AI-written code?
• A: 84% of developers use or plan to use AI tools, but only 29% trust the accuracy of what those tools produce, and 46% actively distrust it.
• Q2: What is the trust gap, in one sentence?
• A: The distance between how much people use AI coding tools and how often they actually check what those tools produce.
• Q3: Why can a wrong answer look just as confident as a right one?
• A: An AI model predicts likely-looking text, it does not know whether the answer is correct, so a mistake can read just as smoothly as the right result.
• Q4: According to the Sonar survey, how many developers always verify AI-assisted code before committing it?
• A: Only 48%, meaning most developers ship at least some AI-written code without a full check of their own.

Learn in your browser · Chapter 03 of 05

The right question is never whether vibe coding is good or bad, it is what happens if this particular piece is wrong.

Stakes, not skill, decide whether vibe coding is reasonable. A prototype you will delete tomorrow carries almost no risk if it is wrong. A tool that touches money, personal data, other people's work or anything you cannot easily undo carries a real one. Ask what would actually happen if this exact piece of code were quietly wrong for a week before anyone noticed.

• Can I undo it? A throwaway script you can delete is lower stakes than one that changes real records.
• Does it touch money or personal data? Even a small business invoice or a list of customer names raises the stakes.
• Does anyone else rely on the result? Code only you will ever see is lower stakes than a tool colleagues or customers use.
• How would I even notice it was wrong? A mistake that would show up immediately is safer than one that could hide for weeks.

Scroll sideways to see every column.

• Q1: What is the main factor that decides whether vibe coding is a reasonable choice?
• A: The stakes of the task, not your skill level: what would happen if this exact piece of code were quietly wrong for a while.
• Q2: Name two of the four questions used to place a task on the spectrum.
• A: Any two of: can I undo it, does it touch money or personal data, does anyone else rely on the result, how would I notice if it were wrong.
• Q3: Why is an invoicing tool for a small business a poor fit for full vibe coding?
• A: It touches money and other people's records, and a quiet mistake could run for a while before anyone noticed it.
• Q4: What should you do when you are not sure which side of the line a task falls on?
• A: Treat it as the higher-stakes case and review it properly. A ten-minute check is cheaper than fixing a mistake later.

Learn in your browser · Chapter 04 of 05

You do not need to read every symbol to review AI-written code well. You need to ask the right questions and test the answers.

You can review code you cannot fully write yourself. The checklist below works whatever the language, because it asks about behaviour, not syntax. Your editor's or notes app's find tool can help you spot the words in the right-hand column even in code you do not read fluently.

Scroll sideways to see every column.

A flawed example, in plain words. An AI was asked to work out a 20% deposit on a booking and refuse any booking of £10 or under. Here is what it actually did, written out step by step rather than as code, so you can review it without reading a line of syntax:

EXAMPLE ONLY. Read it, do not build from it.

1. It reads the booking amount typed into the box.
2. It works out 20 per cent of that amount as the deposit.
3. It emails the customer's address and the booking amount to a logging address, without being asked to.
4. It refuses a booking only when the amount is exactly 10 or under, so a booking of 10.50 is allowed, which is correct, but a booking of 9.99 is also allowed, which should have been refused.
5. If the amount box is left empty, it shows the deposit as NaN (not a number) instead of a clear message.

• Q1: Do you need to read every line of code to review it well?
• A: No. A checklist that asks about behaviour, what it touches, sends, does with bad input and whether it matches your brief, works whatever the language.
• Q2: Why is an AI's own explanation of its code not proof that the code is right?
• A: The explanation is generated the same way the code was, so it can sound fluent and still be wrong. Your own test against an answer you already know is the real proof.
• Q3: What is the single most useful test you can run on AI-written code?
• A: An example where you worked out the correct answer yourself first, then checked the code against it.
• Q4: In the booking example, why did the 10 check cause a problem?
• A: It only caught bookings of exactly 10 or under, so an amount just under that line was wrongly allowed instead of refused.

Learn in your browser · Chapter 05 of 05

A handful of habits turn vibe coding from a gamble into a reasonable, repeatable way of working.

Keep secrets and personal data out. Never paste passwords, keys, account numbers or other people's details into an AI tool or the code it writes. What you type usually leaves your device, and OWASP's guidance for AI systems warns that sensitive information you provide may later be exposed elsewhere. Use made-up example data instead, and if a real secret slips in by mistake, treat it as exposed and replace it at the service that issued it.

Work on a copy, not the original. Keep a saved, working copy of anything before an AI tool changes it, so a bad result costs you a few minutes, not a rebuild. If a tool can act on its own, give it the least access it needs for the one job, a habit OWASP frames as addressing excessive agency, and ask for a dry run, a list of what it would do without doing it, before anything that changes real files or sends anything.

Check the terms before you use or share the result. Tool terms and code licences vary, and this is not legal advice. GOV.UK notes that copyright protects original work, including software, automatically in the UK, and that an owner can license others to use it. Before you rely on AI-written code for something that matters, or share or sell it, check your tool's terms and the licence of anything it reproduces.

1. Write a short brief: what it is for, what goes in, what comes out, and one or two examples worked out by hand.
2. Ask for it in one small piece at a time, not the whole thing at once.
3. Review with the checklist: what it touches, sends, does with bad input, and whether it matches your brief.
4. Test it against the examples you worked out by hand, not against the tool's own account of itself.
5. Check the guardrails: no secrets pasted, a saved copy kept, terms checked if it matters.

• Q1: Name one thing you should never paste into an AI coding tool.
• A: Any of: a password, a key, an account number or another person's personal details. Use made-up example data instead.
• Q2: What is a dry run, and why ask for one?
• A: A list of what a tool would do without actually doing it. It lets you check a plan before anything real changes.
• Q3: Why work on a copy rather than the original file?
• A: So a bad result costs a few minutes to undo instead of a rebuild, since you can go back to the saved copy.
• Q4: What is the single most useful habit for catching a quiet mistake?
• A: Testing the result against an example you worked out by hand yourself, not against the tool's own explanation of what it did.

You can now name vibe coding honestly, see the real gap between how much people use these tools and how often they check them, judge when the trade-off is fair, review code you did not write using a plain checklist, and keep the guardrails that matter regardless of how good the tools get.

This PDF is yours to keep. Print it, write in it, and keep the five-step card somewhere you will actually see it.

Ready to prove it? Take the exam for this workbook. Score 81% or higher and you earn a certificate with your own name on it.

https://trust-agent.ai/exam/vibe-coding-explained

This is free educational content published by Mickai LTD, not professional, legal, financial or compliance advice, and Mickai accepts no liability for how you use it.

Checking code before you trust it is a small, personal version of a bigger idea: a human stays in control of what an AI system does, which is at the centre of how Trust Agent and Mickai think about trustworthy AI.