[Biopython] [ext] Re: Generative AI policy for contributions to Biopython

[Jones Kelly, Terence Carleton]

Slightly off-topic (and apologies if this has been suggested and I missed it): would it make sense to put top-level instruction files for agents into the BioPython repo? They'd then automatically be in place for anyone who cloned the repo and started using an agent on the codebase. The instructions could include following code style, staying focused only fixing one problem, writing a complete transcript of dev sessions including explanations and choices, writing tests, giving attribution (where possible), using type hints, etc. I use Claude Code on a daily basis now and it is pretty good at following explicit instructions. If it were my project and I was forbidding the use of AI, I wouldn't really want my top-level repo dir polluted with files for agents, though, so this suggestion might get a flat no on that basis.

Regarding the legal aspect, I should think that in some cases (like fixing a specific bug) it would be possible to ask the AI to provide URLs giving sources with permissive licenses. I.e., it could explain that it implemented a fix based on code found at such-and-such a URL, that was public domain or licensed in some open way. That could be added to the pr code as a comment. In such cases BioPython would be in the clear, no?

BTW, another aspect of AI-aided development that I don't think has been mentioned is debugging. Claude Code is fantastic for that - I have had it track down some very human-cryptic problems (in Python, in C, in PowerBasic), sometimes diagnosed in seconds based on a minimal description of the misbehaviour. I don't like to keep saying this is incredible, so I won't. But should BioPython have an explicit policy clause about this, or is everything permissible except what has been forbidden? It's easy to imagine someone submitting a human-written patch which is actually broken, based on a complicated and incorrect AI diagnosis that they didn't fully understand. That's not so different from incorrect code written by an AI - the incorrectness starts with the AI and is not detected by the human.

Thanks for all the discussion!

Regards,
Terry

From: Biopython <biopython-bounces at biopython.org> on behalf of Peter Cock <p.j.a.cock at googlemail.com>
Date: Sunday, 11. October 2026 at 13:12
To: biopython at biopython.org <biopython at biopython.org>
Subject: [ext] Re: [Biopython] Generative AI policy for contributions to Biopython

Dear Biopythoneers,

I have failed so far to convince many of our committer pool to approve
my no AI policy pull request, despite softening it with explicitly
tolerated tool use (outside of the commits themselves) based on the
Python project stance (which I feel is too lax).

https://github.com/biopython/biopython/pull/5241

Some still view the draft as too strict (see the PR and recent linked
PRs, some examples being small AI generated changes that would be
acceptable if from a human). I understand that Michiel favours a more
permissive policy like NumPy or SciPy adopted, based on technical
merits and still expecting human understanding of the code. Given his
long standing and on going substantial contributions to Biopython, his
views carry weight.

A unanimous consensus does not seem to be possible. Might an interim
AI ban with a view to reviewing this in say three years work? Some of
the objections may well be moot at that point. Otherwise we may have
to opt for a majority rule amongst our current maintainers.

Would any of you like to put forward an alternative AI policy draft
pull request based on NumPy and SciPy please (I find the Python
project text too light on detail), including our consensus that the
communications at least should be human written (but possibly computer
translated into English). I think we need something concretely enough
that we can review PRs consistently. One of the advantages of a no-AI
policy is the line for what is or isn't acceptable is much easier to
follow.

In arguing for rejecting AI contributions, I'd focused on the legal
uncertainty argument from a project stewardship perspective (copyright
etc), thinking this was a strong enough point in and of itself. There
are other strong community based-arguments from a project perspective
for rejecting or at least shackling AI contributions including leaving
less room for beginners and mentoring, and very real risks of
maintainer fatigue or burnout. And there are the ethical objections
including unacknowledged plagiarism, excessive energy use, and abusive
collection of training data. And financial too, with the costs of
computers and parts rocketing.

Regards,

Peter


On Fri, Oct 2, 2026 at 11:01 AM Peter Cock <p.j.a.cock at googlemail.com> wrote:
>
> I'd also like a second opinion on merging an AI usage declaration on
> the PR template now:
>
> https://github.com/biopython/biopython/pull/5334
>
> I don't expect the PR template change in itself to be contentious,
> even if we do not yet have agreement on rejecting AI written commits.
>
> Hoping to get AI agents to self-disclose via a directive in our
> contributing file seems worth a try (it has been shown to work on
> other projects).
>
> Peter
>
_______________________________________________
Biopython mailing list  -  Biopython at biopython.org
https://mailman.open-bio.org/mailman/listinfo/biopython
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.open-bio.org/pipermail/biopython/attachments/20261012/1a84c740/attachment-0001.htm>