"Vibe Coding" Is A Stupid Trend

“Vibe coding” is being used as a catch-all label for any AI-assisted programming, but its original meaning is narrower—and that mismatch matters because it blurs what these tools are actually good for. In the stricter definition popularized by Andrej Karpathy and reinforced by Simon Willison, vibe coding means building software while effectively ignoring the code itself: generating changes, running the result, and only using feedback like errors to iterate—without reading diffs or treating the code as something to understand and maintain.

The distinction is central. Using AI to help write code—tab completion, inline suggestions, or command-based edits that still require reviewing what changed—doesn’t qualify. The term is reserved for workflows where the developer “forgets the code even exists,” often by hiding it in the UI, refusing to inspect it, and relying on the output (the running app) rather than the implementation. In practice, that can look like using an agentic editor to apply changes, closing files, and pasting error messages back into the chat with minimal context until the system “vibes” its way to a working result. The core claim is that coding and vibe coding are nearly opposites: AI can assist coding, but vibe coding replaces the act of coding with an output-driven loop.

That original intent is now getting diluted. The term is being applied to any AI code generation, and even to books with misleading titles—some promising “vibe coding” while actually describing responsible AI-assisted development for experienced programmers. The frustration isn’t just semantic. If “vibe coding” becomes synonymous with “using LLMs,” it stops being a useful label for a specific tradeoff: speed and low-stakes iteration in exchange for not understanding or maintaining the generated code.

Both commentators argue that vibe coding still has a legitimate place. It’s best for disposable, low-stakes projects where the cost of bugs is limited and where rewriting later is acceptable. The transcript emphasizes practical guardrails: avoid secrets like API keys, watch data privacy, consider network load and third-party API costs, and be careful with usage-based billing that can turn a quick experiment into a large bill. It also stresses that vibe coding shouldn’t be blamed for outages by default; the term is meant for throwing together things that don’t demand production-grade rigor.

Where the approach becomes valuable is learning and momentum. By collapsing “time to first success,” vibe coding can help more people reach that first “smile” moment—seeing a change work quickly—before they hit harder debugging. That lowers the initial barrier to building software, including for non-developers, and can serve as a gateway into deeper engineering later.

Ultimately, the transcript argues for keeping the term precise so it can describe a real workflow: not reading the code, iterating on outputs, and using AI to build quickly when correctness, maintainability, and long-term ownership are not the goal.