Interesting comments from lobste.rs IMHO:

1. 19 upvotes link

   Relevant issue: https://codeberg.org/ziglang/zig/issues/37402

   Pending PR: https://codeberg.org/ziglang/zig/pulls/37417

2. 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’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:

• A page filled with bootstrap style div-soup
• A page filled with tailwind style class-soup
• A slideshow webapp that has duplicated state and three different ways to change slides (navigate(), goTo(), and changeSlide()).
• A slop-grenade of a chatbot interface for navigating a user through a flow chart, documentation of the flow chart, and documentation of the logic of the flow chart, all of which conflict with each other.

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:

1. People don’t realise that every line of code is a liability.
2. People think that once they have something on the screen that looks finished, the project is finished. They haven’t thought about support or maintainability at all, and since they are completely inexperienced about such things: they aren’t qualified enough to when when a project is “even done”, let alone “good enough”.

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:

1. AI is amazing because now it can make this thing

2. 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.

“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

• People 30+ years old tend to consider good health more important than other factors in their own happiness
• It’s eye opening to see how many people right-leaning people don’t care about climate change or rising authoritarianism. I wonder if this is linked to the adage that people who don’t care about things happening to other people until it happens to them tend to lean right, or if it’s more of a consequence of being exposed to an increased amount of propaganda from oil producers.
• It’s curious to only see 33 users out of 5463 self-report as far right, is this due to people on the far right not trusting surveys, not wanting to take part in surveys, or is the survey just not getting to them.

The AI section is expectedly disheartening

• A supermajority agree that AI is not making their mental state better
• It’s completely expected that people who hate AI don’t use it, and that people who love AI use it
• It really valuable to have some numbers on emotional states sorted by AI sentiment:
  • Pro AI folks are mostly curious, but notably excited and overwhelmed at the same time
  • Anti AI folks are mostly exhausted and disillusioned

The hobbies section was awesome

• People really like games, tv/movies, and reading
• A lot of folks like walking/hiking
• A lot of gamers like RPGs and survival
• Book readers are really into sci-fi and fantasy

Edit: Spelling

That’s not how a brain works.

People forget the language they grew up reading/writing/speaking simply because they stopped using it.