107
'It's Literally the Gulag': Furious Meta Employees Speak Out on 'Soul-Crushing' AI Jobs
(www.ibtimes.co.uk)
this post was submitted on 15 Jun 2026
107 points (100.0% liked)
Work Reform
16656 readers
211 users here now
A place to discuss positive changes that can make work more equitable, and to vent about current practices. We are NOT against work; we just want the fruits of our labor to be recognized better.
Our Philosophies:
- All workers must be paid a living wage for their labor.
- Income inequality is the main cause of lower living standards.
- Workers must join together and fight back for what is rightfully theirs.
- We must not be divided and conquered. Workers gain the most when they focus on unifying issues.
Our Goals
- Higher wages for underpaid workers.
- Better worker representation, including but not limited to unions.
- Better and fewer working hours.
- Stimulating a massive wave of worker organizing in the United States and beyond.
- Organizing and supporting political causes and campaigns that put workers first.
founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I’m personally playing with the idea of putting together a POC to transition our “foundation” data warehouse from PSQL to a graphDB, because the extensibility and maintainability of our current system is fucking awful. Like, some upstream entity gets a version bump and there’s like 5 systems we have to go through and add columns to various tables (usually 2-4 such modifications in each workflow - and it doesn’t help how my manager fucking loves to slice work up so much that it becomes a massive pain to integrate, instead of telling one Eng “integrate this new data element” and have it done, soup to nuts, in a week or two across the whole ecosystem) and occasionally fuck around with joins and so on every single time there’s a new piece of data we want to integrate. And we have no capability to scan back historically and evaluate our holistic state at some particular time index, which can be really helpful for some applications.
Anyways, I’m fucking swamped at work so haven’t touched that at all, but I’ve wanted to explore that idea for well over a year and a half at this point.
I have little experience with graphdb, but a lot of experience with the pain you're describing. Maintaining schemas is a pain, maybe if you don't need the performance, you can go that route!
The thing that interests me about it is that it will be a lot more trivially interrogable by ML stuff (bespoke ML specifically, not LLM), which could glean an absolute shitload of interesting insights for us.
I am an enormous fucking Luddite for a whole swath of reasons when it comes to LLMs, but ML outside of that context can be immensity powerful when employed correctly.
For sure, my lab has been doing that for a long time.
How is graphdb more ML-friendly?
If you’re doing PSQL (or any typical relational DB flavor), there’s a lot more complexity in terms of understanding the shape of the data, what joins to what, how to optimize queries, etc. Graph DBs are gonna be easier for a model to explore, since they can just do stuff like “I want to see tests with samples that have reactivity to mutation ABC on chromosome 14 over a threshold of X”, which is a lot easier for an ML agent (or less experienced developer, or even a molecular biologist with limited CS/DB experience) to just intuitively evaluate correctly using the syntax of GraphQL than it would be trying to do a shitload of joins between 6 or 7 tables in PSQL.