“Vibe coding” is the style of development where you iterate quickly with an AI assistant: you describe what you want, the model generates code, you run it and maybe fix a few things, and you ship. It’s fast and feels productive. The downside is “slop”: code that works in the narrow case you tried but is brittle, inconsistent, or wrong in structure. You get to 80% of the way in 20% of the time, but the last 20% (correctness, edge cases, structure) can take 80% of the effort — or never get done.
The 80% problem is that the model is optimized for “what looks right next” not “what is right overall.” So you get duplicate logic, missing error paths, and design drift. Tests help but only for what you think to test. The structural issues — wrong state machine, flag conflicts, dead code — often don’t show up until production or a deep review. Vibe coding is great for prototypes and for learning; it’s risky for production unless you add discipline: review, structural checks, and clear specs.
Speed is real. The model can draft a whole feature in minutes. The trap is treating the draft as done. The fix is to treat vibe coding as a first pass: then refactor, add tests, and check structure. Some teams use the model for implementation and keep specs and architecture human-owned. Others use the model only for boilerplate and keep business logic and control flow hand-written.
Progress in LLMs will make the 80% better — fewer obvious bugs, better adherence to patterns. But the gap between “looks right” and “is right” is fundamental. Design your process so that the last 20% is explicit: who reviews, what gets checked, and what’s the bar for “done.”
Expect more tooling that helps close the gap: structural checks, spec-driven generation, and better integration of tests and review into the vibe-coding loop.
nJoy 😉