How to Vibe Code: The Basic Workflow
Step 1 – Define scope tightly before you start The most common vibe coding failure is starting with "build me a SaaS app." Start instead with the smallest possible slice: "Build a login form with email/password that validates on submit and shows an error state." Narrow scope = coherent output.
Step 2 – Choose the right tool for the output If you need a full-stack app with a database, use Lovable, Bolt, or a similar platform. If you're extending an existing codebase, use an agentic IDE. If you need a quick script, use a chat-based assistant. Tool mismatch is responsible for a significant proportion of bad vibe coding experiences.
Step 3 – Prompt in outcomes, not implementations "Make the button blue" is a worse prompt than "The primary CTA button should be visually dominant – use the brand accent color with high contrast." Describe what you want the user to experience, not what CSS to write. The model decides implementation; you decide intent.
Step 4 – Review every change before accepting This step is where vibe coders most often get into trouble. When a change "looks right," it's tempting to accept without reading the diff. But AI-generated code can introduce subtle issues, unused variables, inefficient queries, missing validation, that aren't visible in the UI.
Step 5 – Test on real inputs, not just happy paths AI-generated code is typically optimized for the example in the prompt, not for edge cases. Test with empty inputs, malformed data, and unexpected user behavior before shipping.
Step 6 – Maintain a record of what was built This sounds obvious but is consistently skipped. A brief comment on each major feature ("AI-generated checkout flow, not reviewed for PCI compliance") creates an audit trail that becomes essential if you ever need to debug, hand off, or secure the codebase.
Is Vibe Coding Bad? The Honest Assessment This is the question that generates the most search traffic, and the most polarized opinions.
Linus Torvalds, creator of Linux and someone whose opinion on code quality carries weight, has not been complimentary about AI-generated code in general, describing it as producing "random crap." His broader concern is that AI systems generate plausible-looking code that lacks the deep architectural reasoning that makes systems maintainable and secure over time.
This is not a fringe view. It's shared by a significant portion of the senior engineering community.
But "is vibe coding bad" is the wrong question. The better questions are:
Bad for what? Vibe coding is arguably ideal for: MVPs, internal tools, personal projects, prototyping, throwaway scripts, front-end mockups, and any context where speed matters more than long-term maintainability. It is arguably dangerous for: production systems handling sensitive data, applications with compliance requirements (HIPAA, PCI-DSS, SOC 2), and any system where a security flaw has real commercial or legal consequences.
Bad compared to what? A non-technical founder using vibe coding to validate a business idea is not comparing it to "a senior engineer building it properly." They're comparing it to "not building it at all" or "waiting six months to find a developer." In that comparison, vibe coding wins on almost every axis.
Bad without what? Vibe coding without any technical review is higher-risk than vibe coding with a code audit before launch. The technology doesn't have to be used carelessly. Most of the cautionary stories in the vibe coding discourse are stories about a lack of review process, not about AI code generation being inherently flawed.
The vibe coding meme, the jokes about founders shipping apps they can't maintain, AI writing code that looks like it works until it doesn't contains real truth. But so does the counter-narrative: real products have been built, real revenue generated, real problems solved by people who would never have been able to ship software before these tools existed.
The pragmatic answer: vibe coding is a powerful tool with specific failure modes. Know the failure modes before you rely on the tool.
