Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A ChatGPT mistake cost us $10k

asim.bearblog.dev

Post reply on HN
Print view View original

411–420 of 526 posts

Re: A ChatGPT mistake cost us $10k

#411

Post by Kesty »

Terretta wrote: post #99
userbinator wrote: post #21

Earlier quoted context omitted.

It read like no one really knew what they were doing. "We just let it generate the code and everything seemed to work" is certainly not a good way to market your company.

> It read like no one really knew what they were doing. "We just let [devs] generate the code and everything seemed to work" is certainly not a good way to [whatever]. Except, have you met startup devs? This is by and large the "move fast then unbreak things" approach.

The idea of moving fast is to have extensive logs and alerts so you fix all error fasts while they appear without "wasting time" with long expensive tests in a phase where things change every day.

5 days to find out you have "duplicate key" errors in the db is the opposite of fast

Re: A ChatGPT mistake cost us $10k

#412

Post by aforwardslash »

primitivesuave wrote: post #314

I spotted the error instantly. With all due respect to your team - this has nothing to do with ChatGPT and everything to do with using a programming model that your team does not have sufficient expertise in. Even if this error managed to slip by code review, it would have been caught with virtually any monitoring solution, many of which take less than 5 minutes to set up.

This. And it seems the team wasn't able to do basic troubleshooting from either database or application log. This was a simple error - what will happen when transient errors (such as implicit locks on tables, etc) occurs. These guys shouldn't be writing code - at all.

Re: A ChatGPT mistake cost us $10k

#413

Post by gnfargbl »

KennyBlanken wrote: post #374
patates wrote: post #360

Earlier quoted context omitted.

Could they have deleted it because of all the negativity? They did make a silly mistake, but we are humans, and humans, be it individually or collectively, do make silly mistakes.

If you code for a hobby/fun, yeah, sure, it's a silly mistake. If you're earning past six figures, are part of a team of programmers, call yourself an professional / engineer, and have technical management above you like a VP of Engineering, yadda yadda....then it's closer to systematic failure of the company's engineering practices than "mistake." There is a reason we call it software engineering , not software fuck…

I agree, but in fairness, engineering mistakes do happen all the time, in every organisation. A good engineering culture enables mistakes to be acknowledged and reviewed in an emotionally neutral manner, ideally leaning to a learning experience.

Being on the receiving end of an internet pile-on of "OMG you idiots everyone knows the first thing you do when setting up a flerble cluster is spend a week installing grazoono monitoring!" is not conducive towards building a good engineering culture.

Re: A ChatGPT mistake cost us $10k

#414

Post by Kesty »

cuppypastexprt wrote: post #321
beala wrote: post #295

Earlier quoted context omitted.

The StripeCustomer table has the same issue. There's both an `id` column and a unique `customerId` column. Presumably the `id` column is useless and could be removed. Also, is there a way to set up foreign key constraints on `userId` with this ORM? That seems like another oversight.

In that blog they say they have now added very robust unit and integration tests, so I don't think this is an issue.

The conclusion of the blog are not great either.

Sure you should have tests, sure you shouldn't copy paste code you don't understand and you shouldn't push directly to production.

But, regardless of all that, the main issue of all this incident is not the rookie mistake itself, is how they didn't have logs or alerts and it took them 5 days of customer complaining to find out they had "duplication errors" in the db.

That's the thing that should have been fixed first and extensivly mentioned in the post-mortem

Re: A ChatGPT mistake cost us $10k

#415

Post by HenryBemis »

jnsaff2 wrote: post #392
KennyBlanken wrote: post #374

Earlier quoted context omitted.

If you code for a hobby/fun, yeah, sure, it's a silly mistake. If you're earning past six figures, are part of a team of programmers, call yourself an professional / engineer, and have technical management above you like a VP of Engineering, yadda yadda....then it's closer to systematic failure of the company's engineering practices than "mistake." There is a reason we call it software engineering , not software fuck…

This is how I felt when a Gitlab employee deleted the production database by doing it in the wrong terminal window.

what phist wrote. Color code the backgrounds of your servers, different colors. So anyone who connects to 'take console' in any system is hit by a blinding electric Green/Blue/Red/Yellow and other striking colors.

I assume that all systems already have descriptive names App_DEV_Server1, App_PROD_Server5, etc.

It also helps if (ofc they would be right??) in separate IP groups/WLANS?

If you are running Windows, it's a good idea to use BGINFO.exe by SysInternals (or Winternals as we old people still call it), and display the most relevant info (showing Dev/Prod/UAT/etc.) with big-big-big letters.

Re: A ChatGPT mistake cost us $10k

#417

Post by throw156754228 »

nicce wrote: post #86
brigadier132 wrote: post #78

Earlier quoted context omitted.

There is no vendor lockin with nextjs

Simply put - if you want get the best out of the framework, you need to host it in Vercel. Otherwise, there are better options for frameworks. No need to ”fight it”. You will find many issues from GitHub which are not considered because they would make the framework ”better” or easier to use on other clouds.

>there are better options

Do you mind naming some NextJS alternatives without potential vendor lock in? Mulling a change in my fe.

Re: A ChatGPT mistake cost us $10k

#418

Post by faizshah »

treflop wrote: post #312
faizshah wrote: post #289

Earlier quoted context omitted.

This sort of process failure is why there’s a Correction of Errors (postmortem) process at Amazon: https://aws.amazon.com/blogs/mt/why-you-should-develop-a-cor... Specifically asking why did it take so long to detect and why did it take so long to diagnose is useful in these situations.

I’ve seen two types of people approach problems: Type 1 tries to find the error message and figure out what it really, really means by breaking down the error message and system. Type 2 does trial and error on random related things until the problem goes away. I hate to say that I've seen way more type 2s engineers than type 1, but maybe I’m working at the wrong companies.

The way you want to build and lead an engineering team is so that the individual engineer’s approach to the problem doesn’t matter. The idea is to establish deployment safety and ops mechanisms so Type 2 isn’t even possible and your Sr. Engineers coach the jr. engineers in how to use these mechanisms effectively through training and runbooks. The idea of COE is to figure out what mechanisms (availability tests, metrics/alarms, logs, unit tests) were missing so that you can fill those gaps.

Re: A ChatGPT mistake cost us $10k

#419

Post by miyuru »

clpmsf wrote: post #110

It seems YC is trending younger with this AI wave (I believe average age of the most recent batch was ~26) - kids dropping out of college to build startups without ever having worked at a real software engineering job... I imagine this type of story is not at all uncommon at the moment.

I got the same information going though the company LinkedIn.

Seems like YC in line with the rest of the world, slap AI on anything and boom there are VCs and cash.

Side story: The company I work for even change the company domain from .com to .ai. Cannot wait for the AI bubble to burst.

Re: A ChatGPT mistake cost us $10k

#420

Post by throw156754228 »

jowea wrote: post #174
Lunrtick wrote: post #59

Earlier quoted context omitted.

They could also have done default=uuid.uuid4 to have a new id each time, or default=lambda : str(uuid.uuid4()). It's not really related to whether or not it's a database default. It seems quite unfair to place the blame on SQLAlchemy here, or even Python. Even a statically typed language wouldn't prevent this kind of issue - the author of the code is the only person who can decide when they mean "use this exact strin…

I could imagine some sort of static analysis saying that using a constant value instead of a function is a mistake for columns with unique set.

Exactly, this is an error that should've been picked up statically, before unit even.
Post reply on HN