One of the use cases is to have a development db that can get data from production or staging (and doesn't send local changes back)
What I've done usually is have some script/cron/worker run periodically to get data, either via dump or running some queries, create a snapshot, store it in S3, then have a script on the local dev code that gets the snapshot and inserts/restores the data in the local db. This works for many cases, but index building can be a pain (take a long time), depending on the data
I've been doing that for years and really happy with the result.
But in reality there were many issues: - there was a culture of launching "project/initiative" to justify more hires and promotions, rather than improving on the key issues we had (that nobody wanted to tackle). - People were often switching team after a promotion, for example leading a new team, and leaving their problems behind. - On the technical-side it was extremely tedious to contribute, we started with a monolith, then moved a micro-service architecture (with k8s, kafka etc). There was a push to do things properly, but it translated in over-engineering parts (for the cool stuff) while the valuable not-so-cool stuff was left to rot. At the end we had to maintain multiple things and the engineering effort to do all these migrations was huge, and took us away from doing more valuable work.
Eventually the company couldn't sustain its workforce and we had multiple round of layoffs.
My key learnings are: - Unless you are looking for a promotion before leaving (pump and dump), hiring a lot of people in a short amount of time is bad. - Even in best scenarios, having more employees make things harder and slower. People are competing for projects, there is a need for more communication, more processes, more tools. Having a lean workforce as long as possible, focusing on what's really important is best. - It's okay if we can't do everything we want. Not so many "ideas" are valuable and employees cost - Before hiring for a new project, can't we move other resources? Is this project really important or just a distraction?
>What features could make it more ethical?
You should think the other way around, start with an ethical base, and only add features that keep it ethical.
Both for "when do you introduce in a supervised setup" and "when do you let them use in an unsupervised setup".
LLMs are new to us, but for them it's not more new than the rest of the internet. It can be harmful, but probably less than social media.