From the article:
The policy summarizes itself this way:
It’s fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to create.
Uses in the first category are allowed, sometimes requiring disclosure. Uses in the second category are heavily restricted.
Seems pretty level-headed to me.
Interesting policy… I suspect it falls apart in the details though. Like, there are plenty of creative elements in responding to questions (and any of the other categories). That mean there will be lots of weird edge cases that are hard to adjudicate. And those GenAI components of “non-creative” categories will have ripple effects into the broader project and community (as they are everywhere, so maybe not that important for a.policy to grapple with, IDK).
“refine” vs “create” is already a super grey area
Yeah in theory I could have a model suggest code through a PR and then review said PR and just be the one to hit squash and merge and it technically only suggested and reviewed and I “created” the PR
But if you actually described this methodology in your PR, then it’d no doubt be closed immediately, based on the spirit of the rules rather than the exact letter of the rules.
Rules like these ultimately presuppose that the contributor is acting in good faith. Because otherwise the contributor could just lie about using an LLM. They don’t need to engage in rules-lawyering or jump through hoops to circumvent the rules
Rules like these ultimately presuppose that the contributor is acting in good faith.
All of civilization is based on that.
nah, it’s a dumb policy which will be impossible to maintain in the years to come.
What counts as creating? How can one refine without creating?
Well a light refactor of deduplicating code would be a refinement that is generally easy to review and likely comfortably in the capability of the codegen.
Versus creating, which generally is harder to review and requires the submitter to explain the rationale behind the change.
Volume of code and nature of change.