Codex logging bug may write TBs to local SSDs

> I don't understand how Codex can blunder so badly. I imagine that even if they would be using vibe-coding, surely they must have some good engineers. So why is there such severe bugs?

Because it was deemed not Hard Enough task for real engineer to look at, so AI was sent to do it with no supervision, just checking the effects.

Also overly excessive logging is probably useful to them in chasing some of the edge cases, the cost to users doesn't matter in the slightest to them

This thread will become a typical "haha slop company made slop" but I've been bitten by a bug exactly like this before in a (pre-AI, artisan) OSS project. The maintainer there didn't properly account for DST when calculating last backup time, so the app started and never stopped writing/re-writing backups continuously.

Perhaps the framing shouldn't be "haha slop" but rather why doesn't the AI write better quality software than we do? To which the answer is obvious IMO -- even emergent properties can't elevate AI intelligence too far above the training dataset. So how do we get to superintelligent (or at least "not-wreck-your-NVMe-endurance-telligent") AI, if we, as a whole, are not smart enough ourselves?

Judge not the slop-bot, lest ye be judged yourself, engineer.

> I don't understand how Codex can blunder so badly.

because they trust the AI too much (and seem to be fin with acting knowingly negligent)

the problem is

- AI tends to produces very convincing looking code, even if fully wrong

- AI does mistakes of kinds no human would do, at least no human who is also able to write convincing looking code

- code reviews are hard, a lot of devs, including senior devs, put a lot of implicit trust into the co-worker behaving "sane and non malicious". But AIs behave sometimes not so sane and in a way (wrt. trying to be convincing). In the worst case in ways which if it where a human you might consider to be them trying malicious sabotage the product

Like a "dump" example from work:

- AI randomly removes a HTML element id while doing other changes in jsx/react

- the PR has a lot of changes, the id removal line looks innocent, like some on the fly cleanup

- human reviewers have the bad tendency to often not look too much at deleted lines, only if they need reference to how a new line was before (but it's only a deleted line and no new line)

- you don't expect humans to randomly without reason delete important properties of components when changing other things

- you maybe would still have found it, but it's a emergency fix for a production issue

- it happens to miss integration tests, but happens to still matter a lot for one specific important for complicated reasons not properly tested flow (similar people tend to not test logging too much, at best the presence of needed info but hardly ever the absence of noise)

Then they can apply a clean solve, the cleanest solution.

It's fascinating how offensive some of this verbiage becomes to you when you see it attached to LLM output too much.