NLNet Labs LLM Policy
69 points by David_Gerard
69 points by David_Gerard
I can see why people get tired of AI generated stuff, especially at scale. Even in the small team that I work it can become annoying. I might question someone: "For what reason did you do this?" and the answer is: "Ohhh, Claude did that!" which is not an answer of course, people offload their thinking and in addition the responsibility to a machine. I think it's not necessarily bad to err on the conservative side on its usage and only relax once you find out how to use this technology responsibly at scale, which at this point no one knows how to do.
Claude did that
Imo the issue with AI is is really this attitude. The buck stops with the prompter. If you can't justify every line of code yourself, you need to put the PR back in drafts and start reading and understanding what you done did. These things cannot take responsibility, so the people driving them have to.
I use AI at work, but I haven't changed my quality standards. The biggest challenge for me has been learning how to use LLMs in a way that produces the same code that I would have written manually. I refuse to accept anything less tbh
It would be nice to hear the reasoning behind these rules. I’d like to know if, say, legal uncertainty was the main motivation vs. concerns about quality or maintenance (or other).
Alex Band from NLnet Labs wrote the following in this toot (as a laudably measured response to some vigorous sealioning):
Suppose you want to contribute a great, much desired feature to one of our open source projects. Some well executed prompts result in a 10K LoC block of code that functionally appears to do what you intended.
Before submitting this as a Pull Request to the NLnet Labs team, have you reviewed, do you understand and take responsibility for every line of code that was generated? In our experiences over the last year, this rarely happens.
Code is left on our doorstep as a (well intended) gift. But it put the onus on us to review the code, take responsibility for it and merge it into the main branch. Knowing that our software runs in critical infrastructure that power the very fabric of the internet, that is a big ask.
As part of our review, we need to be able to have a conversation where both parties understand the ins and outs of the problem space and the solution that is being proposed. That’s not what LLM-use provides the submitter, and it negatively affects the long-term maintenance of the contribution.
well put but seems to rule out categorically the possibility of contributing /tests/ with the PR. You could have guidelines for adding those with your PR, and your project could supply CI that runs all those tests. A human only needs to press a button to trigger the check. The tests could be generative/property-based, to reduce the surface for human error. We can have good things!
Tests are not free: they are run continuously in test and build infrastructures. Over and over again, potentially for decades to come. Bad or unnecessary tests are at best expensive cruft burning precious cycles, but they can be a security issue as well.
I don't see an argument in their policy against using a script or other deterministic approach against generating tests, you really don't need an LLM for that. To exaggerate this position: imagine having a fuzzing tool submitting every permutation as a test to a code base, and having to review that. Wouldn't you prefer to submit the configuration of the tool and the source code of the tool over a petabyte of tests?
I do have a suggestion for you, which is to put any LLM generated tests into a separate repository. You can develop and run those tests safely on your own infrastructure, and they keep a clean and concise code base.
(I'm on of the authors)
The immediate reason to write this was to protect the time of our developers. But of course copyright, quality control, long-term maintenance and ethical concerns were all considered for the document.
I like the focus on human patch authoring and review but also the exclusion for vulnerability report patch suggestions. They can be useful to read when simple and to the point.
Keep in mind that this is NLnetLabs’ own policy and it is not the policy that must be adopted by NLnet funded projects.
It's understandable where they came from with this decision but the enforcement style ("no to everything") comes across as narrow minded.
Can you explain where your normative judgement comes from? In what way are you vested in someone else accepting LLM generated submissions for their project, and what would they (or society) gain from that? I find the reasoning logical and consistent, and a healthy protection measure in this day and age. Are you afraid they (or organisations like them) will refuse any submissions of yours for that reason, or has this already happened to you? Would it be so hard for you to comply with this policy?
Are you yourself a long-term maintainer of critical infrastructure, dealing with a daily influx of low effort noise on your issue tracker? How would you suggest to stay motivated and dampen the impact of a flood of false positives on your human-oriented workflow?
How would you suggest to stay motivated and dampen the impact of a flood of false positives on your human-oriented workflow?
Well, just use an llm for triage, duh !
/s
(I like the policy very much, ill pass it around in my circles and corporate)
It's fairly common for rules to be set that are narrow-minded and simple when the relevant community has proven it's unable to handle the more open-minded and complex version that more accurately reflects the interests of everyone involved. This isn't a bad thing. Perhaps when developers grow up a bit, this could be revisited.