No reason to be uncivil. It's a bit of a stretch to say that "clanker" is related to race in any way. Lots of slurs have nothing to do with race, you're projecting your own bias and prejudices as some sort of universal linguistic truth. In highschool band the percussionists called the wind section "honkers," were they making some vailed n-word allusion? No, it was silly and the wind section were all blowhards so we made fun of them with a little in-group slur.
Anyone who says "clanker" is analogous to any actual racial slur is revealing their belief that AI, in its current state, can be deserving of the same rights that humans have. Which is demonstrably false, given the current state of AI.
Now, true AGI? There's a debate to be had there regarding rights etc. But you better be able to prove that a so-called AGI is truly sentient before you push for that. This isn't Data. There is nothing even remotely close to sentience present in any LLM. I don't even know if AGI is going to be achievable within 100 years. But as far as I'm concerned, AI "slurs" are just blowback against the invasion of AI into everyday life, as is increasingly common. There will be a point where the hard discussion of "does true artificial general intelligence deserve rights" will happen. That time is not now, except as a thought experiment.
No offense taken, my understanding of the term could was wrong. I hope it doesn't take anything away from my argument though. I think I wanted to use the term "deprivatization" instead, I only remember this topic distantly from reading about communism and economics.
One use case I'd love to see an easy plug-and-play solution for is a RAG build around companies vast internal documentation/wikis/codebase to help developers onboard and find information faster. I would love to see less of people trying to replace humans with language models and more of people trying to use language models to make humans jobs less frustrating.
In all the companies I have worked at and have looked at such docs, unfortunately this doesn't really work because those internal documentation sites are statistically never up to date or even close. They are hilariously unclearly written or out of date.
As for relying on the code base, that is good for code, although not for onboarding/deployment/operations/monitoring/troubleshooting that have manual steps.
^this, but many non-code documents with manual steps can also be kept up-to-date as long as there is a way (a) relate it back to the codebase or another source of truth (b) detect conflicts (when someone says something in contradiction to an existing document)
