The Case Against Vibe Coding: Why Friction and Ownership Still Matter
The rise of "vibe coding"—the practice of using Large Language Models (LLMs) to generate software at the "speed of thought"—has been framed as a revolution in productivity. The promise is simple: remove the friction of syntax, boilerplate, and implementation details, leaving the developer as a high-level orchestrator of agents.
However, for many experienced engineers, this promise feels less like a liberation and more like a loss. The transition from writing code to "managing vibes" isn't just a change in tooling; it's a fundamental shift in how we interact with complexity, learn from failure, and take ownership of the systems we build.
Accidental vs. Essential Complexity
To understand why some developers resist the AI-driven approach, it is helpful to revisit Fred Brooks' seminal work, The Mythical Man-Month. Brooks distinguished between two types of complexity in software development:
- Accidental Complexity: The difficulties inherent in the tools we use (e.g., fighting with a compiler, remembering a specific API's arguments, or manual refactoring).
- Essential Complexity: The inherent difficulty of the problem being solved—the conceptual design, the architectural trade-offs, and the logic required to model a messy reality.
LLMs are incredibly effective at erasing accidental complexity. They can write a quicksort implementation or a boilerplate React component in seconds. But the danger lies in the belief that by erasing the act of coding, we are erasing the complexity of the problem.
Essential complexity—the hard work of designing elegant, maintainable systems—cannot be "vibed" away. When an LLM generates a working solution, it doesn't explain why that path was chosen or what the trade-offs were. It provides a result without the reasoning, leaving the developer to maintain a system whose architectural foundations they may not fully understand.
The Cognitive Value of Friction
In the marketing of AI tools, "friction" is presented as an enemy to be defeated. But for the practitioner, friction is often a vital diagnostic tool.
Learning Through Struggle
When learning a new language or framework, the struggle to implement a basic feature is where the actual learning happens. By bypassing this struggle with an LLM, developers risk a superficial understanding of the technology. As one commenter noted, solving hard problems is like training in a gym; it makes the developer stronger. Without that resistance, the cognitive muscles required for deep problem-solving atrophy.
Friction as an Architectural Signal
Friction also serves as a signal. When writing code becomes unexpectedly difficult, it is often a sign that the current architecture is wrong. The "pain" of implementation is a prompt to step back and redesign.
An LLM-driven approach encourages "coding through