> For the novice, it's great at unblocking and expanding capabilities. "Good enough" results from novices are tangible. There is no doubt the volume of "good enough" is perceived as very low by many.

For personal tools or whatever, sure. And the tooling or infrastructure might get there for real projects eventually, but it’s not currently. The prospect of someone naively vibe coding a side business including a payment or authentication system or something that stores PII— all areas developers learn the dangers of through the wisdom gained only by experience— sends shivers down my spine. Even amateur coders trying that stuff try old fashioned way must read their code and the docs and info on the net and such and will likely get some sense of the danger. Yesterday I saw someone here recounting a disastrous data breach of their friend’s vibe coded side hustle.

The big problem I see here is people not knowing enough to realize that something functioning is almost never a sign that it is “good enough” for many things they might assume it is. Gaining the amount of base knowledge to evaluate things like form security nearly makes the idea of vibe coding useless for anything more than hobby or personal utility projects.

> For large and complex codebases, unfortunately the effects of tech debt (read: objectively subpar practices) translate into context rot at development time. A properly architected and documented codebase that adheres to common well structured patterns can easily be broken down into small easily digestible contexts. i.e. a fragmented codebase does not scale well with LLMs, because the fragmentation is seeding the context for the model. The model reflects and acts as an amplifier to what it's fed.

It seems like you're claiming complex codebases are hard for LLMs because of human skill issues. IME it's rather the opposite - an LLM makes it easier for a human to ramp up on what a messy codebase is actually doing, in a standard request/response model or in terms of looking at one call path (however messy) at a time. The models are well trained on such things and are much faster at deciphering what all the random branches and nested bits and pieces do.

But complex codebases actually usually arise because of changing business requirements, changing market conditions, and iteration on features and offerings. Execution quality of this varies but a "properly architected and documented codebase" is rare in any industry with (a) competitive pressure and (b) tolerance for occasional bugs. LLMs do not make the need to serve those varied business goals go away, nor do they remove the competitive pressure to move rapidly vs gardening your codebase.

And if you're working in an area with extreme quality requirements that have forced you into doing more internal maintenance and better codebase hygiene then you find yourself with very different problems with unleashing LLMs into that code. Most of your time was never spent writing new features anyway, and LLM-driven insight into rare or complex bugs, interactions, and performance still appears quite hit or miss. Sometimes it saves me a bunch of time. Sometimes it goes in entirely wrong directions. Asking it to make major changes, vs just investigate/explain things, has an even lower hit rate.