Comment by locknitpicker

> Most things that people who don't know how to code want to build are not actually dead simple, and they often won't be able to articulate what they need very well.

I think it's wrong to frame vibe coding as something that's done by people who don't know how to code. Those who I see effectively vibe coding things tend to be staff- and senior-level engineers, who use it to speed up implementations while focusing on architecture.

What I see as the main obstacle to vibecoding at the moment is that vibecoding is mainly effective at greenfield development projects with little to no prior contrext, and that small-scope work over reasonably sized projects ends up being iterative, time-consuming, and with mixed results.

One of the factors I've noticed is that legacy projects gravitate towards messy, unstructured, poorly maintained projects. When these projects carry huge contexts that tend to be unstructured and inconsistent, coding agents have a hard time outputting anything that is worthy of the term "improvement".

Another issue with legacy projects is that maintainers often don't have the full picture of what the codebase does and is expected to do. They at best gain enough context to do tactical changes whose scope is minimized. Coding agents don't show the same concern, and often propose sweeping changes that can and often do introduce regressions. That's frowned upon tactical-minded programmers, who don't want the risk or the work of testing and verifying their changes.