Vibe Coding is not an excuse for low-quality work

What “vibe coding” Means (and How It Drifted)

  • Original meaning in the thread: let an AI write code, “accept all,” don’t read diffs, paste in errors blindly, keep retrying until it runs; explicitly for throwaway / weekend projects.
  • Many commenters note semantic drift: it’s now often used to mean “any AI-assisted coding,” which they argue muddies an important distinction.
  • Several propose a crisp boundary: if you carefully review, test, and can explain the AI’s code, that’s just software development, not vibe coding. Vibe coding is specifically “not reading/groking the code.”

Perceived Benefits and Legitimate Use Cases

  • Good for: prototypes, internal tools, weekend hacks, one-off scripts, quick integrations, or exploring feasibility (“how hard would this be?”).
  • Some consultants report big gains for small, frequently changing automation apps: they mostly write specs and review PRs, and feel quality has improved under tight budgets.
  • “Vibe debugging”: using agents to iteratively run builds/tests/deployments until they succeed, especially for tedious environment/config issues.
  • Many individual devs happily “vibe” on personal or low-stakes projects where “works on my machine” is acceptable.

Risks, Failure Modes, and Code Ownership

  • Core concern: loss of understanding. When things break and no one knows what the code does, debugging and maintenance become painful or impossible.
  • Reports of production bugs traced to blindly accepted AI code; parallels drawn to past Stack Overflow copy‑paste, but with organizational pressure and metrics now pushing AI usage.
  • Security and correctness risks: no tests, chaotic architecture, “accept all changes,” and management extrapolating toy gains to critical systems.
  • Consensus: the AI is never responsible; whoever merges the code is.

Quality, Maintainability, and Business Trade‑offs

  • Discussion of two “qualities”:
    • User-facing: few bugs, solves the right problem.
    • Internal: clarity, structure, ease of change.
  • Some argue only the first matters if AI can cheaply rewrite everything; others counter that maintainability is what enables user-facing quality in any nontrivial, evolving system.
  • Vibe coding is seen as tempting short‑term “energy saving” that pushes cost and pain onto future maintainers, successors, acquirers, and users.

AI Tools vs Human Developers

  • Strong disagreement over how good current models are: some say “any competent engineer” writes better code than current LLMs; others report high‑quality, one‑shot PRs on real codebases.
  • Specific complaints: verbose/messy code, hallucinated APIs, weak TypeScript/Drizzle handling, high failure rates for auto‑generated tests.
  • Broad agreement that today AI needs a competent human steward; fully autonomous coding is not reliable yet.

Culture, Craft, and the Future of Software

  • Some predict developers becoming “managers of AI agents” and major shifts away from large, monolithic products toward many small, bespoke tools; others are skeptical, citing complexity, moats, and maintenance cost.
  • Several express worry that hype, grift, and executive buzzwords (“future,” “penny per line”) will normalize low-quality AI‑driven practices.
  • Counter‑movement idea: “craft coding” — intentional, explainable, maintainable code, using AI as a coherence/automation tool, not as an excuse to stop thinking.