Lowyat recently ran a piece on vibe coding that is worth reading if you have built anything with AI this year. The term came from Andrej Karpathy, who described the practice as fully giving in to the tools: “I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works.”
That last clause is doing an enormous amount of work. Mostly works is a perfectly reasonable standard for a weekend prototype. It is a different proposition once the thing is on a public domain, taking enquiries from customers, and holding somebody’s data.
We are not here to tell you not to vibe code. Plenty of our clients have built something useful this way, faster and cheaper than any agency would have quoted them. The problem is never the building. It is everything that happens in the eighteen months after the building stops.
The specific gap: you shipped code you cannot read
Every other kind of website owner has somebody who understands the code. Maybe it is a developer they hired, maybe it is a plugin vendor, maybe it is the WordPress project itself. Somebody, somewhere, knows what the thing does.
With a vibe-coded app, frequently nobody does. The AI wrote it, it passed the one test that mattered — it looked right in the browser — and it went live. The article is blunt about where that leads: maintenance, updates and new features all become harder, because any change risks breaking something you did not know was there.
This produces a very particular failure mode. The site works fine for months. Then one day it does not, and the only available response is to go back to the AI and ask it to fix something neither of you can describe.
The four things that break, and when
The article lists the risks. Here is how each one actually shows up on a live site.
Software rot. Code degrades even when nobody touches it. The PHP version on your server gets upgraded by your host and a function your app relied on is gone. A payment provider changes their API. A browser tightens a cookie rule. None of this is your fault, none of it involved you making a change, and all of it will break a site that nobody is watching. We wrote about the PHP flaw that WordPress updates cannot fix for exactly this reason — the layer underneath your app moves whether you are paying attention or not.
Hardcoded secrets. This is the single most common thing we find in AI-generated code. API keys, database passwords and tokens written directly into files, sometimes into files the browser can fetch. The AI did it because it was the shortest path to working code, and working code is what it was asked for. Nobody told it that the key would still be sitting there in public a year later.
Authentication in the wrong place. The article names this one and it is worth repeating: AI will cheerfully implement a login check in client-side JavaScript. It works perfectly in testing, because you are not trying to cheat. Anyone who opens developer tools can walk straight past it. The admin area is not protected; it is politely signposted.
Slopsquatting. An AI hallucinates a package name that does not exist. Attackers watch for commonly hallucinated names, register them, and fill them with malware. You run the install command the AI gave you, and now the malware is on your server. This is not a theoretical supply-chain scenario — it is a published attack against exactly the workflow vibe coders use.
What a care plan actually does about this
A care plan is not a code review service and we are not going to pretend it is. What it does is supply the things a vibe-coded project structurally lacks: somebody who knows what is running, somebody watching, and somebody to call.
Somebody knows what you are running. We inventory the stack — PHP version, server OS, packages, dependencies, what is exposed to the internet. On a vibe-coded project this is often the first time anyone has written it down. You cannot patch what nobody has catalogued, and the catalogue needs to exist before the advisory lands, not during the panic.
The layer under your app is patched by someone whose job that is. Your app may be a mystery. The operating system, web server and runtime underneath it are not. Those are standard, well-understood components, and keeping them current is routine work on a plan. That alone closes off the majority of how sites actually get compromised. It is also the dividing line between our plans: Managed WordPress works within hosting you already have, while Managed WordPress + Web Server and Managed Web Server cover the server layer itself.
Secrets get found and moved. When we take on a site, hardcoded credentials are one of the first things we go looking for. Finding a Stripe key in a public JavaScript file is a thirty-minute fix today and a very bad month if it is found by somebody else first.
Monitoring means you hear it from us. Software rot is only expensive because of the lag. The site breaks on a Tuesday, you find out on Friday when a customer emails, and by then you have lost a week of enquiries. Uptime and security monitoring collapses that gap to minutes.
Backups are off-site and held separately from your host. This matters more for AI-built projects than for anything else, because the recovery path is weaker. There is no vendor to call, no plugin to roll back, no documentation. A known-good copy from before things went wrong is frequently the only route home. And as we have written before, backups kept on the same server they are protecting are not backups.
You have someone to ask. WhatsApp support sounds like a small line item. In practice it is the thing that stops a two-hour problem becoming a two-week one, because the alternative is prompting an AI at midnight and hoping.
Where the honest line is
A care plan will not rewrite your app, audit every function the AI generated, or guarantee that code nobody has read is free of bugs. If what you need is somebody to go through it properly, that is an audit, and it is separate work — the kind of thing we describe in what an audit finds in a fifteen-year-old WordPress site, just applied to code that is fifteen months old instead.
What a plan does is stop the preventable half. Unpatched servers, exposed keys, silent downtime, no backups, nobody watching. Those are not AI problems; they are operations problems, and they have the same answers they have always had. AI just produced a great many more sites that have nobody doing the operations.
The article concludes that vibe coding suits prototypes and small programs, and that experienced developers get the most out of it because they can spot the mistakes. We would put it slightly differently: the code is not really the risk. The risk is a production system with no owner.
If you have built something with AI and it is now live and earning, get in touch. We will tell you what you are actually running and what it would take to keep it standing.