A ChatGPT mistake cost us $10k

Post by [deleted] » Tue, Jun 11, 2024, 1:23 PM UTC

ben_w wrote: post #19

chrisjj wrote: post #2

Thanks for telling. Bookmarked for the next time we're told ChatGPT's code error rate is acceptable because we review its code just like an intern's.

If you're treating ChatGPT code differently than your interns' code, you're going to miss some serious issues regardless of which one isn't under a spotlight. I had to fix some intern code once, and… well, I can't give too many details, but I will say that an FAQ shouldn't consist entirely of quotations from a TV show from a different country in a language the app doesn't support.

Post by randomdata » Tue, Jun 11, 2024, 1:35 PM UTC

owl57 wrote: post #509

randomdata wrote: post #468

Earlier quoted context omitted.

> it's collocating the idea of setup and cleanup together. Okay, sure, but Rollback is the cleanup function. You always want to rollback – you only sometimes want to commit. I suppose this confirms that someone got their logic mixed up.

> You always want to rollback This phrase highlights the confusion. If you learned SQL before Go, you want to rollback only on error. Every time I write `defer tx.Rollback()`, I cringe and have to remind myself that yes, it's actually ok to call a method called `Rollback` after succesfully writing data.

    BEGIN;
    INSERT INTO ...
    COMMIT;
    ROLLBACK;

Post by randomdata » Tue, Jun 11, 2024, 4:14 PM UTC

owl57 wrote: post #515

randomdata wrote: post #514

Earlier quoted context omitted.

If you learned SQL before Go, you'd know the pattern works just fine and is arguably a good sanity check. BEGIN; INSERT INTO ... COMMIT; ROLLBACK; It is not some kind of Go-ism. The Go database/sql package actually executes ROLLBACK in the SQL engine. Check out the error returned by it. Perhaps you mean learned SQL in the context of languages that consider a failed rollback an exception? In that case one needs to be…

> The Go database/sql package actually executes ROLLBACK in the SQL engine. No: https://github.com/golang/go/blob/beaf7f3282c2548267d3c89441...

Post by randomdata » Tue, Jun 11, 2024, 5:42 PM UTC

owl57 wrote: post #517

randomdata wrote: post #516

Earlier quoted context omitted.

Fair enough, although it wouldn't matter if it did. Nothing would change other than some unnecessary computation would occur. SQL supports it just fine. Anyone who learned SQL first would know that quite well.

Fair as well. It's just sending a command which you know will fail, and even relying on the fact it fails, feels wrong, whether it sends a request over network or not. BTW I checked and it's not an error in Postgres, only a warning. Still not something I would want in my database logs for the happy path.

Post by southernplaces7 » Wed, Jun 12, 2024, 8:48 AM UTC

vsuperpower2020 wrote: post #366

KennyBlanken wrote: post #352

Earlier quoted context omitted.

It's not some innocent mistake. The title is purposefully clickbait / keyword-y, implying that it was chatgpt that made the 'mistake' for SEO and to generate panicked clicks. "We made a programming error in our use of an LLM, didn't do any QA, and it cost us $10k" doesn't generate the C-suite "oh shit what if ChatGPT fucks up, what's our exposure!?" reaction. There's a million middle and upper management posting this…

>By definition they're not capable of "mistakes" because nothing they generate is remotely guaranteed to be correct or accurate. This makes no sense. Only things that are guaranteed to be correct or accurate can make mistakes? Everyone knows what "mistake" means in this context. Nobody cares what your preferred definition of mistake is.