The website that was built before lunch
Imagine a founder who describes her new website to an AI tool at 10 am. By lunch it's live. It looks great, the colours are right, the contact form works. Everyone's thrilled.
Now imagine that three weeks later, the same contact form is happily accepting anything a stranger types into it, including a sneaky bit of malicious code. Nobody notices, because everything still looks fine.
That's the odd thing about code nobody has read. It can work perfectly and still be unsafe, and a demo never shows you the difference.
This is what people call vibe coding: describe what you want in plain English, let the AI write the code. It's real and it's everywhere. Even W3Techs, which tracks the technology behind websites, now lists AI site builders like Lovable and v0 next to the usual names. Nobody needs to avoid it. It just helps to know where to keep a hand on the door.
What the security research says
Veracode, a security company, gave more than 100 AI models a batch of coding tasks designed to tempt them into common mistakes. Nearly half the time (45%), the code that came back had a known security flaw. Not exotic ones, either. The sort security people have been warning about for years.
Take cross-site scripting, a classic. An attacker slips their own script into your page through something innocent, like a search box or a comment field, and your visitors' browsers run it as though it came from you. The models failed to guard against it in most of the relevant cases.
Here's the twist. Newer, bigger models got better at writing code that runs. They did not get noticeably better at writing code that's safe. So waiting for the next model to fix this isn't really a plan.
Fair caveats: a security vendor ran the test, the tasks were set up to be tricky, and it measured code snippets rather than finished websites. A failing snippet isn't a hacked site. But as a warning light, it's hard to ignore. Veracode also points out that AI-written code reaches you indirectly, through plugins, vendors, low-code tools and contractors. So even if you've never opened an AI tool, some of it may already be inside your site.
Green light: use it freely
- Prototypes and design experiments you'll show a client and then bin
- Layout and styling drafts that a developer will tidy up
- Boilerplate and repetitive components
- One-off scripts, tried on a copy of the data first
Red light: a human reads every line
Logins. Anything that writes to a database. Payments. File uploads. Admin panels. Anywhere an API key lives. And any form that collects personal details, like admission enquiries, applications or patient bookings. A simple test: if the data in that form would make an ugly headline, a person reviews that code.
A gate that isn't heavy
- A developer reads the sensitive parts. Properly, not skimming.
- Run automated scans, including a check on every package the AI pulled in. AI tools love adding packages.
- Keep passwords and API keys out of the code itself.
- Give the database account only the access it needs. A form that adds rows shouldn't be able to delete tables.
- Test on a staging copy first, never on the live site.
- Give it an owner. Someone has to understand this code at 11 pm when it breaks. This is the step everybody skips.
What to ask your agency
Do you use AI to write code on this project? Who reviews it before launch? What scans do you run, and can I see the results? Who looks after the site afterwards? A good answer is specific. "Don't worry, we've got it" isn't an answer.
Where this lands
AI is a very fast pair of hands. It isn't the owner. Let it save you hours, and keep a person between it and the public internet wherever it matters. That's boring advice, yes. But boring is exactly what you want from whatever is holding your admissions form together.
If you're weighing an AI-assisted build, or you've inherited one and aren't sure what's inside, talk to the Chillipages team or read more about Chillipages' AI-powered website development.
