At this point, it’s safe to assume all net-new software is vibecoded. Who in their right mind would take a month to create an MVP when a bot can spit it out in an afternoon? Existing software isn’t necessarily immune, but there are still individuals that are fighting (or resisting the change) to keep their code base human readable. It’s a losing battle. Eventually those people are either gonna change their minds, leave or be pushed out. Then the agents will be unleashed upon those code bases too.
Saying "surely, <i>everybody</i> does X" is a sure way to be wrong. You're even spectacularly failing at making your own point by acknowledging in the very same comment that there are, in fact, people not doing it. Some people are different from you, deal with it.<p>That being said, it's true than we can assume <i>most of</i> new software are generated. No need for hyperbole on that. An interesting fact is that it makes grandfather's concern moot: people who are generating their code don't care much if a dependency goes unmaintained, they can have it replaced by an other one in matter of minutes.<p>There's an other objection to openai-cli we could raise, though: why use a generalist developer tool, containing probably hundred of features we don't need, when we could make a bespoke specialized version, perfectly fit to us, in like 25 minutes? I can get that there are audiences where this would not even come to mind to the users, but we're talking about a developer tool, here. The value of that is questionable. And ironically, those who might from benefit it the most are those who <i>don't</i> want to generate their code.
they didn't say "surely everybody does" they said "safe to assume all", when really what they should have said is "safe to assume any" meaning any that you encounter and consider using.<p>I think it makes sense as a reasonable heuristic going forward, assume the MVP was vibe coded or nearly vibe coded (a weeks worth of human / agent work together, then initial release)
Considering that "it's safe to assume everybody does X" while perfectly knowing "there are actually many people who don't, but who cares" is honestly kind of militant conformism. You can expect it without assuming.
You put it better than me
This is not unique problem to vibecoding. Google was killing products before LLM and forcing you into deprecation churn loop for years. Problem is companies without strategy trying things and then moving to next shiny thing.<p>I am still salty about anthropic killing Claude design in December.
There is a difference between wanton "vibecoding" and AI-assisted coding.<p>The latter still gives you many-X productivity improvement while the quality is pretty close to handwritten code.<p>LLMs are <i>still</i> not good enough where you can unleash it upon a huge codebase and get good results btw. Quality goes to shit once a context uses up around 50k-100k tokens. That's often only enough for one feature change and whatever validation the LLM wants to do for it.<p>It's fair to say that most new software is written with AI help, but that doesn't mean someone just prompted a few things and pressed deploy.
> Who in their right mind would take a month to create an MVP when a bot can spit it out in an afternoon<p>The people who need something more than an MVP, I would suppose. Bot sure does spit out a prototype faster than any human can, but actually building on that dogshit prototype becomes slower than someone with a clue writing by hand.
Yeah, but then you get the user's side. Will users really trust and rely on software that was vibe coded in an afternoon? Maybe for games, but for something like a CLI you would depend on - do you want to depend on someone's vibe coded in an afternoon project?
I don't know the answer. I suspect the answer today is yes for any "boxed" products like CLIs, desktop apps, mobile apps, simple client side apps, SDKs, etc. Complex services that have a livesite and deployment orchestration and numerous moving parts are still struggling, but everyone is pushing there too anyway.<p>As for users, I think it depends on the individual users. A lot of the time users abstract your software as a blackbox. It either works or it doesn't, and as long as you can fix it quickly and they get every bizarre feature ask answered quickly, that's all what some care about.<p>Personally, I have an all times low trust in the software I run. I used to cruise Show HN, /r/selfhosted, and GitHub Trending for cool new software to play with, learn from, or get inspired by. I don't anymore because I see what agents generate at work all day long.<p>There used to be this old joke among us programmers that we think it's insane that people trust their life to software when we all know how buggy it all can be. It was true, but also we knew that we can eventually get decent enough software. This is also out of the window now. Everything on all those places is a vibecoded thing generated in a couple of hours and no one knows what code is in there. It'll only get worse.
Sure they will. Case in point: Claude Code. I think its being vibe coded every afternoon, and indeed lots of programmers gladly take it with its various and often-changing quirks and small bugs. No biggie, it still gets the job done.
99% of people don't care, it's us programmers that are living in a bubble thinking that other people prioritize same stuff as we do. So yes, people won't care and will depend on someone's vibe coded apps, just like they use Windows, Adobe and whatnot even though those suck.
While I agree with the premise, I would argue with the conclusion. Yes agents can and do code fast. But if you're integrating software in business where people work in some patterns, more often than not there are "real life" happening. You learn that only by operating a system long enough to know these things. And competence accumulates, and the value of provider increases with the learned patterns. I think many devs live in tech world which is sometimes detached from physical world, world where people actually has to do some work, which takes time and system working in technical sense, doesnt work in practical sense.
This type of comments is making me insane.
I don't really know what to say tbh. I feel insane at times too but I'm being a realist and a pragmatist. I think I'm in the "changed their mind" camp because I got tired of fighting and can't deny reality. It <i>is</i> a losing battle. All approaches to manage changes in a traditional way also don't work. I have seen people who left because they can and I might follow suit too.<p>Like I think (or know) code reviews are also over. Someone asks me for a 10-11am brainstorming meeting regarding a concept they are working on, at 11:15 they have a "design doc" ready, at 1pm they ping me if I had a chance to review it yet, at 3pm I approve it, at 3:30pm they send a 7k line PR... "dude, that's not ok. I'm not reviewing 7k line change" so they say "oh yes absolutely sorry about that. that makes a lot of sense. Do you want 7 1k-line PRs? or 14 500-line PRs?" "hey Claude, split this into 10 commits and open 10 stacked PRs" :|
> Like I think (or know) code reviews are also over.<p>Whatever the size of code review chosen, merging totally unreviewed code to prod is still totally insane. There are a few AI code review products out there. The one I've used is fairly decent at picking out issues, though there's definitely some shortcomings vs a human reviewer with additional context (especially since not everything is written down for the bot to access). So I wouldn't say they are over. Even though the AI review isn't perfect, we all know human reviews aren't either.<p>As AI improves it'll be able to hold more of the codebase as context, enabling better, quicker reviews.
Whether code review is inportant or not probably depends on whether the problem someone is solving is important or not. But when it is important, I think we should be putting the onus on the person who filed the PR instead of burning our own neurons trying to understand volumes of stuff. Tell me what you asked the AI to do. Why is that a good idea? Once I hear that answer (because many junior programmer ideas don’t even get past that point), let’s look at the code together. Tell me why you think the code you submitted does what you say. Did you look at the code? Did you write tests? Did you check for test coverage? Maybe you’re a little smarter than that. Did you think through pre- and post-conditions? Corner cases? Are certain undesirable behaviors impossible? How do you enforce that? Types? State machines?<p>Even before slop coding good code review was hard, because verification is a hard problem. But we have many tools at our disposal to increase confidence without having to go full-on mathematical proof. Human understanding has always been the bottleneck, and as long as the thing you are doing is for humans, humans will have good reasons to want to understand it, so they will remain the bottleneck. This is ok. It’s ok for humans to be the rate-limiter. But don’t go it alone and fry your own brain.
Yeah but who writes totally unreviewed code nowadays? Everyone I know doesn't commit until a model has reviewed the code that another model wrote.
This type of comments gives me the impression that HN is riddled with AI marketing bots.
Most people are practical
Reality is making you question your sanity.<p>The comments are just accurately describing that new, insane reality.
There are different ways of using AI. Experienced software developers can easily still test their "vibe coded" app for most common bugs.
<a href="https://xkcd.com/1483/" rel="nofollow">https://xkcd.com/1483/</a><p>>Eventually all the people who hate this kind of thing are going to be dead, and the ones who use it are going to be in control.<p>The West has fallen.
There was a generation of programmers who obsessed about memory alignment, bit packing, SoA vs AoS, memory arenas, handwritten assembly, etc. For well over a decade now, a todo app would take 800MB in RAM, but it has really cool mark-done animation so people would use it. If it's slow on your machine, get the new i7 or M58 mac to experience this awesome todo app.
I'm so curious what you do when the providers go down. Do you tell your boss you can't fix the incident because your token quota is out?
Sort of, that's the mindset you get because you've no clue how the app actually works.<p>We have a 100% vibe-coding team, and yes, when they couldn't pass through the CI/CD at some point, they contacted the Ops team and literally said "the agent said the problem is on your side".
…yes? This is the equivalent of an electrician showing up to your house without tools.<p>It would be faster to setup a deepseek locally hosted instance or glm than try and build by hand, assuming all hosted providers were down somehow.<p>Which is to say, there is no token quota. If you run out you buy more.
How many times have you heard "we can't work because GitHub is down?". This has nothing to do with AI, and yes, it's commonplace.<p>Not to mention the "yes, there's a bug. We opened a ticket to the maintainer. Now we wait".
This reminded me my dad's story. "In highschool we used to tell our teachers we couldn't do our homework because lights were out." Take anyway you want.