Eric J Ma's Website

I just got back from SciPy 2026, my eleventh year at the conference. The loudest thread across the week was AI in open source, and what maintainers are supposed to do about it.

The thread surfaced in a Scientific Python community session, run as a Birds of a Feather (BoF). Stefan van der Walt walked us through the project's work: the specification process (SPECS, the Python-community analog of PEPs and NEPs), four developer summits, shared tools like RepoReview and spin, and MyST as the documentation engine behind the next Jupyter Book. Then the floor opened for Q&A.

Someone raised a worry I haven't been able to shake. As Claude and its cousins make it cheap to spin up a working tool, maintainers build bespoke utilities for themselves and stop contributing back. The room offered an analogy: if everyone builds their own vehicle, the roads stop working. Someone drives a tank, someone else a bicycle, and the shared infrastructure collapses. The cheap-prototype problem makes it worse: the version a person publishes often only works for them, pushing the next person to build their own.

That conversation was still on my mind when a pull request hit my review queue that week, giving me a cleaner frame for these questions.

Two flavors of AI in open source

Henry Schreiner opened PR #821 on scientific-python/cookie to add an AI page to the cookie project, the Scientific Python community's recommended project template. (Henry started the draft by pointing Claude Opus at the issue and reworking the output by hand, which is exactly the meta-lesson of the page itself.) The page opens with a distinction I believe is useful here:

• A developer driving an interactive AI harness with a capable model, reading the output, and taking responsibility for the result.
• Low-cost models running unattended in automated systems that mass-produce pull requests.

The first is a power tool. The second is slop. Most maintainer frustration about AI contributions comes from the second case, and most of the value comes from the first. Conflating them produces bad policy.

I see this conflation constantly. A contributor opens a pull request with a generic "I improved the code" message, the diff is a wall of token churn, and when you ask a question the answer comes back in the same flat model-voice. That is slop with a human attached. The human is the relay, not the author. Reviewing it takes longer than writing the change myself.

The first flavor is what I want more of. A contributor who uses an agent to engage with my project, reads the result, and defends every line, is using a tool. I want to encourage them. Encouragement only lands if contributors can tell which flavor you're asking for, which means writing it down before they open a PR.

Write your stance down

The heart of Henry's PR is AI_POLICY.md, a project-level file that tells contributors what you expect. The PR sketches three tiers you can adapt.

All in. AI-assisted contributions are welcome on the same footing as any other, as long as they meet your quality bar and are disclosed.

Moderate. AI assistance is fine, but the contributor has to show real human involvement and prior buy-in before opening the PR.

Minimal. AI-generated PRs are discouraged or restricted. Use this if you have limited review capacity.

Which one fits depends on the project. The point, however, is that you should pick one. A contributor reading your AI_POLICY.md should know what to expect before they open a PR, and a maintainer closing a PR should be able to point at the policy rather than re-litigate it every time.

The cookie PR leaves the policy out of the template by default, letting each project select and modify their own. I think that's right. A project with one overworked maintainer is in a different situation from a project with twenty regular contributors, and the policy should reflect that. The maintainer reserves the right to take whatever action fits the project; nobody is paying for this work, which means no contributor is owed a review.

Engage with the human, not the bot

The policy also has a recommendation for how maintainers should treat contributors, and my favorite passage is tucked inside a callout:

If you maintain a project: try to engage with the human. If they are willing to interact (and not just type "address the review" into their harness), treat them like a human, even if you also see the AI working on their behalf. They also may use AI to address a language barrier.

The failure mode of an AI-assisted contribution is the human tagging out, which is the power-tool flavor sliding back into slop. A contributor pastes review comments into their harness, pastes the harness's reply back into the PR, and walks away. The maintainer is now arguing with a bot. That's draining, and it's disrespectful of volunteer time.

The policy handles this directly with one rule: keep human review human-to-human. If an AI is responding on your behalf, say so, with a disclaimer line at the top of the comment. You're accountable for every change you submit. Don't make a maintainer talk to an AI without knowing it.

Disclosure norms pay off here too. The PR recommends the Linux kernel's Assisted-by: <harness>:<model> trailer for commits. A convention I first saw Daniel Chen use is the :robot: _AI text below_ :robot: line for any AI-generated prose in a PR or comment. Knowing which model was used lets a reviewer run a different model family to cross-check the work (the PR calls this the "rubber-duck" technique). It also just respects the maintainer. Hiding your process when you contribute to open source is a small lie, repeated. It stings because it withholds the context a reviewer needs to do their job.

Context is the bottleneck

Both worries, fragmentation and slop, trace back to the same constraint: the cost of producing code dropped faster than the cost of producing context. When anyone can ship a working prototype in an afternoon, the scarce thing is the understanding of what the code should do, why it should do it, and how it fits with what already exists.

This shows up in every issue triage. The issue that says "the build is broken" with no logs, no repro, no environment info. The PR that addresses a problem the contributor never confirmed anyone had. The agent-generated patch that is locally correct and globally wrong because nobody told it about the other module that depends on the current behavior. In each case the gap is the same: context that lives in someone's head and nowhere in writing.

What helps is documentation written for an agent to read. The cookie PR includes a section on AGENTS.md, the cross-harness standard file that captures how your repository works: preferred command runners, architecture notes, conventions, traps. A good AGENTS.md makes the AI far more effective, because the AI stops guessing. The same instinct applies to issues: write down what you tried, what you expected, what you saw. The agent working from a thorough issue is a different animal from the agent working from a one-liner. Agents are also good at producing that context. A minimal reproducible example is tedious for a human; for an agent that can spin up the environment, run the code, and iterate until the bug fires, it's a short task. Your AI_POLICY.md can ask contributors to use their agent to produce a self-contained repro first. The maintainer gets something runnable; the contributor finds out whether the bug is real before anyone else spends time on it. On the PR side, prompts that shape agent behavior belong in AGENTS.md, which travels with the code and reaches every contributor's agent: ask for the smallest diff that fixes one thing, and for stacked PRs when a change needs more. AGENTS.md itself is documentation written for an agent.

AGENTS.md captures mechanics. Intent is a different kind of context, and it matters just as much. Thomas Caswell's SciPy keynote traced the story of Matplotlib's design decisions, the kind of narrative that lives in maintainers' heads and leaves with them. Writing that story down as design docs (a high-level design for the project, then low-level designs and EARS requirement specs per feature) gives an agent the intent it needs to stay grounded. The docs will shift as the project evolves. That malleability is fine, because the current version still beats an agent guessing.

Later in Q&A, someone who works with NASA data raised the same point from their own side: they had started asking whether to write their documentation for a chatbot instead of a human. They had started shipping documentation as markdown alongside the rendered HTML, because the markdown is what the chatbot consumes. The rendered page is for a human; the source is for the agent. The lesson generalizes. If you want agents to do good work on your project, give them something to read.

Be courageous

Documentation is what you write for the agent; your AI policy is what you write for your contributors.

If you maintain an open source project, pick an AI policy from any of the three tiers. Write it down, commit it, link to it from your contributing guide, and enforce it. The action that fits your project is correct. A solo maintainer with no review capacity is within their rights to say "no unsolicited AI PRs, full stop." A healthy project with twenty contributors and review bandwidth can be all-in, and benefit from it. Both are legitimate. What's undesirable is having no policy, drifting, and burning out.

That burnout lands on you. The action that fits you is also legitimate. If engaging with AI-assisted contributors drains you, require prior buy-in, close the PR, or step back from the project for a week. Some projects are solely volunteer. Protecting your capacity is part of the job.

Protecting your capacity and welcoming contributors go together: hold the line against tag-out bots, and give your time to the humans behind real contributions. When a contributor shows up willing to engage, even when their harness did most of the typing, treat them like a human. Read their PR, ask your questions, and teach them the parts they don't know yet. That is how open source onboards people. Thomas Caswell onboarded me to Matplotlib a decade ago by walking me through seventy pull requests over two months. The first four were painful for him, but he did it anyway, and I'm still here. That people connection is invaluable.

That human connection is what got more valuable this year. The cost of writing code dropped. The value of a maintainer who knows their project, writes down their stance, and engages with the humans who show up rose, because agents amplify whoever brings the judgment. That's the work. Go do it, and don't apologize for the policy you choose.