Vibe Coding: The Promise, The Pitfalls & How to Do It Right

Most of us in the tech or business space have heard of the term **“vibe coding”** — coined by Andrej Karpathy in February 2025 which in AI years feels like a decade ago. > “There’s a new kind of coding I call ‘vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. … I just see stuff, say stuff, run stuff, and copy-paste stuff, and it mostly works.” > > > — Andrej Karpathy, [X (formerly Twitter)](https://x.com/karpathy/status/1886192184808149383) > It took the world by storm. Suddenly, anyone with an idea, an internet connection and enough *vibes* could build; whether or not they had ever heard of Git before. That shift sparked beautiful innovation… and plenty of #AIslop. Like any revolution, vibe coding brought **the Good, the Bad, and the Ugly**. In this piece, I’ll explore the benefits, the pitfalls, and how vibe coding *should* be used.. rather than letting it use us. ### 1. The Good — why vibe coding matters **Speed of execution** Vibe coding lets you ship faster than ever. What once took a month to build a POC or a MVP, now takes a weekend, sometimes even a single coffee-fuelled evening. Creators are using LLMs to build full-stack apps in hours. (find example pls, partner) That kind of momentum changes the psychology of shipping; it rewards curiosity instead of perfectionism. **Creative freedom** Founders can now test ten ideas instead of one. Instead of debating feasibility for weeks, they can just *build the thing* and see if users care. It’s the startup equivalent of rapid sketching — fail fast, validate faster. Many Builders in the #BuildinPublic space do just that. **Cross-discipline collaboration** Perhaps the most underrated benefit: non-technical teammates finally get a seat at the table. Designers, marketers, and ops people can prototype scripts that solve the companies pain points that devs might not have noticed. When barriers fall, ideas surface from corners of the company that normally stay quiet. It’s democratization in its purest, messiest form. Additionally, non-tech people that want to improve their life can do so by automating their own workflows and/or build their own basic applications. But for every breakthrough, there’s a bug hiding in the shadows. Let’s talk about the bad. ### 2. The Bad — when vibes go wrong **Lack of Security** When you don’t read the code, you don’t know what vulnerabilities you might be introducing. A single copy-pasted snippet can expose API keys or user data, and most people especially non-technical won’t notice until it’s too late. (link to tea app hack due to simple security failure) You might ask, *“Why not let an LLM code the app, then review and test it before production?”* Absolutely — that’s smart development. But that’s **not** vibe coding. As programmer Simon Willison put it: > “If an LLM wrote the code for you, and you then reviewed it, tested it thoroughly and made sure you could explain how it works to someone else — that’s not vibe coding. It’s software development.” > > > — [Simon Willison’s Weblog](https://open.substack.com/pub/simonw/p/not-all-ai-assisted-programming-is?selection=2f04ea1d-f56b-48d4-aa6c-b50e68a539e2) > **The cult of the 10× vibe coder** The internet loves speed. “10× engineer” was already a meme, vibe coding just revitalised the culture. But when speed becomes the only metric, architecture and communication crumble. A “10×” vibe coder might ship 10 times faster but also create 100 times the maintenance debt. They can often build code that is a mystery, with codebases so brittle that nobody else can touch them without something breaking. This used to exist but has been more prevalent now that vibe coding has been introduced. The result? A beautiful demo, a brittle product, and a burnt-out coder. Speed matters — but clarity compounds. **The slow death of understanding** When you rely entirely on AI-generated code without understanding it, you miss the opportunity to learn. That might seem trivial, but heres why it isn’t: 1. **You can’t debug confidently.** If something breaks, you or your LLM will spend hours tracing logic you never understood. You will not even know what the problem even is, much less where to look. 2. **You can’t rebuild or extend what you’ve built.** You become a **code consumer**, not a creator. I know this first-hand: I once vibe-coded an app to help me stay in touch with friends. New stack, new framework, the MVP worked. The issue came when I tried to add a feature, I realised I had no idea how the app functioned. So I shelved it (for now). Lesson learned. 3. **You stop thinking like a builder.** This might not be an issue for those that are not programmers but for programmers, you lose the ability to think critically and deeply over your code. When you outsource every mental step, your ability to reason through problems weakens over time. Yes, I know, thats harsh. But think of it like skipping leg day for your brain; sure, you still *look* in shape, but the foundation gets shaky. First we lost curiosity, then we lost security, and somewhere along the line, we lost the plot. ### 3. The Ugly — ..and how to make it beautiful It all depends on **Intention**. Here are two common ones, and how I’d approach each. **1️⃣ Intention: “To build an MVP quickly. for those that understand code”** Here’s how to vibe responsibly: 1. **Design deliberately.** Before prompting, outline your stack, features, and data flow. The LLM will happily hallucinate your architecture if you’re not specific. 2. **Use vibe coding for prototyping, not permanence.** Let speed rule *temporarily*. It’s called *vibe coding*, not *vibe deploying*. Use it like sketching on a napkin: fast, flexible, and disposable. Once an idea proves itself, rebuild the core properly. 3. **Review and refactor.** Don’t just skim what the AI wrote, understand it. Refactor unclear logic, add comments, and make sure every function has a reason to exist. Insert tests and documentation. Think of it as “de-vibing” your prototype into a product. 4. **Mind the risk.** For anything public, sensitive or monetised, apply standard software engineering guardrails (security review, logging, backups). Vibe coding gets you to *something that works*; secure development gets you to *something that lasts.* 5. **Grow your builder mindset.** Use vibe coding to *accelerate* building, not to skip building. Let it free your prototype time so you can focus on strategic problems, not just typing. Use AI as a creative sandbox, not a production pipeline. Treat it as such and you create problems that can scale. **2️⃣ Intention: “To build your own apps, scripts, or automations when you don’t yet understand code.”** This is where vibe coding becomes an amazing learning tool. Here’s how to use it intentionally: 1. **Start with curiosity, not perfection.** Don’t aim to build the next Facebook clone. Instead, start with something small an automation that saves you 10 minutes a day. 2. **Ask “why” after every generation.** When the LLM writes code, ask it to explain *what each block does*. Treat every answer as a micro-lesson. 3. **Experiment safely.** Run things locally first. Avoid giving APIs or credentials until you know what the script actually does. 4. **Document your journey.** Keep a small note file explaining what you learned with each build. It’ll reinforce your understanding faster than any course. 5. **Graduate from vibes to fundamentals.** As patterns repeat, try writing those sections manually. That’s when you realise vibe coding isn’t replacing coding, it’s teaching you *how to think like a coder.* ### Closing thoughts Vibe coding is neither a revolution nor a sin — it’s a mirror. It shows how we build when the barrier to creation disappears. The magic is in using the vibes to *amplify* your mind, not replace it. If you’ve built something through pure vibes, I’d love to see it. Tag me [@caslerbiz](https://x.com/caslerbiz) or join the [Secubri Circle](https://www.secubri.com/circle). And if you want monthly insights like this — join [**Secubri Brief**](https://buttondown.com/secubri), where we explore the real-world side of AI, automation, and security for builders and businesses.