Community Discussion: using LLMs to contribute to Project Jupyter

[marthacryan]

The Jupyter Executive Council would like to open a community-wide discussion about the use of LLMs and AI-assisted tools in contributions to Jupyter projects.

Our goal is to better understand how contributors and maintainers are experiencing this shift so we can develop thoughtful policy recommendations for subprojects. Our goal is not to define a single Jupyter-wide LLM contribution policy, we are surfacing ideas and opinions for others to consider across the project.

We recognize this is a topic that people feel strongly about, and those feelings span a wide range. Some of us are enthusiastic about the ways these tools can lower barriers to contribution and improve the quality of work. Others have serious concerns about the volume and quality of AI-generated contributions, the ecological cost of running these systems at scale, the potential impact on underrepresented and marginalized communities, or the broader implications of LLM use in open source more generally. All of these perspectives are valid and welcome here. Please engage with good faith and mutual respect, keeping our Code of Conduct in mind.

To help focus the discussion, a few questions to consider:

• What are you seeing? What has your experience been with LLM-assisted contributions so far?
• What's working, and what isn't? Where have these tools helped, or created extra burden?
• What would a reasonable policy look like to you? We're aiming to protect maintainers from low-quality or high-volume AI contributions, while still supporting contributors using these tools to learn or improve their work.

We'd love to follow this up with a live call. For now, please share your thoughts and experiences!

@jupyter/software-steering-council Please help draw attention to this thread in your subprojects! We're looking to get a broad understanding of the experiences of contributors in Jupyter.

edited by @choldgraf to clarify our goals

[mfisher87]

Thank you for opening a broader community conversation on this!

Here's a thread on AI usage policy we're developing for JupyterGIS / GeoJupyter. All welcome to comment. Apologies if I've contradicted myself at some point, this is hard and I've found myself unsure and open to influence on this issue and my opinions are changing over time. My guiding value is inclusiveness, and I'm looking for a path that balances including people who may have great ideas but don't feel comfortable in a "software engineering space" while not driving maintainers to burnout.

What are you seeing? What has your experience been with LLM-assisted contributions so far?

On the GeoJupyter project, which is not an official subproject, we've had a few experiences with LLM-related contributions. I see them in two categories:

1. Well-intentioned people who are not experts in the programming language they're contributing code to who are willing to take ownership over their work, and are worried that they'll be judged for using LLMs to "punch above their weight". They take pains reach out (usually on Zulip) to ask if it's OK if they use LLMs and reassure maintainers that they won't make them have a conversation with an LLM or submit code they haven't personally reviewed. This manifests for maintainers as a similar experience to interacting with someone who is not an expert in our codebase -- they need some guidance, they listen, and we get to a mergeable state reasonably quickly.

2. Fully-automated contributions that may be solving a real problem or not, but either way are not capable of tricking maintainers into believing they are human.

I think (1) is great. There's an accessibility problem being solved here. I want folks to feel comfortable using LLMs as a way to both learn and make an impact on a project at the same time. For many that's more fun, effective, and rewarding than doing leetcode or Euler problems. They're learning from real-world codebases and their unique challenges and history, they're building relationships with people, and they're making stuff that can improve someone's life. I'm not seeing this category of contributor as careless or disrespectful. They showed up to our project for a reason, and LLMs are just a tool to enable them to be there, not the reason they want to be there. AND I'm seeing them put at least as much thought in to responsible LLM use as we, the maintainers, are.

I think we can all agree we don't want (2).

I haven't seen (A) folks using LLMs for to enable them to engage with our project in English, and I fully support that use case of course; or (B) something in between (1) and (2) where the contributor is using LLMs and just carelessly throwing slop at us to build a resume; or, as far as I know (C) an LLM that can trick us into thinking it's a human.

I can't say (B) doesn't exist just because I haven't seen it; my project is smaller than probably every Jupyter sub-project and I wouldn't be surprised if others have seen (B). But I see (B) as an exception to the rule. And I think it's worth assuming we're dealing with a good-hearted (1) until we have evidence we're dealing with (B).

If we start seeing (C)... I don't know. There's nothing we can do at that point. We can't start suspecting everyone we haven't met face-to-face at a conference or we'll alienate the majority of prospective contributors, and our projects will die. I don't think this is worth thinking about right now.

What's working, and what isn't? Where have these tools helped, or created extra burden?

So far, just treating people like they are in category (1) and going from there. All category (1) contributors have been a benefit to our project.

Looking at their GitHub profile to see if they're in category (2)and closing those PRs; I've so far had no challenge identifying category (2). E.g. 120 pull requests against 116 projects in 1 month. That's not a human and we all know it.

What would a reasonable policy look like to you?

I worry in some conversations we're leaning too far on the conservative side and approaching exclusivity. I also worry that on reading this, some folks might see themselves and think I don't respect their stance. I do, deeply. I feel a sense of my craft that I love, that gives me a feeling of making a mark on the world, that gives me a feeling of being able to express myself and do art (in an unconventional sense), being attacked. And that feels bad. But also, I'm more and more finding ways to use these tools to enhance my craft without damaging my self-expression. For example, as an "improved" rubber duck. Give me a ton of ideas, all wrong, and they can act as a springboard towards finding the solution I've been looking for. I didn't have a full idea of what I don't want before, and now I do. Another human is the best way to do this, but at midnight, when I'm frustrated with my own indecisiveness and don't have access to a human? I'll take a machine's bad ideas in a heartbeat. And this gives me hope that while the technology poses massive risk, there are social solutions that can leverage LLMs to make our collective lives better.

LLMs can be an accessibility tool, like curb cuts or one of those buttons that opens the door. In the sense of enabling people with lots of software engineering experience but are having a rough day, or people with minimal/no software engineering background, or people with disabilities, to more confidently engage with projects that they can legitimately provide value to, but otherwise couldn't. Confidence is important: we all ask ourselves "do I belong here" and have different tolerances for where on the belonging spectrum we need to be before we take action and make our voice heard.

I really like the Zulip project's AI policy summary in their recent blog post for being succinct, clear, and respecting humans on both sides of a contribution (i.e. inclusive of contributors and valuing time of maintainers):

End-to-end human responsibility for work and the communication around it. You always need to understand, test, and explain the changes you’re proposing to make, whether or not you used an LLM as part of your process to produce them.

Clear and concise communication about points that actually require discussion. While we allow carefully edited AI-generated PR descriptions, we’ve had to ban AI-generated chat messages in the development community as too disruptive.

I feel like my post turned in to a ramble in the end. Sorry 🙃

[agoose77]

<personal>
I feel incredibly conflicted about LLMs. A significant concern of mine is that most conversations focus only on the technical, and tend to omit consideration of the externalities. I think most of the time this is accidental, and not in bad faith, but I don't want to ignore these factors, and I don't think the Jupyter project should either. This can sometimes make conversations about LLMs harder to enter into, because reconciling participants with some shared understanding of externalities is predominantly a conversation about values and ethics, not about technical tradeoffs. I am aware that many of my peers do not hold the same views as I do, and I try to engage with this conflict as compassionately and respectfully as possible. This can be difficult, however, when we convene in a shared space and look to collaborate together.
</personal>

On to the question at hand!

What are you seeing? What has your experience been with LLM-assisted contributions so far?

In Jupyter Book, most of the LLM contributions that I think I'm seeing are human-in-the-loop. Some of these are from longer-term contributors, whilst others might be from contributors I'm unfamiliar with. This might be to help write documentation, or actual code generation.

What's working, and what isn't? Where have these tools helped, or created extra burden?

In general, I trust the humans that are using these tools. However, I have observed that we rarely (although this is improving) have authors tell us that they're using LLMs in the PRs themselves. I find myself realising that LLMs are being used when I spot telltale signs like helper functions, "pretty" comment boxes, etc.

I find this tiring. Humans tend to do the smallest amount of work required, which provides a unique prior for understanding intent with technical contributions. LLMs tend to completely void this prior. Humans tend to write things with purpose, whereas LLMs write things (as we know) by token completing, with emergent purpose. I have recently found myself blindly reviewing PRs in different modes. On reflection, I realise that I'm reacting to the signals of LLM assisted contributions, due to this phenomenon.

Whilst LLMs lower the boundary to contributors, this naturally increases the burden on maintainers. We're facing a new pressure to accept contributions from contributors that do not understand the long-term / broader consequences of these PRs. I believe that a contributor can 100% understand every line of a PR that they authored with the help of LLMs, but I do not think that taking ownership of LLM output produces the same kind of solution as one that someone hand-rolls.¹ Naturally in open source software, there's a fairly large gap between "this works" and "this is the right solution". We know from educational studies that reason a solution and understanding it doesn't have the same long-term behaviour as "figuring it out for yourself". I find this the key issue above the "high-volume" / "low-quality" contributions that even the staunchest LLM proponents would agree are problematic.

Ultimately, I'm concerned that LLM tools do not address the ultimate bottleneck of maintainer resources — if anything, I think LLM tooling pushes us further into resource scarcity. Someone can contribute a high-quality well-reasoned "drive-by" PR that adds a needed feature. But, if they don't stick around to maintain it ... that's also a problem for us. This has always been a risk, but the numbers have shifted.

What would a reasonable policy look like to you? We're aiming to protect maintainers from low-quality or high-volume AI contributions, while still supporting contributors using these tools to learn or improve their work.

I'm reluctant to hold a staunchly opposing view. Bluntly, I know that doing so would alienate many of my colleagues, peers, and friends who enjoy using these tools. I also acknowledge that I do not know what the right answer is in the face of complex and conflicting issues such as improving accessibility of our projects and balancing future technical debt against delivering near-term vital features.

So, given this, I would benefit from a policy that:

1. Requires people to share that they've used LLMs, and attempt to provide some context about the way that they were used.

Footnotes

1. This is 100% not "LLMs will never be human" fearmongering push-back. It's a statement of what I'm currently seeing. ↩

[manics]

JupyterHub discussion/PR on a policy: jupyterhub/team-compass#880

[krassowski]

I get lots of "can I work on this issue". I want to be able to say:

Yes - I am happy to review all contributions which involve human effort beyond running an LLM or a claw-style agent (careful planning, testing, experimenting with multiple approaches). Please note that we may disregard and close low-quality PRs if obviously produced by LLM; while we can iterate on low-quality PRs with a human to couch them into being a better contributor, we cannot do so with LLMs.

and point to some kind of policy that backs it.

[krassowski]

I see PRs with very low value, generated by bad use of LLMs. They waste a lot of time and CI. I want to be able to say:

I'm closing this because it is not meeting the quality threshold and after three rounds of feedback, this is not making any progress/keeps making the same mistake/was clearly not tested by end user

I reviewed multiple PRs like that over in JupyterLab. Again, humans learn, LLMs don't. Some LLM-based agents have memory and can retain information momentarily, but they are still unable to address issues which require a human end user to test.

Some LLM-based contributions are great, and I do want to merge them. But for those which waste days of my time, I want to be allowed to close them without facing a backlash about a single maintainer being the decision maker to blame (see what happened in matplotlib case; there they at least had a policy already when the indecent occurred).

[krassowski]

I see companies holding back with OSS contributions because they worry that their code is tainted by having been developed with (varying levels) of LLM assistance (a controversial topic). I want to be able to say:

Yes, any code contributions are welcome, and we will not penalize users of AI. We are excited that LLMs lower the barrier to contributions, adding tests coverage and help scan code for some kinds of issues. However, we require:

• the same high coding standards and end-result quality of LLM and human contributions
• the same commitment for future maintenance as from human contributions (see puppies in CORPORATE.md of JupyterLab)

Thus, we require a human to be a contact point who takes responsibility for any contributions.

I worry that without us having a freedom to say so, companies may stop contributing patches, retreat into their own silos, and we will lose the great collaboration forum we have.

This may be controversial because it invites AI-generated content. IMO the path forward is to let subprojects decide; e.g., JupyterHub could say that they do not want such contributions, but JupyterLab could say "Welcome (if you play nicely)".

[manics]

IMO the path forward is to let subprojects decide

I can't think of any other option. Clearly JupyterHub is against. On the other hand I assume jupyter-ai is in favour of good contributions?

What might be useful is acknowledgement that subprojects have differing views, and that the EC will support the policies of each subproject if something needs to be escalated, e.g. in the case of the Matplotlib example. Though would the EC need to review each policy first?

Are any other subprojects working on their own LLM/AI contribution policy?

[Zsailer]

Clearly JupyterHub is against.

I'd encourage us to be very careful not to overstate consensus here. I don't believe this specific statement is true. While some in JupyterHub are against AI assistance of any kind, I've talked with folks in Hub that are not clearly against using these tools and have felt frustrated at times to have others speak so strongly on their behalf.

Looking at the current state of the JupyterHub PR referenced above, it doesn't seem to fully reject AI-assistance but

1. raises important, shared concerns
2. asks for full disclosure, respect of the maintainers time, deep understanding of the work submitted, and
3. sets a (great!) high bar for the quality of contributions of this kind.

[manics]

Sorry, I should've been more specific. The policy the JupyterHub organisation has drafted so far is against. Personally I'm some where in the middle, I've had some success with using LLM assistance in personal projects and have also had lots of failures, and seen several examples of security report and PRs in JupyterHub that waste our time. Regardless, I'm happy to accept that others in the JupyterHub org have stronger views.

The view of the organisation is not the same as the views of individual members of the organisation, and given the divergence of views I don't think we'll achieve complete agreement.

If you or anyone else has concerns please comment on the JupyterHub PR. I think this is the sort of discussion that could benefit from an in-person discussion, but unfortunately that's not practical.

[minrk]

I love @agoose77's comment, very well put and expressed my feelings as well. I am also seeing a lot of time wasted by undisclosed AI PRs, like @krassowski.

What would a reasonable policy look like to you? We're aiming to protect maintainers from low-quality or high-volume AI contributions, while still supporting contributors using these tools to learn or improve their work.

I would like to take the strongest possible stance against AI tools, because I don't believe any relevant technology has caused more direct harm specifically to community software projects and principles and infrastructure. But we're a community project and I obviously don't speak for everyone, and we should represent our actual shared values, whatever they may be. Clearly LLMs enable a massive increase in low quality contributions that are proving costly to deal with. Also, commercial LLMs like Claude aggressively violate the principles of community software for profit. The ambiguity of not having a policy (whatever it is!) to communicate to contributors is its own cost, so I support having clear, simple policies, at the subproject level if there's sufficient divergence of views. It would probably also be nice to have a 'default' policy at the top level subprojects could use if the don't want to spend the time creating their own.

The JupyterHub policy indeed doesn't currently strictly prohibit LLM-assisted contributions, though my initial proposal mostly did. The current requirement is one where the contributor asserts "authorship" (thanks @mfisher87 for helping figure out how to express that, I'm still trying to come up with the best language, since the current language is reading more mechanical and strict than I intended), whatever tools they may have used to get there, and it's genuinely up to the author to convince themselves they are the author, and it's not worth maintainer time to try to dispute that. I hope we're trying to come to an actual consensus, which definitely wasn't with my starting point, and that's okay!

[rowanc1]

Very much echo @mfisher87's example from Zulip, which seem sensible, contained, measured, and human-centered.

End-to-end human responsibility for work and the communication around it. You always need to understand, test, and explain the changes you’re proposing to make, whether or not you used an LLM as part of your process to produce them.

Clear and concise communication about points that actually require discussion. While we allow carefully edited AI-generated PR descriptions, we’ve had to ban AI-generated chat messages in the development community as too disruptive.

Both of those are just good practices to reinforce! Going beyond that to ban or even discourage the use of modern technologies, seems like it excludes/discourages many potential contributors and quiet voices¹ with good intent or good practices. Centering the discussion on the human responsibilities (understand it, flag where you don't, be aware of maintainer burden through clarity and being concise) are norms we can encourage regardless of the tools you use to create your work.

Footnotes

1. Many of the early career researchers I work with have both good intentions and new super-powers — as well as a poor understanding of the consequences of submitting work they did not review/write. The message being "ensure you take responsibility, and make sure you are concise to reduce burden on people who review your work" is very different than "the tool that just gave you super powers is bad". I also think this is not new advice, it just requires more amplification in the age of AI. ↩

[mmcky]

I second the comments made by @rowanc1, @mfisher87.

At QuantEcon we have generally had a net positive experience with LLM supporting PRs and contributions (but we have only started allowing these tools post November 2025 -- when we felt the balanced flipped from low to medium/high quality results). We put GREAT emphasis on the human making the submission is responsible for the submission. Tests need to be completed, PR descriptions need to be read, edited and reviewed (if written with LLMs), we enforce quality over quantity in any RA training -- and we ask RAs read ALL the code they are submitting, understand it -- and challenge the LLMs to improve it.

People need to have discussions, certainly no bots or automatic merge decisions.

We are also considering community guidelines around AGENTS.md files to help standardise common practices.

(I just think all LLM providers should be required to give Open Source projects FREE access -- given they used GitHub as a source for training these models) - but this is starting to veer into politics and opinion so I'll stop there 😄

[westurner]

From "[jupyter/governance] AI-assisted code policy: "Literature Review" (Issue #326)"
#326 (comment) :

From the pulpproject org account README.md: https://github.com/pulp/.github/blob/main/profile%2FREADME.md#L26-L53 :

• https://github.com/pulp/pulp-docs/blob/main/pulpproject.org/help/more/governance/ai_policy.md

There are three rules for code contributions to the Pulp Project:

1. All contributors must indicate in the commit message of their contribution if they used AI to create them and the contributor is fully responsible for the content that they submit.

   This can be a label such as Assisted By: <Tool> or Generated by: <Tool> based on what was used.
   This label should be representative of the contribution and how it was created for full transparency.
   The commit message must also be clear about how it is solving a problem/making an improvement if it is not immediately obvious.

2. If there are any copyrighted materials that are included in any contribution, the author must confirm that they have permission to use that material from the owners.

   This can be in the form of an open source license, public domain declaration, or other proof that complies with the Pulp Project's licensing policy.
   This evidence must be included prior to contribution to the project.

3. All AI contributions must follow the definition of Open Source as well as any applicable policies & licenses that the Pulp Project uses.

A label such as:

• Assisted By: <Tool> or
• Generated by: <Tool>

Copilot through GitHub.com (without manual editing in vscode or Codespaces with a devcontainer.json, for example) has this metadata on commits and the branch prefix copilot/.

For example, https://github.com/westurner/ssl-config-generator/tree/copilot/add-pq-ciphers-support .. mozilla/ssl-config-generator@master...westurner:ssl-config-generator:copilot/add-pq-ciphers-support adds this to commit messages:

Agent-Logs-Url: https://github.com/westurner/ssl-config-generator/sessions/30ab488c-75f9-484e-89c9-e7a422ec8a45

Co-authored-by: westurner <50891+westurner@users.noreply.github.com>

That's probably more accountable than Assisted By: <Tool_name or URI>, but it doesn't say which model was used. Though the model name and version can be determined by retrieving the Agent-Logs-Url: <URL>.

Tools should add such structured data to commit messages