I’d doubt they’d be using it past simply testing the technology and simple translation of customer support messages in spoken languages that they aren’t able to converse in.
They’re not beholden to shareholders, so they’re not incentivised to chase short term gains over long term sustainable profits, so they’re not pushed to use AI and rot out their own understanding of their own codebases from underneath themselves.
Vibe coding actually works now
Guess you missed this:
Interesting comments from lobste.rs IMHO:
19 upvotes link
Relevant issue: https://codeberg.org/ziglang/zig/issues/37402
Pending PR: https://codeberg.org/ziglang/zig/pulls/37417
6 upvotes link
Hate to say it, but LLM code review certainly would have caught such an obvious “accidentally quadratic” bug.
23 upvote response link
And we would have missed the community showing up, and having fun working together on a fix.
I think this is acceptable in a pre-1.0 language.
You’re not going to be good at it, at first. It probably takes a good 6-12 months to do it all correctly and most developers don’t actually learn how to do it all properly.
But here’s my cheatsheet if you actually want to spend the time to get really good at code review. Save this comment so you can keep coming back to it.
First, you need to relearn the programming side, making code in a specific way that has the capacity to be reviewed correctly. Don’t think about code made to accomplish a goal because you should already be able to do that. Instead make sure you understand what makes code easy to review by someone else.
Why: You may have been stuck in an environment where someone else was either fixing your mistakes for you (depriving you of your opportunity to get better at writing reviewable code), or you may have been in an environment where you were getting the wrong feedback.
How: Read this link: https://mtlynch.io/code-review-love, then read it again next week, and again the following week. Once you intuitively can make reviewable code, it’ll be easier for you to teach others how to make reviewable code (which makes your reviews easier to perform correctly).
Second: Learn how to actually give feedback in a way that gets things fixed.
How: Read this: https://mtlynch.io/human-code-reviews-1/.
Third: Don’t try to write or correct documentation before you understand the “Grand unified theory of documentation” Link: https://docs.divio.com/documentation-system/. TL;DR: Most programmers don’t understand that there’s actually four different types of documentation and assume that the kind that they right is what’s actually needed.
That goes into technical writing, which is another skill you need to develop but makes projects better as a whole, which makes it easier to review code.
Fourth (bonus reading material): antirez (the guy who made redis) went through his whole project and did a kind of census/retrospective on all the comments inside. It sort of accidentally turned into a good practical advisory on writing comments that actually mean something. Link here: https://antirez.com/news/124
Maybe you want your wedding website to look different to other people’s?
Unless you’re drawing a massive illustration or specifically going with a non-wedding themed wedding, there’s only so many variations you’re going to end up with.
Dude it’s 2026 not 2024. I know things are changing rapidly but that has been very obviously not true for at least 6 months.
Since this is such a cookie cutter argument, see last week’s response about the same thing: https://programming.dev/post/57569685/26396986.
You’re going to be shocked.
I’m constantly shocked at the bad code I get from other using the latest models. See one of my parent comments in the same linked comment, each of the four projects came from people using the latest models.
Why would you not reuse event pages for the next event?
How many times are you getting married? 😄
Let me fix that for you: How many times are people getting married?
The answer: Lots.
There are already wedding websites out there, in every variation possible.
Why reinvent the wheel when we have so many wheels that they’re treated as disposable?
I’d expect that the code would be almost exactly the same as other code that already exists, in which case, why not use that code?
Uhm, because it’s not the same? Why would I vibe code an app that’s almost exactly the same as an existing one?
Because a vibecoded app is going to be a ripoff of its training data anyway. LLMs can’t produce creative or novel works, all they can do is stochastically regurgitate what they’ve already seen in their training data. So why deal with risk of injection attacks hidden in the training data when you can just use the original source instead?
There’s not really any such thing as a one off web page.
Of course there is. What an absurd thing to say. A very obvious example is event websites, e.g. for weddings.
Why would you not reuse event pages for the next event?
Maybe it depends on the language but I’ve recently vibe coded two tools in Rust and I’ve skimmed the code and it’s perfectly good Rust. I would accept it in a PR - even if I was being as picky as I’d really like to be in reviews. I don’t think that would have been the case 3 months ago though.
I’d expect that the code would be almost exactly the same as other code that already exists, in which case, why not use that code?
I too love filling my code with things that silently reduce my understanding improving my code using stochastic prediction models trained on tainted data filled with hidden injection prompt attacks AI
I’d agree with you if the thing literally changing wasn’t the placement of the goalposts.
For .one-off web page that is true
There’s not really any such thing as a one off web page.
It’s eventually going to need to be updated or reused for something else.
The only exceptions being if your company goes under, force majure, or if you have something with the same requirements but choose to make the same thing again from scratch for no real reason , which is just being inefficient and unreasonable.
Also the latest models don’t even make a mess any more.
Yeah… I’m calling bullshit on that, all four projects I was handed was made by the latest models and it will continue being an issue for the foreseeable future. (see a previous comment of mine for reasoning: https://programming.dev/post/57569685/26398217)
E.g. for one-off web page design it’s been good enough for a long time.
In just the last two months, I’ve been handed the following web projects:
navigate(), goTo(), and changeSlide()).I think the effect you’re seeing is that different people have different levels of “good enough”
I think the effect that I’m seeing is twofold:
It’s clear you have no idea what you’re talking about. […] You do understand that this is a rapidly developing technology right? That it’s getting better weekly?
This is literally the retort that moves the goalposts.
You can’t just bury your head in the sand and tell yourself that LLMs are still just “advanced autocomplete” anymore.
I made no claim that LLMs haven’t changed, I make the claim that others are making claims that fall apart once examined.
The claims others make:
AI is amazing because now it can make this thing
Oh, the only reason doesn’t hold up to scrutiny this one time is because of {insert goal post moving here}.
Argument 1 falls apart when looking inside the product (i.e. the shit sandwich, the slop grenade, etc…).
Argument 2 is circular, so I’m not going to waste time on it.
But just for the sake of argument, lets say there’s some sudden release of a model tomorrow that runs one million times better than today’s best model and everyone only uses that model from now on. Will I still be handed a shit sandwich?
Yes.
Why?
Because the fact that I’m handed a shit sandwich isn’t influenced by how good the model is. It’s based on the fact that English is a terrible language for logic.
We discovered this in the 60s and 70s. Computer programming was too hard in the 50s and only getting harder, so everyone got together and tried to make a programming language out of English, that way everyone could do it. That’s literally how the Cobol language came to be. It was sold to everyone on the idea that anyone could create something with a fuzzy human readable language called English.
What did we learn? English is both a terrible programming language and a terrible specification language, Non-programmers (managers, general workers, etc…) fall prey to things like the xy problem, understanding gaps, intention gaps, etc… and so can’t end up with a new good product by giving orders. The scars of that delusion are still felt in our banking system today. Every lesson learned by Non-programmers in the goal of getting a good program turns them lesson by lesson into programmers, and at that point you’re just programming by hand anyway.
The same lessons were rediscovered in the 80s by people trying to program by spreadsheets and GUI-only app builders, the 2010s with the no code movement, it’s currently being rediscovered in the 2020s with LLMs, and it’ll be rediscovered again by a new generation in the 2040s once those with the experience and learned wisdom of last time retire out of the industry and the few remaining are outnumbered and dismissed as religious zealots.
I responded in the other comment
“You’re not using the latest model”, “You’re holding it wrong”, etc…
It’s the same shit, different day.
I’m consistently told LLM generated code is the best thing since sliced bread, and people keep handing me “proof”, yet every time I open what they’ve handed me, I see a shit sandwich.
And as soon as I point that out, the goalposts are moved yet again, ad infinitum.
That’s right, move those goalposts!
The worldview section was interesting
The AI section is expectedly disheartening
The hobbies section was awesome
Edit: Spelling
Did you mean something else? fill is only for svgs.
But my personal variants are: outline: 3px solid red; and outline: 3px solid #F0F; just because they are such obvious debug/programmer-art colours
border: 10px solid hotpink;
This should be: outline: 10px solid hotpink;.
Borders are calculated as part of the layout, so adding or changing a border also means potentially changing the layout. So just by trying to debug something, you’re potentially making the problem worse. It’s a heisenbug.
On the other hand, outline doesn’t change the layout, it’s drawn around the element. Also, you can usually see what the border was on the element which makes it easier to debug all that nested div slop that bootstrap/tailwind vibecoders like to produce. And, you can also offset the outline if you need to also see the borders of elements touching the one you’re trying to debug.
It depends.
To be more specific, they are massive productivity enhancers over the short term with the trade off being lost productivity over the long term. If your scope is going to be over the long term then using LLM tools is going to be a net negative benefit.
A single small scope disposable project however might be more productive to be vibecoded as the negative effects to the coder (e.g. cognitive debt, skill atrophy, etc…) can be overcome by paying off that debt and reinforcing acquired skills in the next project with thinking through challenging problems and hand coding a larger project.
But you need to take care to make sure it’s a one off, otherwise you open yourself up to compounding those negative effects. The real danger is the productivity boost from one small scoped disposable project is psychologically seductive and you risk yourself falling into a cognitive surrender / death-spiral. We already know it uses the same pathways as those found in gambling and drug addiction so caution is definitely warranted.
This can work, but it’s easy to get it wrong.
Online competitive gaming suffers a similar problem: If all your opponents are bots or cheaters, then the game is no longer fun and players leave.
The best solution we have for that is shadowbanning. When a user is found to have been cheating, only match them with other cheaters, and don’t tell them. But that doesn’t work in source forges where bad users can tell they can’t communicate with everyone.
The next best solution is to make it expensive to be a bad actor. Make it so that to participate, you need a paid account (usually a small $5 fee). Bad actor’s accounts are banned and to participate again, you need to jump through the hoops of purchasing a new account. This is used in gaming with purchasing subscriptions (where the credit card number is blacklisted), or by tying a phone number to the account which is sent a validation text message (where the number is blacklisted). This is also used by phone app stores to combat spam app submissions.
It’s not a perfect solution, but it’s effective.