"Vibe coding" is the shorthand for building software by describing what you want in plain English and letting an AI write the code. You type "make me a booking form that emails the office," it produces something that runs, you nudge it until it looks right. You don't learn syntax, you don't read docs, you don't open a single Stack Overflow tab. It feels like cheating.
Here's what that speed is worth in hours, at my company, this month. A careful conversion of an existing site used to run me about 25 hours, and a much bigger one could hit 70 or 80. It's now 10 to 15, and even the large ones land close to that same budget, because page count matters a lot less than it used to. Most of my time on one is quality check now. We're spending about a thousand a month on Claude to keep it there.
So that's the good half, and it's a big half. We've built sites since 2009, more than 2,000 of them, and I read AI-written code most weeks of the year now, which means I keep seeing the same five mistakes over and over, on projects that have nothing to do with each other, written by models that are supposedly a generation apart, and it's the same five every time. They aren't code-quality mistakes either. The models write pretty good code. What they don't do is ask what happens to that code on a Tuesday afternoon when somebody who isn't you is using it.
The problem isn't the speed. The problem is what "done" quietly means when an AI hands you something that runs.
I re-check this list every month, because the models change and so does the mix. What moved this month: secrets in the repo climbed. The newer models got noticeably better at sanitizing form inputs, and no better at all about where they put your API keys.
Mistake 1: Unvalidated Inputs And Secrets Left In The Code
You ask for a form that emails the office. You get a form that emails the office. What you don't get is the part where a stranger types a database command into the name field, because the model wasn't thinking about that stranger and it won't bring him up on its own.
What we keep finding: inputs that never get sanitized, a database query a visitor can rewrite, an admin route with no real check on who's calling it. And the one that costs the most, fastest, API keys and database passwords pasted straight into the code and then pushed to a public repo. Bots scan public repos for keys around the clock, so you're measuring that exposure in minutes. A leaked cloud key is somebody else's crypto miner on your bill by morning.
That's the mistake, and it's the same one both times. The model writes what you describe, and it never once pictures the person trying to break it.
Mistake 2: No Tests, So Nothing Catches A Break
Ask for a feature and you get a feature. You don't get the test that proves the feature still works in November, because the model doesn't volunteer one. It'll write tests if you spell it out, but it's never the one to bring it up, and that gap is where most of the damage lives.
So the code works today. You change one thing next month, something three files away quietly breaks, and you find out when a customer calls, which is a pretty expensive way to find out. On a booking form that's weeks of leads that went nowhere, and there's no log anywhere that can tell you when it started. Nothing was watching. The thing that wrote the code isn't watching either.
Mistake 3: Accessibility Gaps In Generated Markup
This one's invisible in a browser, which is exactly why it survives to launch.
Generated markup tends to look right and read badly to anything that isn't a pair of eyes. Missing form labels. Heading order that jumps from h1 to h4. Images with no alt text. Divs doing the job of buttons, so a keyboard user can see the thing and can't press it. Screen readers notice. Google notices. And there's a third reader in the room now, which is the AI assistant deciding whether it can quote your page in an answer, and that one is only going to matter more. Three different readers, and the markup wasn't written for any of them.
Mistake 4: Code Nobody On Your Team Can Explain
The model wrote it, it works, it's load-bearing now, and nobody on your team can say why it works.
This is more of a volume problem than a quality problem. You can generate more code in a week than you could read in a month, so at some point you stop reading, and that's just arithmetic. The day it breaks is the day you find out you can't fix it, and the AI that wrote it doesn't remember writing it either. Then you're paying somebody to reverse engineer your own website.
Mistake 5: No Version Control And No Backups
Ask a chat window for a change and it hands you a change. It doesn't run git init. It doesn't take a backup first. It has no idea that the file it just rewrote is the one your customers are looking at.
So edits land on a live site with no history and no copy anywhere, and one bad afternoon later there's nothing to roll back to. Setting version control up is maybe twenty minutes of work, and it's the one on this list that can cost you the whole site.
A quick gut check: if you pushed a feature live this week and can't answer "where's the backup, what tests cover it, and who would catch it if a stranger fed it bad data," you have a vibe-coded site whether you call it that or not. That's fixable. It's just better to know.
The Pre-Launch Checklist For AI-Written Code
Closing that gap is what our AI Studio was built for. We work the same way the trend does, fast and conversational with the AI doing the heavy lifting, and then a system runs on top of it. Pull the data, analyze it against documented methodology, deliver the artifact, with experienced people steering and signing off before anything ships. We call that system The Toolbelt. Design drives data, data drives design.
Five things happen to every build.
A person reads what the AI wrote. One review cycle caught about thirty-five issues we'd otherwise have shipped. We also run an enforced cross-check where OpenAI's GPT and Google's Gemini review each other's work and our own methods before anything is final.
Security and secrets get handled on purpose. Inputs get sanitized. Keys move out of the code and into a real key store. We shrink the attack surface rather than hoping nobody pokes at it.
The markup gets graded. Against accessibility standards, against search engines, and against whether an AI assistant can read the page and quote you in an answer. That last layer is its own discipline and a big part of how we approach building and rebuilding sites now.
The content cites checked facts. For regulated topics we build source-cited knowledge bases from primary sources, with each fact tagged by its authority, effective date, and a confidence level. One of them runs to more than 130 checked facts for a single legal niche, on a schema where adding another state is an overlay and not a rewrite.
Version control, backups, analytics. Every change is tracked with a clear history and there are backups, so a bad day is an undo. Then the new page or form gets wired to Google Analytics 4, so the next decision starts from what happened and not from what we hoped would happen.
Astro Or WordPress, Whichever Fits How You Run The Site
Picking the architecture is part of shipping responsibly, and forcing one stack on every client is its own mistake. Astro ships almost no JavaScript by default, which wins on raw speed, Core Web Vitals, a smaller attack surface, and clean markup that search engines and AI answers can both read. WordPress wins on a mature editor with a deep plugin library, plus easy self-editing for a non-technical team, and we harden and tune it so the speed and security gaps close. Neither one is the right answer for everyone, because it depends on who edits the site and how the site earns its keep.
Should You Vibe Code?
Yes, for the right things. Sketch the idea. Build the internal tool. Prototype the feature before you commit a budget to it. It's a fantastic way to draft and we use it every day.
Just know which side of the line a given project sits on. A weekend experiment and the form that takes your customers' money aren't the same risk, and they don't deserve the same level of care.
When it's the thing your business actually runs on, the prompt is the easy part. The review, the security pass, the accessibility and SEO checks, the cited facts, the version history, the backups, the analytics, that's the part that keeps you out of trouble, and it's the part we've spent years building a disciplined way to do. If you've got a vibe-coded site that works and you aren't sure you'd bet the company on it, that's a problem we know how to fix.