The "right way" to vibe code (engineers, please watch)

Vibe coding isn’t a shortcut to skipping engineering—it’s a way to skip the parts of engineering you don’t need to keep. The core claim is that “vibe coding” works best when it’s used to generate throwaway, legacy, or low-stakes code (prototypes, one-off scripts, UI scaffolding, quick utilities) that solves a real problem without demanding deep ownership. When that same approach is applied to production-critical systems that require careful debugging and long-term maintenance, it predictably collapses—because copying code without reading it can’t replace engineering judgment.

A major obstacle is that people use incompatible definitions of “vibe coding.” Some mean plain-English prompting that writes code without developers reading it; others mean ignoring code entirely; others mean non-developers generating code via AI; and still others mean simple autocomplete inside an IDE. Those modes sit on different points of a spectrum: how much the user understands and how much they actually read the code. The transcript argues that most arguments about vibe coding fail because participants are talking past each other—criticizing “tab completion” while defending “agentic coding,” or dismissing “prompt-only” workflows while assuming they’re the same thing.

The speaker draws a sharp distinction between agentic coding and vibe coding. Agentic coding uses tools to inspect a codebase and propose changes, but vibe coding is defined as what happens when the developer doesn’t meaningfully read the resulting code afterward—copying error messages into a prompt box rather than tracing the underlying logic. Under this lens, the “right way” to vibe code is not to treat it as a replacement for engineers, but as a productivity tool for the large fraction of software work that is inherently disposable. For every line that ships, many more lines are written, tested, and deleted; vibe coding fits that reality.

Several examples illustrate the sweet spot: generating an SVG-to-PNG converter for video editing workflows, building small browser-based utilities, and creating quick tooling for content pipelines and benchmarks. The argument is that these tasks are often solvable with code, but not worth the time and attention required to design and maintain a polished solution. In those cases, vibe coding helps ship useful outcomes faster—without requiring the developer to become deeply invested in the generated implementation.

The transcript also tackles the “dependency” critique. It argues that developers who dislike package sprawl should not be surprised that vibe coding can reduce external dependencies by generating tailored solutions instead of installing generic libraries. Still, it concedes that vibe coding can create its own maintenance risks: if the generated code needs changes later, developers may have to rewrite or patch it anyway. That’s why the speaker insists vibe coding should not be used to compensate for not knowing how to code. The real danger is emotional: tools can make people feel unblocked without learning, creating a long-term skill gap.

Finally, the manifesto rejects two extremes. AI tools won’t eliminate the need for engineers; better tools can make the same experts more productive, not replace them. Likewise, dismissing AI as useless ignores the practical value of generating code you don’t want to read—especially when the goal is to solve small, annoying problems quickly and throw the result away when it stops being useful.