Live data from Hacker News

Codex logging bug may write TBs to local SSDs

github.com

21–30 of 296 posts

Re: Codex logging bug may write TBs to local SSDs

#21
post #14

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 sof…

1. I bet that developer only made that mistake one time in their life. Humans learn from their mistakes, LLMs don't. If you rely on LLMs to generate all of your code, you can expect to run into the same issues again and again.

2. "One developer somewhere in the world made a bad mistake one time, so this represents the quality of all software devs everywhere". Maybe they were just a bad developer? Bad developers exist. I have never written a bug that has destroyed my users' hardware, and I think that writing such a bug is completely inexcusable in an enterprise environment with software that will be shipped to millions of users, as Codex is.

Re: Codex logging bug may write TBs to local SSDs

#22
post #14

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 sof…

We've gone from "you're holding it wrong" to "the training data was bad because humans suck too". Difference is, humans learn from their mistakes.

Re: Codex logging bug may write TBs to local SSDs

#24

If something like this is helpful or necessary, that’s what ram backed tmpfs is for.

Using a RAM backed tmpfs would be a work-around as to not trash your SSD. It's doesn't fix underlying problem. It's incredibly poor design on OpenAIs part.

Re: Codex logging bug may write TBs to local SSDs

#25
post #19

The first of many bugs that are beyond the complexity of its authors, thanks to comprehension debt. Even with tests, the more complex the code base is, the more risky it is to vibe-code on it without introducing more bugs [0] and increasing the debt. Does not matter if the CI is green or if all the tests pass. It gets even worse if you can't explain the change / pull request or what the implications are after applyin…

There are going to be sooooo many consulting opportunities after this wave.

Re: Codex logging bug may write TBs to local SSDs

#26
post #10

Codex is one of the most infamous examples of slopware. Just having the window unhidden on my mac will cause it to use 100% of the GPU displaying the spinner message. THE SPINNER MESSAGE CAUSES 100% GPU USAGE ON AN MBP M5!! So any time you're waiting on the model (which is 90% of the time), your fans will be blasting (careful, don't use it on battery). The issue is on github and close to 6 months old. Probably since…

This was fixed long ago, if I'm thinking of the same bug. It was stuck in an inf loop all the time the codex window was open.

Re: Codex logging bug may write TBs to local SSDs

#27
post #14

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 sof…

1. I bet that developer only made that mistake one time in their life. Humans learn from their mistakes, LLMs don't. If you rely on LLMs to generate all of your code, you can expect to run into the same issues again and again. 2. "One developer somewhere in the world made a bad mistake one time, so this represents the quality of all software devs everywhere". Maybe they were just a bad developer? Bad developers exist…

> I have never written a bug that has destroyed my users' hardware, ...

Probably whoever (human or agent) originally decided to put TRACE logs into SQLite also thought---or reasoned---so. Maybe the decision was right at that time but the amount of TRACE logs have increased enormously. You will never know.

Re: Codex logging bug may write TBs to local SSDs

#29

Earlier quoted context omitted.

1. I bet that developer only made that mistake one time in their life. Humans learn from their mistakes, LLMs don't. If you rely on LLMs to generate all of your code, you can expect to run into the same issues again and again. 2. "One developer somewhere in the world made a bad mistake one time, so this represents the quality of all software devs everywhere". Maybe they were just a bad developer? Bad developers exist…

> I have never written a bug that has destroyed my users' hardware, ... Probably whoever (human or agent) originally decided to put TRACE logs into SQLite also thought---or reasoned---so. Maybe the decision was right at that time but the amount of TRACE logs have increased enormously. You will never know.

I love that we've moved the goalposts from "LLMs are better than artisanal software engineers" to "actually, shipping hardware-destroying bugs in production is literally unavoidable, nobody could possibly avoid doing it".

Re: Codex logging bug may write TBs to local SSDs

#30
post #14

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 sof…

What are your thoughts on the SNR of the linked GitHub issue threads? Consider the volume of comments posted and the substance of each comment.
Post reply on HN