Ask HN: How far has "vibe coding" come?

That is one of the strongest valid criticisms. Even if we ignore the possibility that the code that is vibed will be buggy and insecure, the real long-term problem is not having someone who understands the system. Almost every well maintained app has one or more people who grok the whole thing, who can hear a problem described and know right where the fix will be. They'll have a mental model of the whole system and can advise on architecture changes and other refactors. They can help teach the codebase to new folks. And most importantly, when an outage happens, they are the ones who quickly get you back up and running.

The lack of those people is why legacy systems are brittle and hard to maintain, so vibe coding a complex app puts you directly into that painful legacy maintenance mode.

One thought people are starting to throw out there is, "But the AI can just re-write the whole app every time we have a bug, so we never need to know things to that level." But those people have never worked with a customer base who gets ticked off when the same bugs re-appear on every release, or when a dozen small UI changes shows up on every release.

Vibe coding might give you some working code. But working code is an astoundingly low bar to set for actually building a product that pleases a customer base.

"If it worked for my use case and didn't work for yours, you're obviously just doing something wrong. That's the only explanation."

Now it's easier to traverse a live plan and to quickly make micro pivots as you go.

I also think that architecture needs to change. Design patterns that will help to provide as much context to the LLM as possible to increase understanding.

What actually happens is tiered understanding. I might vibe-code a utility function (don't care about implementation, just that it works), but I need to deeply understand data flow and business logic boundaries.

The 20k LOC weekend SaaS stories are real but missing context. Either the person has deep domain knowledge (knows WHAT to build, AI helps with HOW), or it's mostly boilerplate with thin business logic.

For complex systems, the testing point is key. AI generates code faster than you can verify behaviour. The bottleneck shifts from "writing code" to "specifying behaviour precisely enough that you know when it's right". That part isn't going away.

The people I see struggling aren't the ones who don't understand their code - it's the ones who don't understand their requirements.

What's cool about this is that, every time new engineer joins this wave, there are more interesting ideas coming and shaping the "vibers" industry.

In my day to day job, now I am worried, it will be very difficult to get a new job, because I vibe so much that I almost forgot to write code from scratch.

Examples:

* Hey Claude, increase mem usage from 500Mb to 1500Mb in production - fire and forget

* Plan mode: What kind of custom metrics can we add to Xyz query processor? Edit mode: add only 3,4 and 9. Later we will discuss 8

* Any other small changes I have...

I primarily became a manager of bunch of AI agents running in parallel. If you interview me and ask me to write some concurrent code, there is a high probability that I will fail it without my AI babies

They care about the business. If you want to be like them, start by caring far less about the actual code or how it gets made. They will bring in people later who do, who will clean up the vibed mess

*I'm generally not a fan of this, but you asked

My sense of using LLMs for coding is me feeling like a maintenance programmer even though the code is brand new and I'm debugging a LLM misunderstanding. Weird to be working on a 10k codebase that didn't exist a few hours ago and I'm now debugging it over the next 4 hours. Having it done around 16-20 work hours later is really strange.

For a larger, more complex system, the real barrier is understanding what needs done well enough that you can build something that can do it. (In my opinion, that has always been the real barrier.)