CONTRIBUTING.md: establish initial automation/AI/LLM policy

[emilazy]

The Nixpkgs core team feels it is overdue to establish an official policy on the use of automation for Nixpkgs contributions. The Code of Conduct has a clause against “Wasting other people’s time with low quality contributions, including but not limited to LLM and bot spam”, but does not define this in detail, and we have seen a large increase in automated contributions over the past months, often without disclosure.

After discussion with the community team bootstrap group and within the Nixpkgs core team, we’ve agreed on submitting this proposed policy for community review.

This is an area where people understandably have strong views, and which goes beyond technical matters to touch on legal and ethical concerns. It’s unlikely we can achieve complete consensus among contributors on the topic, and we’re willing to make judgement calls as necessary for the benefit of Nixpkgs, but we want to start out with a baseline policy that we think can gain strong consensus.

Therefore, we’ve focused on formalizing existing norms around automated contributions and applying them generally to include LLM‐based AI tools, ruling out what we think contributors will widely agree are clearly unacceptable cases: undisclosed use of complex automation, and automated contributions submitted without any manual review or understanding. The hope is that this will also give us more visibility with which to iterate further as necessary.

The core of the proposed policy is:

Every contribution to Nixpkgs and related development venues, including code, documentation, and communication on GitHub and Matrix, must have a responsible person in the loop who is accountable for that contribution and reviews it before submission, and must transparently disclose any non‐trivial use of automation to produce it, including but not limited to LLM‐based AI tools.

See the rendered version of the full policy for easier reading.

This policy takes inspiration from similar policies in LLVM, Mesa, Fedora, and the Linux kernel, along with a proposal by the author of Anubis. We’re also following the Rust project’s work on a more elaborate, stricter policy.

We’ll leave this pull request open for a public feedback period of at least two weeks. We’re happy to hear concerns or suggestions, either on this pull request or in private.

To ensure the discussion stays on track and civil, we’ll be liberally hiding comments that aren’t focused specifically on what Nixpkgs policy should look like, or that restate previously‐raised points. Please leave each piece of feedback as a separate review comment on specific lines of the diff so that threads of discussion can be kept separate and resolved as needed; use the header line if you have a comment about the policy as a whole.

Why cover all automation rather than just LLM‐based AI tools?

We have established norms around how we expect people to disclose, review, and verify automated contributions like treewide refactors. In the past, there have been cases where such changes have been merged without adequate verification and had to be reverted.

We think that formalizing those norms makes sense on its own merits, and that they serve as a good starting point for an AI policy: our expectations for the use of LLM‐based AI tools should clearly be at least as strict as those for more deterministic, reviewable tooling.

Why not ban LLM‐based tools entirely?

There’s clearly a divide in the community on these tools, with some prominent contributors forgoing them entirely and some using them extensively. As we said in the summary, we’re willing to make judgement calls here for the benefit of Nixpkgs, but only after doing our best to facilitate consensus. We believe that we need to establish a baseline of transparency and accountability before considering whether further steps may be appropriate, and that formalizing existing norms will help with this.

We believe that a maximally hardline policy of banning all use of LLM‐based tools at any stage of any contribution would likely be untenable; we would not want to ban the use of accessibility tools that often use LLMs like machine translation, speech to text, text to speech, and OCR, and declining genuine vulnerability reports solely on the grounds of LLM use during research would be shooting ourselves in the foot. We are not concerned with designing norms around dishonest contributors, but believe any policy will need to strike some kind of balance to be reasonable and enforceable.

We care deeply about the technical quality of Nixpkgs and don’t want a race to the bottom on standards, but believe it should be possible to use these tools without sacrificing rigour. While it may be financially inadvisable, I have seen Claude use to produce trivial version and hash bumps, and clearly in that case there is no meaningful risk to Nixpkgs compared to doing it by hand or with nix-update. For a less trivial example, it’s not uncommon for initiatives to be blocked on treewide changes that are tedious to write by hand, but comparatively easy to programatically verify (e.g. checking whether a refactor avoids causing rebuilds); in the past, these have sometimes been accomplished with a combination of naive scripting to handle common cases, and manual busywork to handle the rest. LLM‐based tools show potential to reduce the manual toil for these changes in combination with deterministic verification code.

In terms of copyright, we generally trust that submitted code is unencumbered and licensed appropriately. Cases where there is clear cause for concern are raised and handled as people notice them. LLM output is one of many areas of legal ambiguity around software copyright; too many, sadly, for us to strictly avoid all of them. This shouldn’t be taken as expressing any official project view on the copyright status of LLM output in general – there is clearly LLM output that does not pose a copyright issue (e.g. the aforementioned trivial version bump), and clearly LLM output that is a much greater concern (e.g. eliciting verbatim reproduction of existing code snippets, or using them to rephrase a codebase in an attempt to “launder” its licensing). If anyone spots plagiarism or copyright violation in any contribution, they can point it out and it should be handled appropriately. Of course, the appropriate copyright policy for LLM output may change as regulation and precedent develop.

We understand, however, that many community members have objections to the training and use of LLMs that go beyond matters of technical quality or legal concerns, and don’t intend to dismiss them out of hand. We would like this policy to be seen as establishing consistent standards based on pre‐existing norms around automation and ruling out the most problematic cases, not as an endorsement by the project, nor necessarily as the final word on the matter. We hope that transparency requirements will give people choice about which contributions they spend time on in the immediate term, and help facilitate a broader discussion on these topics to inform future work.

Why require disclosure?

We believe that transparency is the foundation of any effective policy. Establishing a baseline expectation of disclosure is required to enforce any further requirements or prohibitions, and to evaluate whether a policy is working.

We already have an established expectation that people who use scripts to generate large treewide changes disclose this in their contributions, and preferably make efforts to verify and understand the results.

We believe that it’s especially important in the case of LLM‐based tools: they are particularly good at producing confident and convincing output even when it’s not correct. While contributors are of course fallible in general, and code review inherently involves applying appropriate scrutiny rather than taking things on faith, we believe that this decoupling between the appearance of confident expert research effort and the correctness of the changes is especially pronounced for LLM output, and has a significant effect on review dynamics. It also decreases the extent to which reviewers can rely on pre‐existing trust in the nominal author.

The fundamental character of interacting with LLM‐based tools is also different – providing extensive feedback on changes from new contributors can usually be expected to help them learn and improve over time, which is not the case for an LLM. Contributors may wish to avoid spending time on this, or adjust their reviews accordingly.

Why require Assisted-by: over Co-authored-by:?

Since LLM‐based AI tools use Co-authored-by: attribution by default, we think that using a different format will serve as a brown M&M test and assist with triage. A commit that contains such a tool in Co-authored-by: but not Assisted-by: is, by definition, one that did not follow the policy and can be closed, potentially automatically. It also matches the format standardized on by the Linux kernel and Fedora, and will make it easier to review and query for use of these tools.

Why require a person in the loop?

We are fundamentally bottlenecked on manual review; there is no benefit to Nixpkgs to the submission of changes en masse that we cannot hope to triage. It’s the expected norm that contributors check their contributions before submitting them. A contributor sending automated changes without any review or validation takes up limited triage resources while not contributing anything that someone else with access to the same tooling couldn’t. Since any kind of automation allows changes to be produced much more quickly, requiring oversight ensures that contributions happen at a sustainable pace, and that every contribution is already vouched for by its contributor.

See the LLVM policy’s remarks on extractive contributions for thinking that resonates strongly with ours.

We also place trust in maintainers and committers in our own automation, e.g. through the merge bot. Unsupervised automation of changes and reviews subverts the principles behind these mechanisms.

This also mitigates the issues around feedback, by ensuring that there is always someone on the other end who can learn from it.

Why not cover upstream practices for packaged software?

We have been following the discussion about this, but believe that establishing a policy for Nixpkgs itself is the priority. Defining criteria and maintaining data for the entire package set would be a huge undertaking that goes beyond the scope of this proposal. A blanket policy covering packages with any LLM output would be untenable, as we cannot avoid packaging core components like the Linux kernel, LLVM, systemd, and HarfBuzz, and it would likely be very difficult to produce a usable, up‐to‐date system while entirely avoiding all such components.

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

[vikanezrimaya]

I feel like "agent name" is a little too vague. "Agent name" could be a harness that was used (opencode, Codex etc.), it could be some sort of nickname or codename the author uses for their agent (a combination of harness, language model or model family, system prompt and perhaps a memory system in case of autonomous persistent agents).

Additionally, Assisted-by could (and, in my belief, should, though for purposes of this policy I'd put in an RFC2119 "MAY") be used for other tools, not just language model-based coding assistance agents.

I seem to recognize that the format was copied from the Linux kernel coding assistant guidelines. I think we should just copy that section in full (with explicit acknowledgment and backlink):

Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]

Where:

• AGENT_NAME is the name of the AI tool or framework
• MODEL_VERSION is the specific model version used
• [TOOL1] [TOOL2] are optional specialized analysis tools used (e.g., coccinelle, sparse, smatch, clang-tidy)

Basic development tools (git, gcc, make, editors) should not be listed.

[vikanezrimaya]

Also I think it would be nice to clarify behavior if several harnesses/models were used. One Assisted-by trailer for each model/harness pair?

[hoh]

Some examples of AGENT_NAME:MODEL_VERSION could be useful, as there is still ambiguity.

For example, what would be the best form amongst the following?

• opencode/unsloth/Qwen3.6-27B-GGUF:UD-Q4_K_XL
• @codex/Qwen3.6-27B
• github.com/openai/codex/Qwen3.6-27B
• github.com/openai/codex/unsloth/Qwen3.6-27B-GGUF:UD-Q4_K_XL (and we are lost in the /).

[vikanezrimaya]

For example, what would be the best form amongst the following?

@hoh all of the examples you listed below have a / where a : should be per the policy described above, and the 1st and 4th example also use a colon for quantization specifiers (the only place where a colon is used in model releases anyway).

All of this definitely requires clarification, and official examples would be useful.

I imagine it like:

• opencode:qwen3.6-35b-a3b (downsides: no quantization specifier)
• opencode:qwen3.6-35b-a3b:q4_k_m (downsides: none, but watch out for the second colon if parsing via automation)
• opencode:unsloth/qwen3.6-35b-a3b-gguf:q4_k_m (downsides: a little more verbose, though this form can be useful if using obscure finetunes/quants/variants; implied huggingface link)
• opencode:hf.co/unsloth/qwen3.6-35b-a3b-gguf:q4_k_m (downsides: a lot more verbose, but extremely specific; I could paste this into llama.cpp and get the exact same model you're running, save for the sampler parameters, which seem to be a matter of taste anyway, it seems)
• github.com/simonw/llm:<any of the above> (downsides: extremely long, but also has a direct link to the harness. One could even do a specific commit, or point to a fork if harness is customized; still doesn't fully capture the workflow, and can't hope to, because some harnesses allow plugins for a total conversion into something else entirely; also, excludes non-OSS harnesses, which to me feels like a good thing, but some proprietary/unpublished harness users will rightfully object, and soon I may be among the latter)

[hoh]

When reflecting on this topic, I am wondering what the real value is for mentioning the specific tools and models used.

A user may also be using a collection of tools, such as:

• Cursor with Opus 4.7 for creating a plan
• OpenCode with Qwen 3.6-35b-a3b for implementing it
• Codex with GPT 5.5 for reviewing the changes
• GitHub Copilot for a second code review
• Claude code with Haiku for fixing typos

There are also web versions of Codex/Claude/...

This would end up with a very verbose list of advertising for the companies behind these tools, but I don't see the value above something like Assisted-by: Coding agent.

[KiaraGrouwstra]

seconding @hoh here - the prevalence of e.g. claude's suggested opusplan default (have the bigger model handle planning mode, the mid-sized one do implementation) already makes this format awkward.

this further raises the question of what exact problem we were trying to solve with that detail. it's not like model details make things reproducible, while i imagine the reason LLM vendors had the Co-Authored-By tags include any info on this was marketing, basically.
like, should we go along with that and make nix contributors do marketing for LLM vendors just because big AI wanted us to?

[7c6f434c]

We might end up collecting a bunch of «not even the top models are reliable» examples of mess-ups, and maybe a few guidelines of type «if you use this, check this and document the check or get the PR auto-closed for carelessness». And yeah, maybe we might end up needing to emergency revert as much as possible of commits touched by a specific setup.

[KiaraGrouwstra]

We might end up collecting a bunch of «not even the top models are reliable» examples of mess-ups

tbh LLMs are 'garbage in garbage out' w.r.t. prompts as well as to prior context, and either way should be challenged by someone with some domain knowledge on suggested solutions, if not further to conversely have the machine challenge the user on ideas and implementation as well.

to an extent then, i would be inclined to regard any use of a tool settling for a shitty output as using it wrong, such that i would argue having some users publish shitty output should not have to imply another wouldn't be able to use it better.

[emilazy]

(Joining threads: I’ve responded to some of the points raised here in #514587 (comment).)

[7c6f434c]

to an extent then, i would be inclined to regard any use of a tool settling for a shitty output as using it wrong, such that i would argue having some users publish shitty output should not have to imply another wouldn't be able to use it better.

On the one hand, sure, «get 70% there and just edit the last part by hand» (possibly with another round of fully-hand-handled LLM review) is solid advice so one could say that anything that gives worse results than that is holding-it-wrong. On the other hand, some data on how bad things can or cannot get with an allegedely vibecoding-safe setup if one doesn't pay attention could still be useful.

[whitequark]

This is one of the more well thought-out policies. While it would not be one that I would choose personally (and I have opted for a different approach in the past), I believe this is the key part that reasonably justifies picking this particular approach:

We would like this policy to be seen as establishing consistent standards based on pre‐existing norms around automation and ruling out the most problematic cases, not as an endorsement by the project, nor necessarily as the final word on the matter.

[acid-bong]

edit: moved accessibility topic to #514587 (comment)

[7c6f434c]

accessibility tools don't generate code, which is what this policy should regulate, they only interpret existing media, such as reading the given text or type from the person's voice

Many speech-to-text tools nowadays definitely use language models to reduce error rates, and some are architecturally close to what is most centrally called LLMs, and possibly some of them use or will soon use unambiguously instruct-LLMs to allow specifying what kind of text one is dictating.

If one includes machine translation into the accessibility umbrella, and includes code comments into the notion of code, then there too one can have LLM-generated code due to accessibility tools.

[7c6f434c]

Suggested change

Every contribution to Nixpkgs and related development venues, including code, documentation, and communication on GitHub and Matrix, must have a **responsible person in the loop** who is accountable for that contribution and reviews it before submission, and must **transparently disclose** any non‐trivial use of automation to produce it, including but not limited to LLM‐based AI tools.

Every contribution to Nixpkgs and related development venues, including code, documentation, and communication on GitHub, Discourse, and Matrix, must have a **responsible person in the loop** who is accountable for that contribution and reviews it before submission, and must **transparently disclose** any non‐trivial use of automation to produce it, including but not limited to LLM‐based AI tools.

[niklaskorz]

Do we consider Discourse a nixpkgs development venue? (honest question; I see it more as a support venue most of the time)

[truh]

Category: Development
Development discussion for Nix, NixOS, Nixpkgs, NixOps, RFCs, etc.

[acid-bong]

Not in entirety, but the specific threads/topics/spaces. Same with Matrix, only development chats (#dev, #ci, #hydra and so on). I'd suggest specifying that moment:

Suggested change

Every contribution to Nixpkgs and related development venues, including code, documentation, and communication on GitHub and Matrix, must have a **responsible person in the loop** who is accountable for that contribution and reviews it before submission, and must **transparently disclose** any non‐trivial use of automation to produce it, including but not limited to LLM‐based AI tools.

Every contribution to Nixpkgs and related development venues, including code, documentation, and communication on GitHub and in development-related spaces on Matrix and Discourse, must have a **responsible person in the loop** who is accountable for that contribution and reviews it before submission, and must **transparently disclose** any non‐trivial use of automation to produce it, including but not limited to LLM‐based AI tools.

[emilazy]

The reason Discourse wasn’t included here originally is that it covers a range of topics outside our jurisdiction, like Nix itself. On GitHub and Matrix, the categorization is distinct enough that it’s fairly unambiguous which venues are related to Nixpkgs and therefore in scope; on Discourse, a lot of topics are just in the “Development” category with no further categorization.

I think it would be a good idea in itself to include Nixpkgs‐related topics on Discourse, but the discontinuity between standards in one topic to the next depending on its subject (and the ambiguity when that subject shifts) may be surprising, compared to GitHub and Matrix where the subject of a venue is more static. Happy to hear people’s thoughts about this.

@acid-bong I think your suggestion is redundant: “Every contribution to Nixpkgs and related development venues, including … communication on GitHub and Matrix”? Note that even for GitHub, related development venues does not include e.g. the Nix and Hydra repositories, because they’re outside of the Nixpkgs core team’s authority.

(Of course, we’d be happy to see this work grow into a more widely‐applicable policy beyond Nixpkgs in future!)

[7c6f434c]

Suggested change

	Contributions include code and documentation in commits, commit messages, pull request summaries and reviews, issue and vulnerability reports, GitHub comments, and Matrix messages.
	Contributions include code and documentation in commits, commit messages, pull request summaries and reviews, issue and vulnerability reports, GitHub comments, and messages in other official community spaces.

[emilazy]

(I think this is the same case as #514587 (comment); let me know if there’s nuance I’m missing.)

[acid-bong]

includes code comments into the notion of code, then there too one can have LLM-generated code due to accessibility tools.

welp, there's a difference:

• if they voice-dictated their writing, preferably to a specialized LLM (if LLM), it's not generation (as long as the misinterpretations aren't too common/severe), the person knows and controls what they write/say
• if they said "write me a package recipe" and got the recipe that way, it's generated

the former should go into its own category, like "LLM-assisted (accessibility)", the latter — into "LLM-generated"

[niklaskorz]

To clarify, is closing a PR in case of "AI tool attributions that do not meet our required format" exempt from the above "assume good faith"? More specifically, are such PRs that use Co-Authored-By for AI disclosure always to be closed directly without giving a chance of correction?

[typedrat]

I hope not, especially for first-time contributors who otherwise seem to be acting in good faith -- granted, I might be exactly the kind of contributor that you want to drive away with this as someone who has admittedly been a bit too liberal with coding agents in some of my PRs, and in that case I'll take my lumps and step away from the discussion, but I really do think that continuing to be a welcoming place for new contributors is worthwhile, even in a world where those new contributors will increasingly make at least some use of AI-based tools and a lot of people in the community have strong feelings about that.

[truh]

To me this paragraph reads like the idea is to grant people who inadvertently violated this policy an opportunity to fix their mistake.

[roberth]

I worry a bit that this paragraph could be used to justify unwarranted behavior on the part of maintainers. I'd favor a phrasing that keeps the temperature low, and we could adjust the policy if we end up becoming more of a target for slop somehow, and even then, the CoC already covers this, albeit with fewer specifics.

Furthermore if this scares away LLM users in the first place, that would be bad.

• Below the generated code are usually real issues that are worth solving
• LLM users contribute real-world testing
• Improving open source together should reduce LLM usage and its negative externalities (i.e. avoid duplicated LLM work between many users)

I'd consider dropping this paragraph and only reintroducing it when proven necessary.

[emilazy]

The assumption of good faith is not meant to be optional here, of course!

By the definition of extractive contributions, however, we need a way to handle them that requires sufficiently low friction on the part of the person doing triage; see LLVM and Rust for concrete precedent on a “quick rejection” flow for PRs that don’t meet standards set by related policies. I believe that we cannot omit some clear indication that contributions that don’t meet the requirements aren’t accepted, and that it’s fine to deal with them quickly and move on rather than debating the policy every time.

We already have a significant triage problem; a dramatically lowered cost of submitting plausible‐looking contributions exacerbates it, which is one of the primary motivations for this policy. In general, I think Nixpkgs is quite bad at saying “no” to things; contributions tend to stall out rather than being closed, which I think is no less frustrating for contributors.

I agree, though, that this shouldn’t come at the expense of being polite, or giving the contributor a chance to address the problem. The ideal flow I imagine looks something like this:

1. We have a label for contributions that don’t meet the policy. CI detects contributions that can be unambiguously determined to violate the policy (e.g. Co-authored-by: without Assisted-by:) and applies it; contributors can also manually apply it where relevant.

2. CI detects the label, marks the PR as a draft, and posts a comment explaining the need to meet the policy and pointing the contributor to it.

3. When the contributor has adjusted the contribution to meet the policy, they can check the PR checklist item, and the PR will be undrafted and the label removed.

4. If the contribution isn’t adjusted within a week, CI closes it automatically.

I think this should allow us to minimize the burden posed by contributions that are in violation of the policy, while being kind to contributors. We’ll take a look at the specific wording here, though, as we don’t want to encourage reviewers to cause conflict, especially unilaterally in ambiguous cases.

[crertel]

I think this is a reasonable policy, as a starting point, and if we find shortcomings in its usage we can iterate and learn.

(moved feedback to comment)

Great work y'all; thanks for getting this out there! :)

[niklaskorz]

How does this affect custom update bots as some maintainers have used them in the past (including me)? Are these still allowed to create PRs on their own without the operator's review before undrafting, or are they explicitly addressed by this policy (i.e, operators are meant to review the automated PR before it is undrafted)?

Context for my use of this (currently retired) bot: zed-editor has a rather short release interval, and for a while there were no other contributors willing to take care of update PRs (which is not the case anymore), so I tried to automate the process in the meanwhile. Also r-ryantm does not notify me of issues in the update process, which my own bot did. I personally think requiring such automated PRs to be drafts until the operator has verified their output is reasonable though.

[roberth]

Perhaps include updateScript and tooling that's created or approved by the maintainers of the individual package?
We can spread the decision making here.

Suggested change

	* Use of standard community automation is exempt, such as `nix-update`, the official Nixpkgs CI bots, the @r-ryantm update bot, and the Nixpkgs security tracker bot.
	* Use of standard community automation is exempt, such as `nix-update`, the official Nixpkgs CI bots, the @r-ryantm update bot, and the Nixpkgs security tracker bot.
	* Use of automation approved by the maintainers of the affected set of files, provided that any automated communication such as PR descriptions and automated commit messages are clearly identifiable as the result of that particular automation as laid out in [Transparency](#Transparency).

(without enforcing that agreement to be formal, so I think it should be fine for a solo maintainer could just go ahead)

[emilazy]

Custom update bots seem like a reasonable use case, and the fact that they’re serving a specific maintainer who has opted in to seeing the PRs certainly helps. However, it seems tricky to delineate the boundaries here. I am not sure we would want to give the green light to, say, LLM‐based bots submitting automated changes en masse, even with maintainer consent, even as drafts, which it seems like @roberth’s amendment would do.

I think that “standard community automation” ought to include update scripts, but update scripts themselves don’t open PRs, which runs into “It is not permitted to submit automated contributions without any manual review or intervention, outside of standard community automation”. Maybe we could have a specific carve‐out here by simply generalizing “the @r-ryantm update bot” here to e.g. “bots that run in‐tree update scripts”?

It’s of course also an option to have these bots present these changes to the relevant maintainers outside of Nixpkgs (say in a fork), and then to migrate them to Nixpkgs once the maintainer has approved, which would meet the policy requirements. But I realize that complicates the workflow, so it would be good to find a way to permit this as‐is.

[Eveeifyeve]

I think it would be good to also add a AGENTS.md inside of the Nixpkgs repository after this pr that lists the do and don't so if someone comes up in claude-code and it should specify this policy automatically.

But however I have nothing else to say about this, I think it's a great idea to be transparent about AI in nixpkgs, it might also be good to something for other repos in nixos github as well (like the nixcpp repo).

[jackrosenberg]

I think it would be good to also add a AGENTS.md inside of the Nixpkgs repository after this pr that lists the do and don't so if someone comes up in claude-code and it should specify this policy automatically.

The whole idea of this change is to enforce keeping humans in the loop. Adding dedicated hands off LLM hooks seems like a step in the wrong direction. We want humans to follow the rules explicitly.

[alyssais]

Hi everyone, and thank you for the lovely feedback so far! I'd like to draw attention to the following request from Emily's PR body though:

Please leave each piece of feedback as a separate review comment on specific lines of the diff so that threads of discussion can be kept separate and resolved as needed; use the header line if you have a comment about the policy as a whole.

Posting top-level comments that can't be threaded can make discussions like this quite difficult to read when they start filling up, because different conversations get mixed up together.

[crertel]

One thing I would like to request, though I'm not sure where it'd go here, is a sort of rule that:

Contributions from tools should at the very least reduce toil for future maintainers.

The idea there being that if you contribute via LLM or similar for packages or services, we expect to see:

• Addition of tests (if they were missing)
• Addition of update scripts
• Addition of (as much as possible) well-documented and well-typed program and service options (instead of, say, the not-uncommon practice of "here's a config string we'll turn into a file, good luck").

(nix-facts is a tool you can use to try and see how many packages are missing tests or update scripts, though it's in "beta")

Basically, if we use LLMs, we should be using them not only for our own convenience but to achieve code quality and ease-of-maintenance that is currently not there.

[typedrat]

I think that this is something valuable to keep in mind as a principle, but I think it's a little bit too subject to interpretation to make a hard and fast guideline.

[crertel]

I think a hard-and-fast rule of "if you're adding a package/service using an LLM, we better see tests and update scripts" is a pretty objective measure--either the tests and update scripts are there, or they aren't.

But, I'm not sure that belongs in this doc, as such.

[vikanezrimaya]

"leave the codebase better than you found it" is a good guideline, but would be indeed subjective to be a hard rule.

May be worth a mention somewhere in the contribution guidelines though. Explicitly, because even though it's common-sense for many long-time maintainers, I feel like newcomers may benefit from a reminder. And I feel the positive sentiment as in "try to strive for this ideal" would offset the "don't do this, don't do that" of hard-and-fast rules aimed at low-effort contributions mentally, encouraging good contributions instead of just discouraging bad ones.

[emilazy]

We would definitely like to encourage contributors to raise our technical standards! But I agree with the other replies that this is a more general principle, and would best go in other contributing documentation, as it seems particularly important for this policy to stay focused; any subjectivity is more of a risk here than elsewhere, and I think it already risks being too verbose in the effort to avoid that.

[jackrosenberg]

Hey all,

I fear that this policy is still too permissive. I see the effort put into guardrails to guide LLM users to use their tools responsibly, but am scared that this will still encourage a flood of low effort contributions.

As you say, we are fundamentally bottlenecked on manual review. I am not enthusiastic about reviewing code that could be AI generated. I do not want to spend my time explaining why something fails, and how it can be fixed, to someone who will just pass it along to their chatbot. I do not think that allowing LLM generated content, even clearly labled, will help the burden of manual reviewers.

I believe automated, deterministic, auditable tools fundamentally differ from LLMs. While I agree that holding them to at least the same standards is a good starting point, I believe they should be held to a much stricter one - if allowed at all.

That said, I appreciate that a stance is being taken. Thank you for your transparency and request for feedback.

[jackrosenberg]

I, and many other maintainers have had multiple workflow disrupting interactions with people using AI as a substitute for thinking. Many contributors will not review, advise, or otherwise knowingly interact with any contribution that has been generated by an LLM. That will not change, regardless of what policy is implemented.

I understand that this is not the case for everyone here, and have had many discussions with people on both sides of the fence. One of the arguments I hear the most is that banning AI all-together is unenforceable. Or that a full ban will alienate new contributors. These are not reasons to implement a more permissive policy. We want new contributors to write their own code, be corrected, and learn from the experience. We want our energy to benefit the community.

Enforcing an AI ban will not be impossible. As mentioned here, banning AI is doable. In most situations it is immediately obvious when someone has used an LLM. If they are dishonest about their use, this can easily be escalated and verified. Multiple other large, community governed projects have chosen for a stricter policy, if not an outright ban (see Wikipedia, Gentoo).

Something similar to the proposed rustlang AI policy is much more in line with our community values. Our policy should aim to lighten the load of reviewers, and encourage human learning.

It is imperative that we implement a policy, and these discussions are prone to stall. I urge the core team to close the discussion after the two week mark.

[emilazy]

We absolutely agree that contributions and reviews being passed unthinkingly back and forth to LLMs is not acceptable, and this policy is very much intended to forbid that; I’ve said more about this and other matters you’ve raised at #514587 (comment), so I’ll point there to avoid duplicating responses :)

[typedrat]

I know I'll get push-back on this, but I really think it's worth including at least a minimal AGENTS.md in the repository that just highlights these standards, if only because then we can enlist the agents themselves to help inform users about the expectations and responsibilities they have to adhere to as contributors.

[typedrat]

They will read CONTRIBUTING.md at times, and I have a global instruction on my system for my agent to do so, but AGENTS.md is directly injected into the context window as part of the system prompt (or at least automatically injected into the context window at the start of all conversations) so they don't even have to read it.

[crertel]

I'll note that figuring out this sort of thing was the point of one of the GSoC proposals that didn't make the cut. It might be worth revisiting, or even suggesting a stub AGENTS.md that has the shape you're considering--a strawman would go a long way. :)

[KiaraGrouwstra]

might adding such a file like this not defeat the spirit of the stated brown M&M test though?

[acid-bong]

Not in entirety, but the specific threads/topics/spaces. Same with Matrix, only development chats (#dev, #ci, #hydra and so on). I'd suggest specifying that moment:

Suggested change

Every contribution to Nixpkgs and related development venues, including code, documentation, and communication on GitHub and Matrix, must have a **responsible person in the loop** who is accountable for that contribution and reviews it before submission, and must **transparently disclose** any non‐trivial use of automation to produce it, including but not limited to LLM‐based AI tools.

Every contribution to Nixpkgs and related development venues, including code, documentation, and communication on GitHub and in development-related spaces on Matrix and Discourse, must have a **responsible person in the loop** who is accountable for that contribution and reviews it before submission, and must **transparently disclose** any non‐trivial use of automation to produce it, including but not limited to LLM‐based AI tools.

[acid-bong]

(here, because it's a reply to Emily's header message, not this file's contents)

we would not want to ban the use of accessibility tools that often use LLMs like machine translation, speech to text, text to speech, and OCR

accessibility tools don't generate code, which is what this policy should regulate, they only interpret existing media, such as reading the given text or type from the person's voice. a contribution from a visually impaired person, who reads with LLM-powered tools, but codes everything by hand, isn't LLM-generated. it is certainly possible to restrict LLM usage and not restrict accessibility tools

original replies:

• CONTRIBUTING.md: establish initial automation/AI/LLM policy #514587 (comment)
• CONTRIBUTING.md: establish initial automation/AI/LLM policy #514587 (comment)

[LorenzBischof]

A coding agent can itself also be an accessibility tool, if someone cannot type for any reason (e.g. RSI).

[acid-bong]

RSI meaning repetitive strain injury?

anyway, once again, see my points in linked messages: there's a difference between voice-typing word by word (and knowing what you do) and "hey, claude, make this thing for me"

[SomeoneSerge]

I think “and” here is misleading

"And" is not always disjoint?

“LLM‐based AI tools” is used consistently

While at it, I'd suggest: "AI" and (L)LM-based tools. This way we highlight that the policy isn't about any particular architecture or implementation, but about certain properties (complexity, poor inspectability, poor predictability, &c) of these tools.

A non‐standard term like “data-driven programs”

It is somewhat common¹²³, in any case less non-standard than "AI" the way it's used today. "AI" is good in a title.

Footnotes

1. https://en.wikipedia.org/wiki/Data-driven_model ↩

2. https://www.youtube.com/watch?v=a13aqr07tJ4 ↩

3. https://archive.org/details/Redwood_Center_2014_09_24_Alyosha_Efros ↩

[SomeoneSerge]

automation is processing a contribution into a form that is no longer comprehensible to the contributor would be a problem, I think, and machine translation has enough pitfalls that I wouldn’t say we can make a general assumption that the contributor understands its output

Precisely. That's why I'm saying it's not really an exemption, nor does it need to be one. The paragraph is just to explicitly state, that the use of translation and accessibility tools in itself is not automatically disqualifying.

[SomeoneSerge]

Much of Nixpkgs is about software build systems [...] a chaotic subject in practice

Yes, Nixpkgs is "applied maths".

Our real needs are about working software,

..."working software" here meaning "working in the long(er) term", i.e. "bootstrapable, maintainable, inspectable", of course.

People who want to make chatbots work will do, people who want to poison chatbots without damaging the actual functionality of Nixpkgs will do, that's fine.

Chatbots are supplied with enough money to keep chugging forward and getting subscriptions regardless of quality of their underlying models. It is Nixpkgs as the social phenomenon and as a world-modeling endeavor, with its Wikipedia-style development model, that is at risk.

Whether we're talking about Nixpkgs-for-deploying-today, or Nixpkgs-for-reading-by-humans, or the Nixpkgs-for-data-analysis, all three are of most value when written by humans.

[SomeoneSerge]

in the limit of underhanded code.

I like the reference, maybe it's worth including in the policy as communicating the spirit...

[SomeoneSerge]

Rendered: https://md.someonex.net/s/Nzr2olhfk8#

Suggested change

	# Automation/AI policy
	Every contribution to Nixpkgs and related development venues, including code, documentation, and communication on GitHub and Matrix, must have a **responsible person in the loop** who is accountable for that contribution and reviews it before submission, and must **transparently disclose** any non‐trivial use of automation to produce it, including but not limited to LLM‐based AI tools.
	The following sections give more detail.
	# Automation and "AI"
	## Care and respect
	All text intended for a human reader must be human-authored.
	## Policy
	Every contribution to Nixpkgs and related development venues, including code, documentation, and communication on GitHub and Matrix, must have a **responsible person in the loop** ("Contributor"). This person is accountable for the contribution, reviews it prior to submission, and must **transparently disclose** any non‐trivial use of automation involved in producing it, including but not limited to "AI" and (L)LM-based tools.

[7c6f434c]

complexity, poor inspectability, poor predictability, &c

Speaking of what is more code and what is more data, lockfiles sometimes get committed, and I think some ecosystems use SAT-solvers, which are complex, have high input sensitivity / low predictability of choice between technically allowable solutions, and also have once been called AI.

Yes, Nixpkgs is "applied maths".

Most of Nixpkgs by impact, possibly. Most of Nixpkgs by churn is at best computational linguistics.

..."working software" here meaning "working in the long(er) term", i.e. "bootstrapable, maintainable, inspectable", of course.

Honestly, for periphery packages often no.

There are good upstreams, where expressions do not require much maintenance beyond versions and maybe dependency lists, and there are bad upstreams where expressions need periodic overhaul as careful as you ever are. There are some medium upstreams where the situation is in the middle, but I am not sure they are the majority of our churn or anything.

Whether we're talking about Nixpkgs-for-deploying-today, or Nixpkgs-for-reading-by-humans, or the Nixpkgs-for-data-analysis, all three are of most value when written by humans.

Nixpkgs-for-deploying-today is a thing that is of most value when it has coverage. Some things need to be well-designed for that (i.e. cross-compilation is a large increase in coverage). Some things just need to be there at all, more things existing better than fewer but higher quality.

Oh, and we have already plenty of human-intent-destroying policies as well as policy-enforced falsehoods if we look at the case of humans reading expressions.

[SomeoneSerge]

and I think some ecosystems use SAT-solvers, which are complex, have high input sensitivity / low predictability

👍🏿 👍🏿 👍🏿

[SomeoneSerge]

Rendered: https://md.someonex.net/s/Nzr2olhfk8#Accountability

Suggested change

	Everyone who submits a contribution to Nixpkgs is responsible for it, regardless of the use of automated tooling.
	Before submission, they are expected to establish a reasonable level of understanding of the contribution and belief in its correctness.
	Contributors are expected to be able to answer questions about their contribution and respond to feedback appropriately.
	A contributor submitting a contribution intended for inclusion in Nixpkgs is also responsible for ensuring that it is [appropriately licensed](https://github.com/NixOS/nixpkgs/blob/master/COPYING) and credited, and not encumbered by any incompatible copyright.
	When output from automated tooling is used in contributions, a contributor must establish confidence in that output.
	This can be achieved by establishing confidence in the correctness of the tooling’s logic, manual review of the included output, or using further automation to verify the output (e.g. programmatically checking whether a refactor avoids causing rebuilds).
	As the inner workings of LLM‐based AI tools cannot be sufficiently understood at present, only the latter two options are available when those are used.
	When automation is used to verify output, the verification tooling itself must be disclosed and reviewed in line with this policy.
	Contributor is responsible for their Contribution, regardless of the use of automation.
	Before submission, they are expected to establish a reasonable understanding of the Contribution, and a belief in its correctness.
	Contributors are expected to be able to answer questions about their Contribution, and respond to feedback appropriately.
	Contributor submitting a contribution intended for inclusion in Nixpkgs asserts that it is correctly attributed, [licensed](https://github.com/NixOS/nixpkgs/blob/master/COPYING), and not encumbered by any incompatible copyright.
	When an Output from automated tooling ("Tooling",) is used in a Contribution, Contributor must establish confidence in the Output.
	This is achieved by establishing confidence in the Tooling, through manual Review of the included Output, or using further automation (a.k.a. "Harness") to verify the Output. A Harness may be e.g. a test suite or a programmatic check, ensuring that a refactoring does not trigger rebuilds. The Harness itself is considered an automation tooling subject to this policy.
	Due to the inherent complexity and opacity of "AI" and (L)LM-based tools, their Outputs must be reviewed manually and (or) verified using an automated Harness. Note that "AI"-based tools might generate Outputs faster and more complex, than is feasible for a human Review or for an automated Harness to achieve reasonable coverage of.

[KiaraGrouwstra]

if you run a test it must be disclosed in the commit in Assisted-By: format? this wording sounds a bit broad to me.
gotta say i also feel a bit mixed on the term harness here maybe as that also seems used for coding agent client programs.

this wording also i think leaves room for a liberal reading that it could suffice to have LLM output verified by LLM (surely as 'further automation' LLMs might qualify as a 'Harness'), which i think can help but should not be sufficient.

[alyssais]

I think it would be more effective to stick to focus on what specific changes in meaning you'd like to see (as you've done a great job at above — thank you) than to propose large rewrites like this, which are difficult for us to incorporate in a redraft when we also have to take into consideration everybody else's comments. For this particular diff I think the legalistic language would make the policy quite a bit harder for people to understand.

[7c6f434c]

A question on retroactive applicability of sorts: should we set an expectation that a contributor that remains active is expected to answer (roughly, not everyone remembers sufficient details and that's OK) about automation use in pre-policy contributions?

This might become relevant for preparing for eventuality where e.g. if France or Italy (choice of countries is not random) gets a regulation with a wider interpretation of derived-work-via-LLM-training-and-use.

[emilazy]

This seems broadly in line with expecting contributors who are still around to answer questions about the licensing/copyright status of code they’ve previously submitted in general, right? I think that it’s something we’d reasonably expect people to do and that it would not be very polite to arbitrarily refuse to do so if a concern comes up, but since the failure case of “they’re just not around in the project any more” is always present I’m not sure if it needs explicit policy wording beyond our general social norms (“Focusing on what is best for the community” per the CoC, and so on).

[7c6f434c]

Strictly speaking we do not know exactly (yet) the extent — per-jurisdiction — of questions about licensing status, but maybe we should already collect the data where feasible.

But as long as your choice is deliberate here, fair enough, thanks for consideration!

[infinisil]

I'd like to highlight #516544 as a recent AI related controversy likely needing a policy, but not covered by this current PR

[truh]

The emoji reactions might not be a representative sample but it appears like people overwhelmingly support the name change.

[mdaniels5757]

Taken too literally, "belief in its correctness" would seem to prohibit e.g. submitting a PR that is known to be a regression for feedback. Maybe:

Suggested change

	Before submission, they are expected to establish a reasonable level of understanding of the contribution and belief in its correctness.
	Before submission, they are expected to establish a reasonable level of understanding of the contribution and (unless they disclose otherwise) belief in its correctness.

?

[emilazy]

Perhaps this is covered by this existing exemption?:

• Use of automation in a contribution clearly marked as not being ready for review (e.g. a draft pull request) is exempt from the requirement for full self‐review, as long as some amount of review has been done and it is expected that the requirements will be met by the time it is marked as ready. This does not waive any other requirement.

Edit: Ah, I guess “ready for review” here is too strong. Maybe just adjusting that to “ready for merge”?

[mdaniels5757]

I have thought about making automated PRs, as an alternative to (smaller) treewides where there is worry about functionality (e.g. removing dead code, where it's often not clear whether the code should be dead or alive). The advantage would be that, with one PR per package (or per unique set of maintainers, or per, like, 5 packages), the maintainers could be requested for review, and request changes, approve, or even merge themselves with the merge bot. (And, because it would be mine, I would be able to easily look at PRs, respond to feedback, close, merge, etc.)

I haven't actually created this. But I think it would be useful in some circumstances, and so I'd be reluctant to prohibit it entirely?

[KiaraGrouwstra]

off-topic (?): i think i've seen considerations (by @infinisil?) on using a single PR for tree-wide changes making for easier reverts - tho for all i know this might depend on the topic as well

[7c6f434c]

Also, if a maintainer has an objection appplicable to multiple packages in the change, it is a bit annoying to paste it to all the relevant PRs… Unique set of maintainers is not really enough to guarantee low amount of per-maintainer spam. If a specific maintainer agrees, one can break out a specific subset of changes after their review comment.

[emilazy]

It sounds to me like this is a process you’d drive with yourself in the loop for a specific treewide, right, @mdaniels5757? I think that doesn’t count as the fully‐automated zero‐intervention no‐oversight bot case this is intended to rule out.

[mdaniels5757]

emilazy: Yes, that's correct. OK, good to hear.

[WillemToorenburgh]

I am quite opposed to Assisted-by: and Co-authored-by: tags in commits, because it helps LLM companies. My suspicion is that coding-focused LLM tools started using this tag pattern to help themselves avoid the so-called Model Collapse problem, where models trained on the output of other models leads to a drop in model efficacy. By instituting a policy of requiring such a commit trailer, we are opting-in to helping the very LLM companies that are besieging the internet with their relentless crawling, by giving a positive and policy-mandated confirmation of commits they shouldn't incorporate into their latest round of training.

EDIT: realized I committed review faux-pas of not including thoughts on remediation.

Beyond my personal ideal of auto-closing any PR which contains these commit trailers, the only thing that I can think of would be to instead require a similar string in PR description bodies. It'd still be straightforward to consume in an automated manner for Nixpkgs' management purposes, and offers at least one level of indirection to not so explicitly help LLM companies. Downside is that it may still (eventually) introduce that same consistent indicator in the Git commit history, but at least it's not quite as regular.

---

Apologies if this has already been mentioned elsewhere. I searched through comments but wasn't able to find anything.

[SomeoneSerge]

How about Assited-By: but without brand names

[SomeoneSerge]

The concern is fair, and was brought up e.g. at #514587 (comment): we're picky about who we promote at nixcon, why not in git log...

I like git-blames and would like to be able to roughly assess which lines come from contributors I know through how many handshakes. Similarly I'd like to know roughly which lines are generated. Metadata in commit messages mostly does the job. Co-authored-by: klanka as the baseline. (further discussion about what other metadata to include: #514587 (comment))

[7c6f434c]

An argument for PR description is also that this is more visible on review. I guess we could also say explicitly that package maintainers may establish stricter constraints on generated code in their area of responsibility than the bare minimum baseline requirements over Nixpkgs?

Additionally, maybe we should say that PR authors MAY add Assisted-by commit headers, for whatever they consider a tool. To make signal expensive to use at scale, one needs deviations from naive expectations in both directions, after all.

[KiaraGrouwstra]

@SomeoneSerge:

Co-authored-by: klanka

nit: while adding a layer of indirection, one could argue adding such metadata might still not fully address the concern raised by @WillemToorenburgh here, tho i'd concur on removing the advertising

[emilazy]

(Joining threads: I’ve responded to some of the points raised here in #514587 (comment).)

[GalladeGuy]

I am quite opposed to Assisted-by: and Co-authored-by: tags in commits, because it helps LLM companies. My suspicion is that coding-focused LLM tools started using this tag pattern to help themselves avoid the so-called Model Collapse problem, where models trained on the output of other models leads to a drop in model efficacy. By instituting a policy of requiring such a commit trailer, we are opting-in to helping the very LLM companies that are besieging the internet with their relentless crawling, by giving a positive and policy-mandated confirmation of commits they shouldn't incorporate into their latest round of training.

This is largely not true. The "model collapse" problem as it is commonly described is a myth. Current SOTA LLMs are actually trained on large amounts of synthetic data, including data generated by older models or previous versions of the same model. While it's not public how this data is used, there are examples of open weights models like Arcee Trinity that use as much as 50% synthetic data during pretraining. This is a big part of how LLMs have continued to improve even as novel human-created data has become harder to find. It's also why OpenAI and Anthropic are always complaining about Chinese labs distilling from their models (i.e. using ChatGPT and Claude outputs as training data for their own models). They wouldn't be upset about it if it didn't work!

So tagging AI-assisted commits is not helping AI companies, because they are likely not avoiding AI-generated code to begin with. Of course, if they wanted to avoid it, I'm sure they have more reliable AI detectors for internal use which do not rely on bespoke commit footers. I don't think it makes sense to not require marking AI-assisted commits just because of a small chance it would slightly benefit AI companies, when requiring them seems like it would almost certainly benefit nixpkgs maintainers much more.

[WillemToorenburgh]

If what you're saying is accurate, then I've been mis-informed, and would withdraw my concern from the discussion. Thank you for the new information!

[KiaraGrouwstra]

In summary of the two discussion threads here, here is a version foregoing the (more machine-readable) commit-level provenance in favor of transparency aimed at humans:

Suggested change

	All covered use of automated tooling for a contribution must be disclosed as part of that contribution.
	In the case of LLM‐based AI tooling used for commits, this **must** be in the form of a Git commit trailer in the format `Assisted-by: AGENT_NAME:MODEL_VERSION`.
	A `Co-authored-by:` trailer does not satisfy this policy.
	Any adequate form of disclosure is permitted for other kinds of tooling and contribution.
	Pull request summaries must be disclosed separately to commits.
	All covered use of automated tooling for a contribution must be disclosed as part of that contribution.
	Any adequate form of disclosure is permitted, such as disclaimers in the pull request.
	`Co-authored-by:` commit trailers are discouraged over their use to market specific tools.

[WillemToorenburgh]

Well done. I would find this much easier to swallow, should it end up in the final copy

[SomeoneSerge]

I'm in favour of the document suggesting an explicit marker (Assisted-by: whatever) that makes it easier to automatically filter the commits, but discouraging ads

[KiaraGrouwstra]

@SomeoneSerge could you submit a formal code edit suggestion here to that extent, so we could gauge relative support?

[emilazy]

I continue to believe that disclosure is the foundation of any effective policy. I made many of my points in #514587 (comment), but I want to expand on them since this has come up a few times. (I’ll address points from both threads, #514587 (comment) and #514587 (comment), to try and keep the discussion on this topic centralized.)

I really want to challenge the idea that the purpose of transparency is promotion. Putting corporate logos front and centre as valued sponsors on a community‐facing page with money exchanging hands, as mentioned in #514587 (comment), is a very different matter to transparency requirements as part of our contribution workflow. We have no restrictions on the disclosure of funding for contributions, even from companies that have been declined for sponsorships, and I think we should encourage it more so we can increase transparency and take conflicts of interest into account. Some companies require employees to use corporate emails or include disclaimers to contribute to FOSS to signify their claimed copyright interest in the work; those are valuable for licence compliance matters and shouldn’t be banned on the grounds of advertising. We have informal precedent for expecting people to disclose the automation they’ve used for certain kinds of changes, but no precedent for preventing or discouraging people from explaining what tools they used to create a change.

Separate disclosure of commits, pull requests, and comments is important to uphold the communication norms discussed in #514587 (comment), and we should try to avoid have load‐bearing attributions for the provenance of source code locked up solely in GitHub and unavailable when viewing commits in the repository. But even an Assisted-by: trailer without any detail would, I think, be a mistake. We have seen this tooling change drastically over a short period, as per #514587 (comment), and a foundational principle of this policy is that the degree and nature of the automation being used for a contribution has a meaningful effect on how reviewers will want to approach it.

It’s also relevant to future policy work; if we are going to review how this initial policy goes and amend it in response to the data we collect as a result of the transparency requirements, knowing what kinds of tools are being used and how, and being able to make apples‐to‐apples comparisons about how it’s going, will be vital. I also agree with #514587 (comment) that such an audit trail is important not just for our own visibility but for potential future legal compliance.

I do agree with the points raised that the specific format currently listed in the policy is currently an awkward balance of overly constrained and underspecified, and we are working on amending it.

Of course, any discussion of any company or product promotes awareness of it to some extent, but we don’t set our communication standards based on that; honestly, I’d say Nixpkgs packaging corporate software advertises far more than attribution for a functional purpose as part of development does. I don’t think that custom commit trailers in Nixpkgs that don’t surface in the GitHub UI is a particularly valuable advertising space for companies at the scale we’re talking about here, and even omitting specific tool and model names wouldn’t eliminate concerns about advertising; insofar as disclosures do act as advertising, even a bare minimum disclosure of “LLMs were used” required to serve the goals of the policy would serve as advertising for the industry as a whole, and with few major players in the space would likely be comparatively effective. I believe we shouldn’t set policy that puts us in a worse position just because there is always some unavoidable element of promotion in any kind of transparent disclosure. Even having such extensive policy discussions about this serves as a kind of promotion, after all, and yet is clearly worth it.

I don’t think I could stand behind a policy that weakens the transparency requirements to the extent being suggested in these threads.

[SomeoneSerge]

...knowing what kinds of tools are being used and how, and being able to make apples‐to‐apples comparisons about how it’s going, will be vital

Like, yes, but this ship has sailed when the industry has given up on training their own models and settled for either renting the Cloud options, or running distilled models. It would be completely useless to type Assisted-by: opus4.7, because opus4.7 is not one fixed thing, but some hundreds of versions of the model and the harness redeployed under the same release name and behind the same API. I would love to have each generated commit to contain an Assisted-by: with a (non)flake-ref to the model, describing the data, the hardware, the schedule that was used to produce it, but there's literally nobody who does that today afaik

[KiaraGrouwstra]

on the higher levels of transparency alluded to by @SomeoneSerge, NLNet has a policy mandating commit descriptions include full interaction logs. while i'm not sure that was necessarily written with coding agents in mind, it might further increase commit size as well.

[WillemToorenburgh]

Truthfully, the advertisement component never entered my mind when I was writing my initial comment. For me, it's all about not making Nixpkgs overtly helpful to LLM companies. On the other side of the coin, I deeply understand the desire to avoid vendor lock-in with LLM usage disclosures only living in GitHub pull request bodies. I appreciate that this is a discussion, and the effort that the maintainers are putting into it.

It's clumsy and more human, but what if we had something like an AUDIT/ directory, where each PR has a corresponding AUDIT/GH-<PR number>.md file containing at least the title and body of the PR (perhaps prompt transcripts too), and a requirement for the file to be included in a given PR when an LLM was used? Such a requirement could possibly be made easier to comply with via some scripts... but this is almost certainly scope creep.

[7c6f434c]

either renting the Cloud options, or running distilled models.

I would say that in terms of specifying the version, distilled models run locally are at least pinnable, and often base / distillation / fine-tuning combination is roughly known, and we'll see if provenance based on weight signatures ends up working. If it is not local, we just have a case of Cloud with all of its usual problems and misleading naming.

[emilazy]

In response to the discussion so far, we’ve made some minor amendments to the proposed policy to:

• Clarify expectations around responsibility and review, especially in regard to communication during reviews, in line with my previous comment at CONTRIBUTING.md: establish initial automation/AI/LLM policy #514587 (comment).

• Add Discourse topics relating to Nixpkgs development to the scope, as suggested in CONTRIBUTING.md: establish initial automation/AI/LLM policy #514587 (comment) and CONTRIBUTING.md: establish initial automation/AI/LLM policy #514587 (comment).

• Make the Assisted-by: format less prescriptive, as although we consider a reasonable level of detail in disclosure critical, we think that specifying a rigid format is not so important as to be worth the amount of text it would require to specify, per discussion in CONTRIBUTING.md: establish initial automation/AI/LLM policy #514587 (comment) and CONTRIBUTING.md: establish initial automation/AI/LLM policy #514587 (comment).

• Exempt maintainer‐approved update bots, as suggested in CONTRIBUTING.md: establish initial automation/AI/LLM policy #514587 (comment).

• Clarify the wording around procedures for closing non‐compliant contributions, per the discussion in CONTRIBUTING.md: establish initial automation/AI/LLM policy #514587 (comment).

Thanks everyone for all the feedback! We plan to leave the discussion open until the end of the week.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/nixpkgs-core-team-update-2025-05-11-automation-ai-policy-feedback-and-new-members-wanted/77567/1

[SigmaSquadron]

Codeowner hat: The technical aspects of the changes to the issue templates are acceptable, thus this approval.

---

I have intentionally not commented on the actual policy for personal reasons, but I would nonetheless like to thank the Nixpkgs Core Team for their work on this, which will surely be an improvement over the status quo of (mostly) indiscriminately allowing LLM usage.

[skyethepinkcat]

I'm a minor contributor to nixpkgs, just wanted to say this policy seems very good to me. I think an outright ban would be basically infeasible and just lead to lots of untagged code getting committed, so this solution is a good trade off. Thanks so much to everyone who has worked on it and keeps Nixpkgs running <3

[numinit]

This is good policy particularly because it also formalizes what was already best practice surrounding things like doing complex treewides with scripts that others can verify. Consider things like bulk hash format changing as one example, we'd likely need more than "trust me, I ran a script" there (or even no comment whatsoever).

I've got no other comments except that this work is greatly appreciated, thank you for being the gardener.

[alyssais]

Thank you everybody for the thoughtful feedback and discussion. The Nixpkgs core team has decided to move forward with this policy, in its current state as amended thanks to community feedback.

As we've already said, we do not intend for this policy to be set in stone. We'll monitor how it goes and consider potential amendments based on our own observations and community feedback.