← All resources

What is vibe coding? We vibe-coded a clinic website in seven prompts, then audited it.

Where the term came from, the tools behind it, and a real experiment: a booking site with patient X-rays, built by an AI from plain-English requests nobody reviewed, then tested the way we test a client’s site.

Vibe coding is building software by describing what you want to an AI and accepting what it writes without reading the code. The phrase is barely two years old and already a dictionary’s word of the year, and the argument about it mostly runs on anecdotes: a demo that worked, a database that got deleted. So we ran the experiment ourselves. A fresh AI coding agent was given seven requests of the kind a small dental clinic’s owner would make — pages, online booking, a receptionist login, emails, a cancel link, X-ray uploads, and “make it ready to put online” — with nobody reading or correcting the code in between. Then we audited the result the way we would audit a site a client brought us: every line of the server code, a running copy under attack, and a speed test. The clinic is invented, the site never went online, and the findings are below — including the parts that surprised us.

What our audit found in the vibe-coded clinic site

FindingWhat happened in the testHow seriousWhat would fix it
Receptionist can be locked out by anyoneFive wrong passwords from a stranger locked the real account for 15 minutes, and it can be repeated indefinitelyHighCount failures per visitor and slow them down, rather than locking the account
Spam limits bypassed with one headerWith proxy mode on, as its own guide advises, 20 of 20 messages got through a limit of 5 an hourHigh once onlineTrust only the address the host’s proxy adds, not the one the visitor sends
No spam limits on the copy the owner runsLimits only switch on in “live mode”; 15 of 15 messages accepted locallyMediumLimits on by default, everywhere
Bookings under someone else’s emailAnyone can book with any address, which emails a stranger a working cancel and upload linkMediumConfirm the email address before the booking is final
Cancel link shown to whoever bookedThe private link appears on screen, not only in the patient’s emailMediumSend the link by email only
X-rays stored unencrypted, kept foreverHealth files sit as plain files on disk and in backups, with no deletion ruleMedium (GDPR)Encryption at rest and an automatic retention period
Consent tick-box as a condition of bookingBooking is refused unless the patient “agrees” to the clinic storing their detailsMedium (GDPR)Base the processing on the appointment itself and health care, and say so in the privacy notice
Fake entries in the message logOne contact message can add text that looks like a second, separate messageLowStrip line breaks from the log, or store messages as structured data

From our audit on 2 October 2026 of a site built by an AI coding agent from seven owner-style prompts, with no code review in between. 30 further checks passed; the full list is in the article. The clinic is fictional and the site was only ever run on one computer.

What is vibe coding?

Vibe coding is writing software by talking to an AI model in plain language and accepting the code it produces without reading it. You describe what you want, run what comes back, paste any error message back in, and keep going until it works. The skill it asks for is knowing what you want, not knowing how to program, which is exactly why it caught on.

The term was coined by the AI researcher Andrej Karpathy in a post on X on 2 February 2025. He described “a new kind of coding” where you “fully give in to the vibes, embrace exponentials, and forget that the code even exists”, admitted that he no longer read the changes the AI made, and added the caveat most people skip: it was “not too bad for throwaway weekend projects”.

The phrase spread faster than almost anything in software. Collins named “vibe coding” its Word of the Year on 6 November 2025, defining it as “the use of artificial intelligence prompted by natural language to write computer code”. In between, it went from a joke about weekend projects to a description of how real companies were being built.

Vibe coding vs AI-assisted programming

Not every use of AI to write code is vibe coding, and the difference matters more than the label. The developer Simon Willison drew the line clearly: vibe coding means “building software with an LLM without reviewing the code it writes”. If an AI wrote the code and you then reviewed it, tested it and could explain how it works, he wrote, “that’s not vibe coding, it’s software development”.

That distinction is the whole subject of this article. Professional developers now use AI assistants every day, and the question for them is how much to check. The question for a business owner who cannot read code is different: what happens when nobody checks at all? That is the situation vibe coding creates, and it is the one we set out to test.

Vibe coding tools

The tools fall into three groups. Chat-to-app builders such as Lovable, Bolt, Replit and v0 take a description in a browser and return a working app, often hosted for you, so there is nothing to install. AI code editors such as Cursor and Windsurf put the same ability inside a programmer’s editor, where the code is at least visible. And coding agents such as Claude Code and OpenAI’s Codex run on your own computer, read and write files, run commands and test their own work.

The first group is where most non-developers start, because it hides the code completely. The third is closest to what a developer uses, and it is what we used here: a coding agent working in an empty folder, deciding its own technology and building, running and testing the site itself. If you are weighing these tools against a website builder or an agency, AI-generated websites compares what each route actually hands you.

How widespread is it? In March 2025, Y Combinator’s managing partner Jared Friedman said that a quarter of the startups in its Winter 2025 batch had codebases that were 95% written by AI — and that these were technical founders, not people who could not code.

Our vibe coding experiment: the rules

We wanted to know what an owner who cannot read code actually gets. So we invented a business — a small dental clinic called Smile Studio Demo — and wrote the requests its owner might make, in the order an owner would make them. The builder was a fresh AI coding agent with no access to our own code, working in an empty folder on one computer. Nothing it built was ever put online.

The seven requests were sent word for word. One: a home page, services and prices, an about page with three dentists, and a contact page. Two: online booking with free time slots that disappear once taken. Three: an admin page where the receptionist logs in and can see and cancel bookings. Four: emails to the clinic and the patient. Five: a link in the email so patients can see and cancel their own booking. Six: a page to upload a photo or PDF of an X-ray before the appointment. Seven: “Make it ready so I can put it online. What do I need to do?”

The rules were the ones an owner would follow without knowing it. Nobody read or edited the code between requests. When the agent offered options, the next request went out unanswered. And nothing about security was ever asked for, because a clinic owner would not know to ask. The only instructions beyond the seven requests were practical: stay in this folder, do not deploy anything, and do not send real emails.

What it built

Roughly three hours of the agent working across the seven requests produced a complete, good-looking site: four pages of invented clinic content, a booking calendar that blocks the full length of each treatment, a reception page with a login, confirmation and cancellation emails with calendar invites, a private patient page, X-ray uploads, a privacy policy page, a launch checklist and a step-by-step guide to going online. It chose plain Node.js with a single extra library for email, no framework and no database — about 2,600 lines of JavaScript that saves everything to files.

It also behaved better than the stereotype. It wrote and ran its own tests at every step — 81 of them after the booking request alone — and fixed the bugs they turned up. It refused to send real emails, as instructed, and saved them to a folder instead. When asked to make the site ready to put online, it did not try to publish it: it wrote a guide, listed what the owner still had to do, and said plainly that the three patient reviews it had invented for the home page “must not go online”.

Our dependency check found no known vulnerabilities in its one library, and the code it wrote was readable, commented and consistent. By the standard of what a non-developer could have produced any other way, this is remarkable.

What it got right without being asked

We ran 38 attacks and checks against a running copy, configured exactly as its own go-live guide says. Thirty passed. Nobody could reach the reception page, the booking list or a patient’s files without logging in. None of the usual tricks for reading the data files from the web worked. Passwords were stored the way security guidance recommends, as salted, deliberately slow hashes. The private patient link carried a long random secret that the site stores only in scrambled form, and the booking reference printed in the email opened nothing on its own.

Most of the defences a security reviewer looks for first were already there, and not one had been requested. Uploads were checked by their actual contents, so a web page or a program renamed to look like an X-ray was refused. Uploaded files were stored outside the public website and served back with the headers that stop a browser running anything inside them. Emails escaped whatever patients typed into the booking form. The pages carried a strict security policy that blocks scripts from anywhere but the site itself.

A large share of those protections arrived in the last turn, though. By the agent’s own summary, the anti-framing headers, the protection against forms submitted from other websites and all the spam limits were added only when the owner said “put it online”. An owner who had stopped at the X-ray request and uploaded the folder themselves would have shipped without them.

What it got wrong

Eight findings survived testing, and none of them is the kind a tool can fix by writing better code. The most serious is about who the attacker is. To stop people guessing the receptionist’s password, the site locks the account after five wrong attempts. But it counts wrong attempts from anyone, so a stranger can lock the real receptionist out of the bookings page for fifteen minutes with five requests, and do it again every three minutes for as long as they like.

The second is about trusting the wrong thing. Once online behind a hosting provider’s proxy — which the agent’s own guide says is “almost always” the case — the site reads the visitor’s address from a header that the visitor can write themselves. Changing it on every request walked straight through every spam limit: 20 of 20 messages accepted against a limit of five an hour. The same trick works for bookings and uploads, which means unlimited bookings with up to 100 MB of files each, until the disk is full.

The rest are about people. The site never checks that an email address belongs to the person booking, so anyone can make an appointment in someone else’s name and have the clinic email them a working cancel and upload link — and the same link is shown on screen to whoever made the booking. A contact message can include line breaks that make the saved message log show a second, fake message. And on the copy the owner actually runs on their computer, there are no spam limits at all: they only switch on in “live mode”.

Health data: the part that needs a lawyer, not a model

X-rays and treatment notes are health data, a special category under Article 9 of the GDPR. The agent treated them carefully as files, but not as health records. They are stored unencrypted, on disk and in every backup, and kept until somebody deletes them by hand. To its credit, the agent raised that last point itself and offered to add automatic deletion. It never came up again, because the next request was about going online.

The legal basis is the subtler problem. In the last turn the agent added a privacy page and a required tick-box: the patient must “agree” to the clinic storing their details before the booking goes through. That sounds careful, and it is the wrong tool. Under the GDPR, consent that is made a condition of receiving a service is not freely given. A clinic processes booking data to deliver the appointment the patient asked for, and health data to provide health care — bases that do not depend on a tick-box at all. The privacy page itself still had nine blanks marked for the owner to fill in.

Then there is the content. The home page shipped with three invented patient reviews, a 4.9 rating and “6,000+ patients”. The agent flagged the reviews before launch, but they were live on the site it handed over. Under EU consumer law, presenting fake consumer reviews as genuine is banned outright, in every circumstance.

The pattern behind the findings

Vibe coding produced code that works and tests that prove it works — and nothing that asks who might use it against you. Every one of the agent’s own tests checked that a feature did what the owner asked: the slot disappears, the email arrives, the file uploads. None asked what a stranger, a competitor or a bored teenager would do with the same features. That is not a gap in the model’s knowledge; it knew how to write a lockout, a rate limit and a hashed token. It is a gap in the brief, and the owner is the only one who could have filled it.

The same pattern explains why most of the defences arrived at the end. The agent built what was asked, and “make it ready to put online” was the first request that implied strangers. In professional work, the question of who the users and the abusers are comes first, before the first line of code. In vibe coding it comes when someone thinks to ask, if they do.

It also explains the incidents that have made the news. In March 2025 a security researcher scanned 1,645 apps built with Lovable and found 170 of them — about one in ten — exposing personal and financial data and API keys through misconfigured database rules. That July, an AI agent deleted a company’s production database during a declared code freeze, a story told in our list of real AI agent examples. The industry-wide numbers on vulnerabilities in AI-written code are collected in vibe coding security.

Is a vibe-coded site slow?

Not this one. We ran Lighthouse, the engine behind Google’s PageSpeed Insights, three times on each of four pages on its mobile setting. The home page scored 98 for performance, 98 for accessibility and 100 for both best practices and SEO, on 158 KiB across 11 requests — lighter than most professionally built sites we have measured.

The booking page was the exception at 84, because the calendar and time slots fill in after the page loads and push the layout down, a layout shift of 0.27 against Google’s target of 0.1. The accessibility findings were small and typical: a heading out of order, some text with too little contrast, and links distinguished from the text around them by colour alone. What a 100 really measures, and what it does not, is in how to get a 100 PageSpeed score.

Speed is the one place where the lack of review did not cost anything, because plain HTML with no framework and no third-party scripts is fast by default. The risks of vibe coding are not in what a visitor sees.

When vibe coding is fine

Karpathy’s own caveat still holds: for throwaway projects it is wonderful. A prototype to show investors, a tool only you will use, a one-off page for an event, a script that tidies a spreadsheet — anything where the worst case is that it breaks and you shrug. The speed is real, and our clinic site shows the quality of what comes out has risen a long way.

It is also fine as a first draft that someone qualified then owns. Most of the findings in our audit would take a developer an afternoon to fix, precisely because the code was clean enough to read. The problem is never the AI writing the code. It is nobody reading it before strangers can use it.

When it isn’t, and what to check first

If the site will take bookings, payments, accounts or anything personal, somebody who can read the code has to read it before it goes online. Not because the AI writes worse code than a junior developer — in places it wrote better — but because the questions that matter are about your business, not about code: who might abuse this feature, whose address is this, what does the law say about this data, how long do we keep it.

If you have vibe-coded a site and want to check it yourself, start with the questions our findings raise. Try logging in wrongly five times: are you now locked out? Book with an email address you do not own: does it work? Look at where uploaded files are kept and for how long. Read your privacy page and look for blanks. Search the home page for anything the AI invented — reviews, numbers, team members — and remove it. And ask the AI directly what a malicious visitor could do with each feature, which is the request our experiment never made.

For the build itself, how to build a website walks through every step whichever way you go, and website builder vs custom website covers when a builder is the safer choice.

What this means if you are paying for a site

Vibe coding has changed what a cheap website can be, and that cuts both ways. A freelancer or an agency using AI well can deliver more for less, and you should expect them to. A freelancer using it the way our experiment did — accepting whatever comes back — can deliver a site that looks finished, passes a speed test and still lets a stranger lock your staff out of it.

So ask how the site was reviewed, not whether AI was used. Who read the code? What was tested beyond “it works”? Where is personal data stored, and for how long? An honest answer to those takes a minute. If you already have a site and do not know the answers, our Technical Audit is €399 and covers code, performance, security and dependencies in a prioritised report; web development covers building it properly from the start.

Sources and method

The experiment and audit were run on 2 October 2026. The builder was a fresh AI coding agent (Claude Code) working in an empty folder with no access to our codebase; its requests, our turn-by-turn notes and the audit scripts are kept on file. The clinic is fictional and the site was only ever run on one computer. Other figures come from the sources below.

Frequently asked questions

Built a site with AI and not sure what is in it?

We will read the code, test it the way an attacker would, and tell you plainly what to fix — or that it is fine as it is.