research - 2026-07-06

Vibe coding is useful. It is not a substitute for expertise.

A founder’s view on vibe coding: it can help with basic sites and quick drafts, but complex apps still need technical judgment, debugging, architecture, and review.

People keep asking the same thing: can I solve this just by vibe coding? And my honest answer is yes, sometimes you can — but only up to a point. For a basic site or a simple app, it often works well enough. Once the problem gets more specific, the gap shows fast.

The issue is not that the tools are useless. The issue is that access is not the same thing as expertise. Anyone can open a model and ask it to build something, but building something that is actually relevant, maintainable, and safe still takes judgment. You need to decide what the product should be, how it should be structured, and where the edge cases live. A prompt is not a replacement for those decisions.

This is where a lot of people get stuck. The model can suggest an implementation, sure. But when the app hits a bug, someone still has to debug it. If you do not know how to debug, you are done. That is the part people like to skip in the demo phase, but it is the part that matters the moment the product leaves the happy path.

The same thing happens with code quality and design. I still see people build something in real time with AI and then act surprised when the code is messy, duplicated, or impossible to extend. I’ve also seen a developer use vibe coding for an entire system, then come back later and realize they could not safely add the next feature because the structure was bad and hard to read. That is not a small issue. That is the system telling you it was never really designed.

Even with planning workflows, MCP, goals, and the newer tools, the quality still depends on the person steering it. LLMs continue the sequence of tokens you give them. If the input is vague, the output will be vague. If the structure is bad, the code will reflect that. The model is powerful, but it still needs direction, review, and someone who actually knows what good looks like.

My view is pretty simple: use AI for drafting, speed, and basic execution where the problem is straightforward. For real products, invest in engineering, product thinking, and review. There is still a threshold where experts matter. For anything messy, specific, or customer-facing, that threshold is not gone — it is just higher.