jamescostian

> with zero human checking of AI outputs

It can be hard enough for humans to just look at some (already consistently passing) tests and think, "is X actually the expected behavior or should it have been Y instead?"

I think you should have a look at the abstract, especially this quote:

> 75% of TestGen-LLM's test cases built correctly, 57% passed reliably, and 25% increased coverage. During Meta's Instagram and Facebook test-a-thons, it improved 11.5% of all classes to which it was applied, with 73% of its recommendations being accepted for production deployment by Meta software engineers

This tool sounds awesome in that it generated real tests that engineers liked! "zero human checking of AI outputs" is very different though, and "this test passes" is very different from "this is a good test"

Many iOS users use the Messages app to send and receive text messages which can be trivially backed up to iCloud but not other cloud storage solutions. Among people who text (common in the US) I'd imagine there aren't many iPhone users with less than 5GB of data stored in iMessages

That said, you can back iMessages up to a computer and back up files on your computer. You just can't restore iMessages to different Apple devices like this, but now we're talking about minor grievances to a really tiny segment of the population

> you'd be an idiot if you don't mass apply using your resume. Everyone does it, so you have to as well.

I've been on the receiving end of mass applications. If you stopped justifying your spam behind "everyone does it" (no they don't) and started tailoring your applications, leaning on your network (or building one up) you may need a lot fewer.

I have never mass applied, so I may seem idiotic to you. But even during the times I quit a job before looking for another, I've never been on the market for more than 2 weeks.

Georgia the country has about half the land of Georgia the state in the US, and Georgia the country has about half the population of Atlanta alone (even less population when compared to the entire US state of Georgia). I think that huge difference in popularity contributes largely to why "Georgia" often refers to the the US state on this site

I think a lot of really smart people end up claiming something like "this whole system wasn't designed properly, we can do it way cleaner if we redesign it from the ground up" but it's always a trap. Incremental improvements take less time, can be more easily understood, are safer to deploy. But a lot of those really smart people have perfectionistic tendencies that cloud their judgement, and nobody can imagine all the different paper cuts that will get in the way of their beautiful vision. And thus, the new technical debt (to someone else) is written

Perhaps something that could you help is adding an H1 to the readmes like "This project is finished, not being developed", with some explanation like "Unless you found a security vulnerability, your issues and PRs may be ignored or receive delayed responses. Feel free to fork this repo if needed. Please do not ask if this is dead."

This clarifies your stance so well that people acting in good faith won't bother you, and anyone who does bother you very likely isn't acting in good faith - easy to ban.

Plus, when you see someone ask questions about your project and interpret them as "a bulleted list of the reasons I suck", it implies that on some level you think "I suck because I'm not giving these projects more of my time". Giving that kind of disclaimer might help you move away from that mindset, and instead feel more at ease with yourself. Your contributions should be celebrated (as the person with those bulleted points did!), and anyone acting in good faith can appreciate them and fork if needed

I've seen apps break in prod where third party libraries had array accesses on indices that didn't exist, or dereferenced nil pointers, in goroutines they spawned. And those aren't the only ways to cause a panic without ever calling the panic function.

Third party libraries have bugs sometimes, and other times our usage of them can create bugs. Nothing like a SIGKILL or anything malicious. That's just the way things are and will be. And breaking down like this in dev can be fantastic!

But when a once in a blue moon issue crops up in prod and all other connections are dropped, the fact that a simple defer+recover couldn't have been preemptively placed on all goroutines is a huge nightmare. I'd even take a "you can add defer+recover for any goroutines created further in this callstack" - it's rare that libraries spawn goroutines, I'll already know which ones to trigger that behavior on

> This might mean you can't use TheTradeDesk and Google Adsense en-masse for example. Basically, as of today, a lot of price discovery is now automated by a majority of companies using a handful of vendors for this.

IANAL but this seems incorrect. Price discovery is one thing, being contractually obligated to keep prices at a certain level 80% of the time is another. A court can make a ruling about that 80% number in the contract without saying anything that impacts one's ability to discover the prices competitors charge

It could be your router giving it a new IP address, but the printer itself hopefully has a static MAC address. Check your router settings for static IP assignment, they may be under a section called DHCP. Over there you could give it a static IP address for its current MAC address

EDIT: this comment no longer makes sense after the parent comment was edited. It used to be explicitly asking for help and didn't mention any solutions like static IPs, nor did it spell out a general remark about how this complexity in consumer electronics is bad

This isn't designed for anyone to pour their heart and soul into it. Contestants are to make a "lightweight" (their word) game. They added a ceiling (to varying degrees) not just to the payout, but also to the submissions

1. You can just use `export type Foo = z.infer<typeof fooParser>` in one place and then import Foo everywhere else, without using z.infer everywhere else

2. Use let and modify your types as new ones become available - union them with a new object that contains the new property you need

3. How often are you making recursive types?

I agree that all of this could be made easier, but zod is the best we have and great for most normal usage. The reason TS doesn't want to make this available at runtime is that it means so many changes they make will become breaking changes. Perhaps one day when there's less development on TS we'll see this get added