Live data from Hacker News

Jellyfin LLM/"AI" Development Policy

jellyfin.org

81–90 of 112 posts

Re: Jellyfin LLM/"AI" Development Policy

#81

> LLM output is expressly prohibited for any direct communication I would like to see this more. As a heavy user of LLMs I still write 100% of my own communication. Do not send me something an LLM wrote, if I wanted to read LLM outputs, I would ask an LLM.

I completely agree. I let LLMs write a ton of my code, but I do my own writing. It's actually kind of a weird "of two minds" thing. Why should I care that my writing is my own, but not my code? The only explanation I have is that, on some level, the code is not the thing that matters. Users don't care how the code looks, they just care that the product works. Writing, on the other hand, is meant to communicate someth…

To me, you are describing a fluency problem. I don't know you or how fluent you are in code, but what you have described is the case where I have no problem with LLMs: translating from a native language to some other language.

If you are using LLMs to precisely translate a set of requirements into code, I don't really see a problem with that. If you are using LLMs to generate code that "does something" and you don't really understand what you were asking for nor how to evaluate whether the code produced matched what you wanted, then I have a very big problem with that for the same reasons you outline around prose: did you actually mean to say what you eventually said?

Of course something will get lost in any translation, but that's also true of translating your intent from brain to language in the first place, so I think affordances can be made.

Re: Jellyfin LLM/"AI" Development Policy

#82
post #72

I know this is nothing new, but it's insane that we need policies like "When talking to us you have to use human words, not copy pasted LLM output" and "You must understand the code you're committing." When I was young, I used to think I'd be open minded to changing times and never be curmudgeonly, but I get into one "conversation" where someone responds with ChatGPT, and I am officially a curmudgeon.

Brazen usage of LLM output is a disrespect to the target audience to begin with. If I'm being expected to employ the mental capital needed to understand the context and content of your writings, I at the very least expect that you did the same when actually authoring it.

Exactly the same argument can and should be applied to generated code

Re: Jellyfin LLM/"AI" Development Policy

#83
post #38

> LLM output is expressly prohibited for any direct communication I would like to see this more. As a heavy user of LLMs I still write 100% of my own communication. Do not send me something an LLM wrote, if I wanted to read LLM outputs, I would ask an LLM.

Relevant: https://noslopgrenade.com

What do you recommend if I've been regularly producing blog-length posts in Slack for years, no LLM present? It's where I write man...should I quit that out? I try to be information dense...

Re: Jellyfin LLM/"AI" Development Policy

#85

I'm not sure when this policy was introduced, but fairly recently Jellyfin released a pretty major update that introduced a lot of bugs and performance issues. I've been watching their issue tracker as they work through them and have noticed it's flooded with LLM generated PRs and obviously LLM generated PR comments/descriptions/replies. A lot of the LLM generated PRs are a mishmash of 2-8 different issues all jumble…

We've had these thoughts for a while, especially relating to clients, but that is exactly what prompted this - a huge number of pure-vibe-coded "fixes performance" PRs that have been a nightmare to wade through.

Re: Jellyfin LLM/"AI" Development Policy

#86

What's the grief with squashing commits? I do it all the time when I'm working on stuff so that I don't have to expose people to my internal testing. So long as the commit(s) look fine at the end of the day, I don't see what the deal is there.

Seems like both "show your working" and "make it easier for us to review" are the reasons. Seems reasonable to me.

"Commit 1: refactor the $THING to enable $CAPABILITY"

"Commit 2: redirect $THING2 to communicate with $THING1"

"Commit 3: add error handling for $EdgeCase" --- long explanation in commit body

A single commit with no commentary just offloads the work to the maintainers. It's their project so their rules.

Re: Jellyfin LLM/"AI" Development Policy

#87

Most of these seem to be applicable to any development. Don't submit PRs that you can't explain. I would hope they have that standard for all submissions.

This has actually come up in our internal discussions while we were drafting this, and the truth is, yea, this applies to "normal" PRs and such as well. But we weren't having any sort of problem with someone who has no understanding of the code at all coming in and making extensive changes. That simply wasn't possible. But LLMs enable someone with no knowledge to submit an extensive, on-the-surface-sensible PR that then needs literally hours of review work and testing.

Re: Jellyfin LLM/"AI" Development Policy

#88
post #32

People can write horrible PRs manually just as well as they do with AI (see Hacktoberfest drama, etc). "LLM Code Contributions to Official Projects" would read exactly the same if it just said "Code Contributions to Official Projects": Write concise PRs, test your code, explain your changes and handle review feedback. None of this is different whether the code is written manually or with an LLM. Just looks like a lon…

A large enough difference in degree becomes a difference in kind. Chat bots have vastly inflated the amount of shitty PRs, to the degree that it needs different solutions to manage.

Exactly. We never had a problem with spammy PRs before. Even at the height of Hacktoberfest, the vast majority were painfully obvious and confined to documentation. It was easy and obvious to reject those. But LLMs have really changed the game, and this policy was explicitly prompted by a number of big PRs that were obviously purely vibe-coded and we felt we really needed to get a defined policy out that we could point to and say "no, this is why we're rejecting this".

Re: Jellyfin LLM/"AI" Development Policy

#89

> LLM output is expressly prohibited for any direct communication I would like to see this more. As a heavy user of LLMs I still write 100% of my own communication. Do not send me something an LLM wrote, if I wanted to read LLM outputs, I would ask an LLM.

I’m glad they have a carve out for using LLMs to translate to, or fix up English communications. LLMs are a great accessibility tool that is making open source development truly global. Translation and grammar fix up is something LLMs are very, very good at! But that is translation, not “please generate a pull request message for these changes.”

Machine translation is best used on the receiving end. Let me decide if I want to run your message through a machine, or read it with my own skills.

Re: Jellyfin LLM/"AI" Development Policy

#90
post #80

> Violating this rule will result in closure/deletion of the offending item(s). Should just be an instant perma-ban (along with closure, obviously).

> Should just be an instant perma-ban (along with closure, obviously). This is the internet. Real offenders will just submit the next PR with a new alt account.

its still an added inconvenience and means they cant use AI to farm reputation on a single account
Post reply on HN