[flagged]
Ask HN: How far has "vibe coding" come?
21–30 of 31 posts
Re: Ask HN: How far has "vibe coding" come?
#22Earlier quoted context omitted.
> You can tell LLMs to... and they may or may not "listen", they are non-deterministic and have no formal means or requirements to adhere to anything you write. You know this because they violate your rules all the time in your own experience
Sure but in my experience LLMs behave much more consistently than humans with regards to quality. LLMs don't skip tests because they have to make a deadline for example. And now we have LLMs that review LLM generated code so it's easy to verify quality standards.
At the same time, the LLM will, with some reliability, ignore the patterns or best practices in your code, or implement the same thing twice in different ways.
There are certain things they do, or don't do, that a human typically wouldn't, putting absolutes and anecdotes aside
Re: Ask HN: How far has "vibe coding" come?
#23I have been doing full stack web dev since 2003 and iOS apps since 2008. I do not write code anymore. At my day job I don't think I get more done over time because the code is rarely ever the bottleneck at that place. I do have more time to experiment and try things and say yes more to asks from colleagues.
Outside of work, I have just launched an iOS app I've wanted to build but has been outside my current skillset. I was able to "vibecode" this app in about 4-5 months.
The application has a tiny bit of moat because it involves a ML model (also vibecoded) trained on my own data set.
When I say vibecoded, I never reviewed or read code in detail. I really only ever saw snippets claude code shows here and there. I asked a lot of questions, much more than asking it to make changes. I only gave it high-level architectural guidance like "use MVVC", etc. I did a lot of manual testing and reading logs.
I won't name the app out of fear of shilling my vibeslop, or whatever, check my profile for the domain in an email address if you want to know more.
Re: Ask HN: How far has "vibe coding" come?
#24I have been doing full stack web dev since 2003 and iOS apps since 2008. I do not write code anymore. At my day job I don't think I get more done over time because the code is rarely ever the bottleneck at that place. I do have more time to experiment and try things and say yes more to asks from colleagues. Outside of work, I have just launched an iOS app I've wanted to build but has been outside my current skillset.…
I think this is exactly the kind of example I wanted to see, so thank you for sharing.
I was thinking about it yesterday and realized that it might actually be worth trying to switch my current project entirely to “vibe development.” That said, I still worry a bit that AI might change the structure or expand the code when all I really want is to tweak a single line or a few expressions—but I’m sure there’s a way to handle that.
Re: Ask HN: How far has "vibe coding" come?
#25I've 'vibe coded' some internal tooling apps and it feels like i've joined a new company and been given a legacy codebase to work on, despite it being a week old.
I just assume all the posts that claim they've got a 20k line project in a single weekend is just marketing spam.
Re: Ask HN: How far has "vibe coding" come?
#26From my recent experience doing a project that involved setting up AWS infrastructure with CloudFormation - a VPC, subnets, docker based lambda s, SNS, SQS, etc - and the code on top of it, it did perfectly with code but took some going back and forth with infrastructure as code
The first thing I did was keep everything as decoupled as possible with so it would be simple for Codex and Claude Code (I use both) to reason over. I work the same way when setting up my own repos.
I treat Codex/Claude as junior developers and I keep my hands on the wheel
LOC doesn’t matter if you have clean modularity
Re: Ask HN: How far has "vibe coding" come?
#27> Is “you don’t really understand the code, so it’ll hurt you later” still a meaningful criticism? 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 de…
Understanding the system and understanding the code is different. The “system” I just mentioned was “architected” by me just like I would have done in 2018 when I first started with AWS (but with 20 years of experience with coding).
I know what every module does (well Lambda in my case but I’m trying to be more generic), I know the abstractions, I know the business case, etc.
As a team lead/architect, even with other people writing code, I don’t know every line of code does. Claude code/Codex is just a junior/mid level developer to me
Re: Ask HN: How far has "vibe coding" come?
#28Earlier quoted context omitted.
Sure but in my experience LLMs behave much more consistently than humans with regards to quality. LLMs don't skip tests because they have to make a deadline for example. And now we have LLMs that review LLM generated code so it's easy to verify quality standards.
At the same time, the LLM will, with some reliability, ignore the patterns or best practices in your code, or implement the same thing twice in different ways. There are certain things they do, or don't do, that a human typically wouldn't, putting absolutes and anecdotes aside
Humans, with reliability, will ignore the patterns or best practices in your code and implement the same thing twice in different ways.
In 25 years I've never worked in a codebase where this wasn't true.
Re: Ask HN: How far has "vibe coding" come?
#29Earlier quoted context omitted.
At the same time, the LLM will, with some reliability, ignore the patterns or best practices in your code, or implement the same thing twice in different ways. There are certain things they do, or don't do, that a human typically wouldn't, putting absolutes and anecdotes aside
Humans, with reliability, will ignore the patterns or best practices in your code and implement the same thing twice in different ways. In 25 years I've never worked in a codebase where this wasn't true.
As a group or the same person under the same constraints
It's far to nuanced for generalities tbt
Re: Ask HN: How far has "vibe coding" come?
#30I'm a non-technical founder who built an entire SaaS frontend using v0 and Cursor over the past year. My experience might be useful here since I'm on the extreme end of "vibe coding" - I genuinely don't understand most of the code I'm shipping.
What surprised me:
1. The "you don't understand the code" criticism is real but misses context. I don't understand the implementation details, but I understand the system architecture, user flows, and business logic. That's enough to make good decisions about what to build next.
2. The iteration speed unlocks something new. I can try three different approaches to a feature in the time it would have taken to spec out one. This changes how you think about product development - you learn through building rather than planning.
3. The bottleneck moved from "writing code" to "understanding what you actually want." The conversations I have with the AI force me to be precise about requirements in a way I never had to be when just thinking about features.
Where it breaks down: anything that requires deep technical judgment about performance, security, or scale. I can build the feature, but I can't tell you if it will hold up under load or if there's a subtle security issue. I need technical people for that.
The "20k LOC weekend" stories are selection bias, but the productivity gains are real for certain types of work. The key is knowing which type you're in.
Source: non-technical founder who built a production SaaS frontend this way