Let's start with the honest part, because it matters: AI-assisted building is one of the best things to happen to small businesses in years. A founder who can't code can now stand up a booking system, a landing page, an internal tool — in a fraction of the time and cost it used to take. "Vibe-coding," where you describe what you want in plain language and let an AI generate it, is a real productivity unlock. We use these tools ourselves. The point of this article is not to tell you to stop.
The point is this: the same tools that let anyone build a system in a weekend also let them ship one that's quietly dangerous — and because it looks finished, it goes straight to production. The industry has a name for the output now: AI slop. It isn't a style complaint. It's an unfunded liability sitting in your live environment, waiting to surface as a data leak, a compliance breach, or a system nobody can safely change.
What "AI Slop" Actually Means
AI slop is what AI produces at speed without oversight: code, systems or content that looks complete but hides real problems underneath. The dangerous thing is exactly that it looks done. A human junior developer's mistakes usually look like mistakes. AI's mistakes often look like a finished, confident, professional result — right up until someone probes them.
In an AI-built system, that typically shows up as a recognisable set of issues. None of these are exotic; they are the ordinary, repeatable ways vibe-coded software goes wrong:
1. Secrets hardcoded in the open
API keys, database passwords and payment credentials pasted directly into the code — sometimes into the front end, where anyone can read them by opening their browser's developer tools. AI generates working code first and worries about secret management never, unless told to.
2. Missing or fake authentication
A login screen that looks like security but checks nothing on the server, or an admin area protected only by "don't share this link." Whole databases have been left open to the public internet this way because the AI built the feature, not the fence around it.
3. Prompt injection and model abuse
Any system that feeds user input into an AI model can be manipulated by that input — tricked into ignoring its instructions, leaking its system prompt, or revealing data it shouldn't. This is now a documented, top-tier risk class (see the OWASP Top 10 for LLM Applications and MITRE ATLAS), and it's almost never handled in a weekend build.
4. Logic that's confidently wrong
Pricing that miscalculates in an edge case, a booking system that double-books, a form that silently drops submissions. The code runs, the demo works, and the bug only appears with real customers and real money.
5. No input validation
Forms and APIs that trust whatever they're given — the doorway for injection attacks, corrupted data and crashes.
6. Structure nobody can maintain
Systems assembled in pieces by an AI, with no coherent architecture, no documentation and no tests. It works today. The first time it needs to change, you discover it can't be changed safely — and the person who "built" it can't explain how it works either.
The POPIA angle
Most of these failures are also data-protection failures. An exposed database or a leaky form holding South Africans' personal information is a POPIA breach — with a 72-hour reporting obligation and fines of up to R10 million — regardless of whether a human or an AI wrote the code that caused it. "The AI did it" is not a defence.
Why It Ships Anyway
The reason AI slop reaches production so reliably is psychological, not technical. When you build something the traditional way, you feel every gap — you know what you didn't get to. When an AI hands you a polished, working-looking result in minutes, there's nothing to feel. The absence of security is invisible. The confidence of the output is inversely related to your awareness of its risks. So it launches, and the exposure sits quietly until an attacker, an auditor, or a curious customer finds it first.
This is the same trap we see with cheap outsourced builds, only faster and more convincing. It's why we built our Digital Rescue practice — and increasingly, why clients ask us to check AI-built systems before they launch rather than after they've leaked.
The Guardrails That Actually Work
The answer isn't to abandon AI — it's to put an experienced engineering layer between the AI and the real world. A few principles do most of the work:
- Get an independent review before launch. A short specialist pass over an AI-built system finds the exposed secrets, the missing auth and the injection holes while they're still cheap to fix — before there's real data behind them.
- Never lead with unvalidated AI in a high-stakes flow. Payments, personal information, anything legally sensitive: AI can help build it, but the security and correctness have to be verified by someone who owns the consequence.
- Keep a human in the loop where it matters. AI features should escalate to a person on the decisions that carry risk, not quietly decide them.
- Put guardrails around AI usage, not just AI systems. Clear rules for what staff may paste into public AI tools protect you from the other common leak: confidential and client data walking out through a chat box.
- Insist on ownership and documentation. If nobody can explain how the system works, you don't own an asset — you own a risk with a login page.
Keep the Speed. Lose the Exposure.
Vibe-coding and AI-assisted building are here to stay, and that's a good thing — they put capability in the hands of people who never had it. But capability without oversight is exactly how a weekend win becomes a Monday breach. Keep building fast. Just don't ship what you haven't checked, and don't check it yourself if the stakes are real. That's the whole discipline: use AI for the speed, and bring in an experienced set of eyes for the safety.