Everything they make these days looks to be strongly vibecoded without a decent review or functional testing. This leads to basic avoidable bugs that annoy vast numbers of users.
Not only this, but when you point out an issue to them on GitHub, they have a history of blocking the reporting user instead of tackling the technical issue.
The comments are just accurately describing that new, insane reality.
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" :|
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.
As AI improves it'll be able to hold more of the codebase as context, enabling better, quicker reviews.
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.
When people rally agains AI, that is why. AI hypers think it’s about the actual coding. It is not. It’s about the understanding and what you built is logically sound, conceptually and concretely. The code aspect matters only for maintenance sake and verifying the logical structure.
Which is why good devs are burning out on this. The PR authors don’t care, management don’t care, so to not be between a rock and an hard place, you just LGTM the review. And then users are suffering with insane bugs.
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.
Which is to say, there is no token quota. If you run out you buy more.
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".
Not to mention the "yes, there's a bug. We opened a ticket to the maintainer. Now we wait".
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.
That being said, it's true than we can assume most of 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.
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 don't want to generate their code.
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)
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.
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.
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.
I.e. I think I could trust vibe coded software more if it had been version frozen to bug fixes only and used by a lot of people for a few months or so.
I am still salty about anthropic killing Claude design in December.
>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.
The West has fallen.
The latter still gives you many-X productivity improvement while the quality is pretty close to handwritten code.
LLMs are still 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.
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.
Let’s just say that both OpenAI and Anthropic strongly disagree with this, in theory and in practice.
It’s absurd, I have the latest OS version, a M4 MacBook, but the new app seems to be buggy as hell.
Is this the new software quality standard we should expect from a company that is worth billions (if not trillions)?
For a while, yes.
I love how people all pretend that they and most engineers are god like programmers. Sure, some people are really good. My 30 years of experience say that is like 5%, maybe if you are at google or a really good start up, that can creep up to 30-50%.
By far the majority of engineers are not elegant or even really craftsman like. Add to this that unless you are working on a pet project you are usually neck deep in something that has had teams working in it for years.
It creates situations where most engineers don't really know what the code base does below the surface area where they are making feature changes. So work gets cobbled on or patched in where people are comfortable making changes.
All I can say is I would much rather have 3 open Opus 5.5 instances than a team of 3 working for me if we are only talking about delivering high quality code. I don't think that is the only value of engineers, but I think we are at a point where the models have way exceeded average engineer ability. There are still tendencies for "compatability everything" and "don't rock the boat" in the current frontier LLMs that can create architectural issues, but if you know what to look for when working, it isn't generally an issue.
I mean just remember how mush everyone complained about buggy games or MacOs or whatever before LLMs even came around.
I am not implying that at all. All I'm saying is that humans can't keep up with LLM/agent rates of code generation but agents come, so what is unusable for humans is ok for LLMs.
And LLMs being required is very profitable to those who sell LLMs.
Never did I imply any bugs
Not at all. It's hard to keep up with lines of code per day, i.e. quantity.
It's not difficult for humans to keep up with the quality, and produce far superior quality code by writing it themselves or instructing an LLM what exactly to implement, down to each function's API surface (if typing is the bottleneck).
A lot of you people are forgetting that there's an engineering aspect to programming, and LLMs are really really really terrible at it out of the box.
Let's say you can let AI design and 3D print 1 large real-life bridge per week. Would you say that humans can't keep up? Or would you point out that there's a difference between what civil engineers do and what an LLM with a 3D printer does?
This was said about web technologies and crypto and every other hype cycle, and it's never been true at all. The vast majority of people are okay just picking something reasonable or a default, and sticking with it.
It's not difficult to imagine that pi.dev will be around in 10 years, and it's not difficult to imagine that vim, visual studio, vscode, linux and ext4 will still be around in 10 years.
I don't know what kind of massive innovation you see here. This is like flying cars; every couple years there's a demo of a flying car of some variety, some people immediately short mercedes, and 5 years later mercedes is still around, making slightly more modern cars than before.
If you really believe that the tech-news hype cycle reflects reality, I urge you to go solve an advent of code in a normal programming language, maybe that'll help get you back on track.
> it's never been true at all.
Like, at all? The problem with "never" is entire platforms get deprecated and people get laid off. So sure, you can have a job in $technology for as long as you've got that job, but if you get laid off but $technology is deprecated, you're in for a bit of a rough patch.
For reference, here's a couple of $technologies that, 10 years ago, you have gotten a job in, but if you were laid off recently, you'll have a tougher time finding a job in:
Apache Mesos -> Kubernetes. Xamarin (mobile dev). Hadoop -> Databricks. Ember.js.
(Not saying it's impossible, just that you said "never" and "at all" so you'd have to get really lucky.)