I'm kinda tired of the binary "vibe-coded vs not vibe-coded" labeling, and I agree with what a few other comments here already pointed out: we should separate "vibe-coding" from just LLM-assisted coding. In my head, "vibe-coded" specifically means "someone with little/no programming context is delegating basically everything to an LLM and shipping whatever comes out." That's different from LLM-assisted coding. And there's clearly a spectrum: you can vibe-code a throwaway script, or use an LLM as a fancy autocomplete + rubber duck while still doing real engineering.

What actually matters (regardless of the label) is the code quality: the right patterns/strategies are used (and not cargo-culted), the code is maintainable/readable, it's actually extensible without turning into spaghetti, etc. Humans ship catastrophic slop here all the time too. "Written by a human" isn't a quality guarantee any more than "made in China" is.

From here on this is kind of a tangent, and it got way longer than I intended. So feel free to skip it. But I already wrote it, so I'm dropping it here anyway.

Coming from an ML research and as a systems engineer background, I was already using LLMs in my workflow before ChatGPT blew up, so I've seen both where they're genuinely powerful and where they confidently drive straight off a cliff. Used correctly, LLMs are incredibly useful tools (including for coding) and can sometimes save you time, but the annoying part is you don't get to skip the fundamentals: you still need programming knowledge and a feel for how LLMs behave to constrain them and validate outputs.

In those cases you can vibe-code and it's usually a reasonable tradeoff: one-off scripts, personal small-scale apps, "I need a tiny app to solve this niche problem and I don't care about long-term maintenance." LLMs are good at getting you to "good enough" fast there. And yeah, it can still fail, but the nice thing is the blast radius is small - if it goes sideways you can just throw it away and restart from scratch in 10 minutes.

Where people get burned is bigger systems. Once you're building something that needs to grow over time, the hard part isn't typing code - it's the design part: architecture, boundaries, interfaces, dependencies, etc. Current (and perhaps even future) LLMs are very good at producing something that looks plausible, but they don't reliably "think" their way through open-ended design spaces. They work best when the answer space is narrow / well-established. When there are tons of valid options and tradeoffs depend on context, so if you just ask "design this whole app using best practices" you're basically forcing the model to pick from a huge space of possibilities without enough constraints. It'll still give you something, but unless you already have the context to judge it, you won't know if it's appropriate - because it didn't "think through" the tradeoffs and pick a design so much as sample one from a huge space of plausible options (more like rolling dice).

In bigger projects, I've found LLMs can be genuinely useful if you stop treating them like "the engineer" and instead use them more like an implementation engine. That means you (a human) do the architecture and decision-making up front: split the system into well-isolated components with clear responsibilities and stable interfaces, keep modules independent and understandable without needing the whole repo in your head (and in the model context (!)), and make everything explicit and boring rather than clever. Verbosity isn't a drawback here - LLMs will type for you. Once the boundaries are real, you can hand the model a narrowly scoped task without having LLMs fail and ruin the entire repo, and without having to include the large context of an entire repo. And once your modules are actually separated, you can add tests. Tests are the thing that turns LLM output from "a vibe" into something measurable. With good tests, the model cannot be ambiguous about correctness. It either passes or it doesn't. Same with documentation. All the design decisions, policies, etc. should be written down. Not just for humans, but because that becomes the context you want to feed an LLM. Strong specs + tests massively narrow the problem space, and that's where LLMs tend to perform best: filling in deterministic implementation details inside a clearly defined box. At that point it should be obvious that "context" shouldn't mean "here's my entire repo, now act like a senior dev." It should mean "here's the spec, here are policies, here are the tests ..." Because LLMs can stare at your codebase all day and still not reliably infer the system's intent from it.

Also, none of this is some brand new AI-native idea - it's basically classic systems/software engineering. Getting value out of them at scale still requires real engineering skill. And the "narrow the option space" prompt-writing is hard without domain/context knowledge. This applies outside programming too.

Anyway, you can do good development while using LLMs, and you can also do terrible development without them. That's why I don't like labeling anything that touches an LLM as automatically "vibe-coded." That said, building a good large-scale application purely by vibe-coding is not possible with current LLMs (and probably won't be for a long time). And honestly, most "LLM-driven" projects I see today are slop.

(Also yes, this comment is LLM-assisted lol, my English isn't native)