Vibe coding a website: what it is, and where it goes wrong
Describe the site, let the assistant write it, never read the code. That is vibe coding, and for a website it works, on one condition.
On this page
TL;DR
Vibe coding is building software by describing it to an AI and accepting the code without reading it. A website is the best possible case for it: the result is a few static files anyone can judge by looking at them. Where it fails is predictable: invented content, images that break, a heavy first screen, a template look, and nothing ever reviewed. The fix is not to read the code. It is a discipline: brief, build, review, publish, and roll back if you were wrong.
What vibe coding actually means
The phrase is from February 2025, when Andrej Karpathy described a way of working where you "fully give in to the vibes", talk to the assistant, accept what it writes without reading the diff, and describe a bug in plain words instead of fixing it yourself. It was half a joke. It became the word for building things by conversation.
It is worth being precise, because the word now covers everything from a weekend prototype to a company. Vibe coding is not a product or a tool. It is a stance: the code is a means, you judge the result, and you never open the file. Whether that stance is reckless or sensible depends entirely on what you are building.
Why a website is the easy case
Most of the warnings about vibe coding are about applications: things with logins, a database, payments, other people's data. There, code you have not read can leak, lose or expose something, and you cannot tell by looking at the screen. The screen looks fine right up to the day it does not.
A website is the opposite. A static site is a handful of files, HTML, CSS, a few images, and everything it does is visible. If a section is missing, you see it. If the phone number is wrong, you see it. There is no server to compromise, no database to leak, nothing running when nobody is looking. The rule "do not read the code" costs nothing when the code is a page.
That is why an assistant can build a real website today and why the result is the same HTML a developer would ship for a simple site. The vibe is not the risk. What you did not ask for is.
The five ways it goes wrong
These come up on almost every generated site we look at, and none of them is a coding error. That is the point: reading the code would not have caught a single one.
- Content that reads true and is not. A testimonial, a founding year, a client name, invented to fill a gap, styled like the real thing, and forgotten there.
- Images that break later. The assistant points a picture at a file on somebody else's site, and one day that site moves it. Nobody warns you.
- A first screen that weighs three megabytes. The model has no idea how heavy the file it just referenced is, and a slow first screen loses visitors before they read a word.
- The template look. A centered hero, three cards, generic icons, soft shadows on everything. Not wrong, just the average of every page it has seen.
- Nothing reviewed. The assistant that just wrote the page is the worst judge of it, and the second worst is you, thirty seconds after the demo.
Every one of these is visible on the page. Vibe coding a site fails in plain sight, which is exactly why it is fixable.
The vibe is the brief
Here is the part the word hides: the quality of a vibe-coded site is decided before the first line of code, by what you said. "Make me a nice website for my studio" gets you the average. What you sell and to whom, the one action a visitor should take, three proofs, your practical details, and a short list of what you do not want: that gets you a site about you.
Vibe is not vague. The people who get good results from an assistant are not better at reading code. They are better at saying what they want, and at asking the assistant to interview them when they cannot. The first guide is that conversation, written out.
The discipline: brief, build, review, publish
- Brief. Four answers and a list of what you do not want, in one message. Ask the assistant to interview you first if you would rather not write it.
- Build. One page, in the order that converts: hero, offer, proof, contact, footer. One action, repeated with the same label.
- Review. Ask the assistant to stop, change role, and score its own work as an art director on eight axes. Fix the weakest point. Two passes, not ten.
- Publish. Say it. With a connector, the site goes online in the same conversation, on a real address, as a version that is never lost.
- Roll back if you were wrong. The version before is live again in one sentence. A publish is not a one-way door.
Notice what is not in the list: reading the code. The review is a scored pass by the assistant itself, and the safety net is a version you can go back to. That is the whole discipline, and it fits in five messages.
Vibe coding does not mean skipping the review. It means the review is a sentence, not a code read.
Where vibe coding a site stops
Honest limits. A shop with a cart, customer accounts, a booking engine that takes payment, a members area: those are applications, with state and data, and they are where the warnings apply. Build them with a developer, or with a service made for it.
What a static site can still do is more than people think: a contact form, a booking link, a payment link, a map, an embedded video, a calendar, structured data that makes it findable. The docs draw the line precisely. For a portfolio, a practice, a restaurant, an event or a launch page, the line is nowhere near you.
Say this
Build me a one-page site from this brief. Before you write any code, ask me for what you are missing rather than inventing it. When it is done, review it as an art director, score it on typography, composition, hierarchy, motion, copy, anti-template, images and accessibility, fix the weakest point, and only then tell me it is ready to publish.
Frequently asked
What is vibe coding?
A way of building software by describing what you want to an AI assistant and accepting the code it writes without reading it. The term comes from Andrej Karpathy in February 2025 and now covers most building done by conversation.
Can you vibe code a website?
Yes, and it is the best case for it: a static site is a few files whose every result is visible on the page, with no server, database or user data at risk. What decides the quality is the brief you give and the review you ask for, not the code.
Is vibe coding safe for a website?
For a static site, the risks are visible ones: invented content, images linked from elsewhere, a heavy first screen, a template look. None is a security problem. Applications with accounts, payments or a database are a different matter and need real development.
Do I need to read the code my assistant wrote?
Not for a static site. Ask the assistant to review its own work as an art director and score it, publish as a version, and roll back if a version is wrong. The review is a sentence, not a code read.