diek

Iridium exists today, refreshed their constellation with Iridium NEXT just a few years ago, and was just bought by Rocket Lab for $8 billion.

(disclaimer: my Dad worked there for years)

> But they don't help much to create logical units, with intuitive boundaries, good cohesion etc.

Completely, 100% agree on these exact points. I have access to every frontier model at work. None of them write what I would call clean code. At work the teams that have gone fully vibe-coded have repos full of broken abstractions that just accumulate over time. Eventually most of the effort of the team and their AI tokens seemingly goes to fixing issues that then break other things. Any attempt at 'refactor this mess, make no mistakes' turns into a _huge_ churn of changes ("shuffling the deck chairs") without ever really fixing things.

I find it funny that the original complaint was: "AI made a mess of the codebase".

Your response was: "Well you're not doing it right, but these hermes devs know what they're doing".

But the blog post you linked to shows their prompt, which is:

> I want god files broken up. I want simplification across the board. I want unification of helpers and methods that can be reused. I want less if-if-if-if-if-if-else routing. I want code legibility up. I want interpretability of the codebase and how things connect to each other up.

So it sounds like AI made their code a mess too. They then tried to make the point of how much money they saved cleaning up the code with AI, that AI made a mess of to begin with.

And if you look at the merged PRs on that project, a ton of them are bug fixes... to the code the AI wrote. And that's been my personal experience too: AI creates a huge amount of churn in a codebase. Just vast amounts of PRs fixing code that the AI itself wrote.

> One caveat worth stating up front

> Here’s the actual difference, side by side

I realize the author put a disclaimer at the bottom that they used AI for styling, but having to wade through this stuff at work all day my brain now actively rejects Claude-isms in prose.

That's a fair point, using 'interpreter' specifically was imprecise language on my part. My main point was php-fpm is developed by the core PHP team and is often the default in how PHP projects deploy these days, and that CVE was very similar to the recent 'fail' LPE vulnerabilities in the kernel.

My first reaction was, "watch, they're going to replace actual rigorous educational institutions with religious colleges" and lo and behold, "Liberty University" is at the top of the list for replacement civilian institutions.

You're correct. If you have:

  public int someField;
 
  public void inc() {
    someField += 1;
  }

that still compiles down to:

  GETFIELD [someField]
  ICONST_1
  IADD
  PUTFIELD [somefield]

whether 'someField' is volatile or not. The volatile just affects the load/store semantics of the GETFIELD/PUTFIELD ops. For atomic increment you have to go through something like AtomicInteger that will internally use an Unsafe instance to ensure it emits a platform-specific atomic increment instruction.

They made the Bolt EV from 2016-2023, and they're revamping it to use the new Ultium platform.

You could buy a 2023 Bolt starting at $26,500, and they're great cars.