Vibe coding is that feeling when development suddenly becomes fast and fluid. You describe what you want, a language model helps generate the code, you tweak a bit, and you’re done. Coding takes less time. Features that used to take days now take hours or minutes.

That feels powerful, but it creates a new kind of pressure. When coding becomes this fast, there’s an expectation—sometimes from yourself, sometimes from others—that you should deliver more features. “If it only takes a short time, why not just build it?” Output becomes the focus. You produce a lot.

The problem is that you also get worse at prioritizing. When things move slowly, you’re forced to choose. You feel the cost of every feature. You ask: is this worth the effort? Is this more important than something else we could do? That natural friction forces you to decide and to say no.

With vibe coding, that friction disappears. When it’s easy to build, it’s harder to stop and ask whether something should be built at all. You end up producing a lot of software that few or no people really need. There are no clear boundaries on how much unnecessary software you can create, because it no longer feels costly in the moment.

The result is bloat. Costs. Trash. Slop. You get more and more features, options, and code paths that don’t provide real value. They clutter the product, make it harder to maintain, and slowly increase the long-term cost of development. What felt fast at the beginning makes everything slower later, because the product is weighed down by things that shouldn’t have been there in the first place.

When you’re constrained by having to move slowly, you’re forced to choose more carefully. You’re forced to prioritize. You’re forced to remove weeds early, or not plant them at all. That’s the hidden benefit of being limited: the garden doesn’t fill up with unnecessary plants just because you had the time and tools to plant them.

Vibe coding isn’t bad in itself. Using a language model to speed up coding can be extremely useful. The danger appears when speed removes the natural limits that used to make us think. If you don’t add any new constraints, it becomes very easy to produce endless amounts of software that nobody really needs.

The core challenge isn’t how fast you can write code anymore. It’s how good you are at choosing what not to build, even when building it would be easy.