This why we get companies killing people through cost-cutting, because no-one does anything until they start killing people (and often not even then).
I guess I am the only one that seems to think that was heavily edited and mostly animated. I am not saying that it didn't happen but it didn't look like what we are seeing.
WRT union comment, that has no relevance to quality control. Actually there's very limited evidence to the contrary in other industries. Take cars for example: All of the models that UAW lists as the ones they manufacture score very poorly on reliability in consumer reports. That could also be poor engineering, but either way, it's unwise of them to claim that they produce quality cars when everyone but them says the opposite.
Software in particular -- compare software produced in the US against other countries, where developers in those countries are often union. It isn't even a contest.
Either way, I don't see any compelling real-world or practical reason to believe that unions will help your argument.
By time an hour would be needed we'll have to factor in the relatively different passage of time on various colonies and have a standard that accounts for timekeeping in different reference frames at least throughout the Solar System.
Hopefully
Somebody who works that out now and proposes a correct mechanism will have their name remembered.
However, you're missing the point the user, the poor bastard who uses the code and will have their credit card stolen, did NOT write/vibe code the thing.
Nor did they choose what libraries or other tools you used.
Saying "Oh it's the programmer's responsibility" is adding nothing to the discussion. We know it's the programmer's "responsibility".
Evidently not. You're literally making a big deal about what tools were used without any mention of whether they're used correctly.
Likewise it's the programmer's responsibility to not have buffer overflows in their code, but they still program that shit, which is why things like Rust, Go, and even Java and C#, are good things and why increasingly programmers want the applications they use to be written in those languages.
Go tell that to the C++ developers who refuse to care about memory safety. Pretty much every last one of them thinks they're incapable of creating undefined behavior, including the guy who created the language. These are bad engineers. You don't trust bad engineers. People who drive cars made by Volkswagen and/or Stellantis do so because bad engineering doesn't bother them.
Anyhow, rust is my daily driver language. I use it for everything unless there a compelling reason to use a different tool. Rust is a tool with many guardrails, so it's harder to misuse it. But just because a newer circular saw has a thumb guard doesn't mean you can't cut off your thumb with it.
Likewise, as someone who knows how the sausage is made, I don't want AI slop on my system.
I don't think so. LLMs are just another tool in your belt. You're talking as if misusing the tool is the tool's fault. Not vetting its outputs is definitely misusing it.
I don't give a shit that there might be a programmer that can herd that slop through a filter that might stop 51% of serious issues from occurring, because I don't want to be reliant on a deadline-meeting programmer being conscientious and quality oriented. How am I supposed to know?
You don't, and it's foolish to assume that the use of LLMs makes any difference here. And that's exactly why you don't just install every program you find on the internet just because it's given away for free. If you do, then you're misusing your own tool, namely your computer. You either trust the developer, or you don't, or you do your own vetting by running it in a sandbox to observe its first.
It's not like we're unionized. We have a terrible record on that in general. They're still finding security holes in Xorg, and that hasn't had any new development since 2010 in an attempt to cripple it so the "new stuff" would look better.
It may be the "programmer's responsibility", but that tells you nothing about the quality of the end product. The fact they felt slop coding was OK for the job though tells you everything about what kinds of programmers were in charge of this.
You're arguing here that merely using an LLM means the code quality is bad. Either that or you seem to be under the impression that bad developers can't produce slop without the use of an LLM at all.
Neither of these are true. If you aren't making these arguments, then what is the point of your post?
It's hard to properly test leap seconds because NTP tries really, really hard to not diverge from UTC. And your code might work fine but that doesn't matter when the JVM or operating system break underneath you.
If I remember correctly, there was a bug in Java which required updating Java to not crash. We worked around it by shutting things down a few seconds before and starting it again after seconds after.
One of the biggest problems with leap seconds is that it's hard to properly test them. We had to install special firmware on a GPS receiver and use that as the NTP source for our servers so we could command the GPS to insert a fake leap second to test them. I'm very happy that they're gone.
"Don't drop acid, take it pass-fail!" -- Bryan Michael Wendt
