Vibe Coding

What Vibe Coding is

Vibe coding is a way of making software where you describe the result you want, an AI tool writes the code, and you judge the outcome by running it instead of by reading the code. You say what is wrong, the tool changes it, and you repeat until it behaves the way you want.

The site’s guide to vibe coding for business defines it in those terms, and that is the level this page works at. It does not teach you to build anything. It explains what the term means, what the method is good for, where it goes wrong, and why the person who owns the business should decide the rules before anyone starts.

What makes it vibe coding, and not just AI-assisted coding, is the level of trust. A developer using autocomplete still reads and edits every line. A vibe coder accepts the output and judges it by whether it seems to work.

Where the term came from

The AI researcher Andrej Karpathy coined it in a social media post on 2 February 2025. He described a way of working where you “fully give in to the vibes, embrace exponentials, and forget that the code even exists.” By November 2025 a major English dictionary had named it its word of the year, defining it as the use of artificial intelligence prompted by natural language to assist with writing computer code.

The guide points out that the original description was of a casual way of making throwaway projects, not a method for running a business. Most of the debate since has been about what happens when that casual method meets work that matters.

How Vibe Coding works

The method is a loop of four steps that repeats until the result is good enough.

First, you describe what you want in everyday language, with as much detail as you can about who uses it and what it should do. Second, the tool generates the code and, in many tools, runs it so you can see a working page or app straight away. Third, you test it by clicking through the cases that matter, such as an empty form, a wrong password or a very long entry. Fourth, you describe what is wrong and ask for a change.

Underneath is a language model that has been trained on a very large amount of existing code. Your request is a plain-language prompt, and the quality of what comes back depends heavily on how clearly it is written.

The guide groups the tools into four kinds. Chat assistants write code that you copy somewhere else. App builders turn a description into a working site or app, with hosting included. AI code editors suit people who can read code. Coding agents work through a whole project with little supervision, which makes them closer to an AI agent than to a chatbot.

What a Business can use it for

A small business can use it for simple, contained tools that its own staff use and that hold no sensitive data. The best candidates are jobs you would otherwise do in a spreadsheet, or not do at all.

The guide lists a staff rota or room booking page, an internal calculator such as a quote estimator, a landing page or one-page campaign site with no logins and no stored data, a dashboard that reads a spreadsheet you already hold, and a prototype to show what you want built.

The last is the strongest use for most owners. A prototype that works on screen answers the question “what exactly do you mean?” better than a ten-page brief. It is also the safest use, because nobody is yet relying on it.

Where Vibe Coding goes wrong

The main risk is that AI-written code often works and is still insecure, and a person who never reads it has no way to see the flaw. The guide reports a 2025 security report that tested code from more than 100 language models and found security flaws in 45% of tests. It also found that bigger, newer models were no better at writing secure code than earlier ones: they had become better at producing code that runs, not code that is safe.

Three problems come up repeatedly. One is broken access control, where the app works but one user can see or change another user’s records. Another is exposed secrets, where passwords and keys end up written into the code or the page. The third is unchecked input, where the app trusts whatever a visitor types.

The guide also cites a 2025 scan of 1,645 apps made with one popular app builder, which reportedly found 170 that let anyone see other people’s personal information. That is the pattern to expect when an app that looks finished was never reviewed.

There is a quieter risk as well. A 2025 randomised trial found that 16 experienced developers took 19% longer on 246 real tasks when they were allowed to use AI tools, while believing they had been faster. The guide notes that the trial’s authors have since said the result is out of date, so it is a reminder that feeling fast is not the same as being fast, and not a verdict on today’s tools.

Code can also contain a hallucination. The tool may call a function that does not exist, or build a feature that looks right and does the wrong sum. That is why testing matters more than looking at the screen.

The Security spectrum

The UK National Cyber Security Centre set out a useful way of thinking about this in June 2026, which the guide summarises. Vibe coding is not a yes or no. It sits on a spectrum, from manual coding with a little AI autocomplete at one end to full vibe coding at the other, where the AI has autonomy over the design, the code and the tests and you only judge the output.

The guidance says full vibe coding can be perfectly fine for prototypes and proof-of-concepts, for demos that communicate an idea, for internal tools with limited exposure, and for anything with no sensitive data or security functions. It says to move towards manual control, with a person who reviews and understands the code, when the project involves login and permission logic, sensitive personal data, secrets or credentials, anything safety-critical, or anything where a flaw would have serious consequences.

The guide turns that into a rule of thumb for an owner. The question is never whether you may vibe code. It is how much review this particular thing needs. A throwaway prototype needs a light check. An internal tool with no personal data needs moderate testing and a backup. A public page that collects enquiries needs a person to read the code that handles the form. Anything with logins, payments or customer records needs someone qualified to write or review it.

Vibe Coding and Personal Data

The method is neither compliant nor non-compliant with the GDPR. What matters is what you build and what data it touches. The regulation expects appropriate technical and organisational security for personal data, and an app that nobody reviewed, holding real customer records, is hard to defend if it leaks them.

Two practical rules follow from the guide. Keep real customer and staff data out of a vibe-coded project until someone qualified has reviewed the code, and use made-up sample data while you build. And be careful what you paste into the tool itself, since prompts and files may leave your control. The data protection page covers what applies to anything you build, however quickly you built it.

Vibe Coding, No-Code Automation and AI Agents

Vibe coding is often confused with its neighbours, so it is worth separating them.

No-code automation gives you ready-made blocks to arrange. What you can build is limited by the platform, but the blocks are tested and behave predictably, and the supplier carries much of the security work. Vibe coding generates real code from a description, so you can build almost anything, but the result is less predictable and nobody has tested it for you. For a repeatable process with fixed steps, the guide says a no-code tool is usually the safer choice.

Vibe coding and AI agents overlap at the coding-agent end, where a tool works across a whole project with little supervision. And the tools a coding assistant builds against are often connected through the Model Context Protocol. The site’s MCP vs API review explains why that matters: with MCP the AI model chooses which tool to use and what to send, so results can vary and need checking.

What it does not change

It does not make the code correct. A tool can produce an app that looks finished and fails on the awkward cases, which is why the guide’s first advice is to test the cases that matter, not to admire the screen.

It does not remove the need for a person. The human in the loop page covers who reviews what, and for anything that reaches a customer the answer is a person who can read the result.

And it does not remove the need for an owner. A vibe-coded app has no author who understands it. If the person who built it leaves, or the tool changes how it works, you may be left with software that no one can explain or fix. The guide’s answer is to give any tool that matters an owner, write down what it does and who can change it, and treat it as an AI governance question from the start.

A worked example

An illustration, not a case study. A business wants a page where staff can see which meeting rooms are booked this week. An owner describes it to an app builder in two sentences, and a working first version appears within minutes.

The owner tests it with made-up bookings, and finds that two people can book the same room at the same time. They describe that fault, the tool fixes it, and they test again. The page holds no personal data and sits behind the company’s own sign-in, so a light review is enough. They save a copy of the working version, name themselves as the owner, and agree to switch it off if it ever starts to matter more than a booking list.

If the business later wanted a public page that took enquiries from customers, that would be a different decision. It would sit further along the spectrum, and a person who can read code would need to review the part that handles the form.

Mix-ups worth avoiding

Four confusions come up often enough to name. The first is treating vibe coding as a replacement for developers, when it lets non-developers build simple things and developers move faster on routine work but still needs someone to design, secure and own what matters. The second is treating working code as safe code, when the evidence in the guide is that they are different things. The third is treating it as the same as no-code, when the output and the risks differ. The fourth is letting it become shadow AI: tools in use that nobody approved, building software nobody owns.

How we use it

Vibe coding is taught in the advanced generative AI course. The block on it covers building small working things without traditional development, the risks and how to mitigate them, and why you still need to understand what was built. It follows the first generative AI workshop and sits alongside the session on agents, personalisation and the no-code tools that run them. Read about it on the advanced generative AI course page.

If you are deciding what your team may build with AI, and what needs review first, a discovery call is a quick way to start.

Sources

• Vibe coding for business: the definition, the four-step loop, the four groups of tools, what a small business can build, the review levels by kind of project, the safe-start steps, the origin of the term, the 45% of tests figure, the scan of 1,645 apps, the developer-speed trial and the National Cyber Security Centre’s spectrum.
• MCP vs API: MCP servers and tools, and the AI model choosing the call at run time.
• Advanced generative AI course: the course block on building small working things, the risks and understanding what was built.
• Prototype, No-code automation, AI agent, Data protection and Human in the loop: the neighbouring terms this page links to.