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

[Peter Cock]

Absolutely if we were to accept some AI use, it would be wise to
insist it be declared. This can be a general point about automated
bulk changes - for example we have precedent with formatting tools
like black or other linting tools with fixers, of recording the tool
version and command in the commit message. Likewise I have often
recorded sed commands for non-trivial or multi-file search-and-replace
operations. It would be nice to encourage that level of disclosure by
default - particularly for any later bug triage to understand how/why
there was a side effect from a deterministic automated edit.

Your analogy "That would be like telling a carpenter they can't use an
electric drill because in the wrong hands a drill can be dangerous."
is cute, but to turn it round: We don't encourage carpenters to take
and use any blueprints they find left out on a coffee shop table and
pass it off as their own work. On the otherhand with 'boiler plate
code' then any copyright abuse claim is very tenous and wouldn't be
taken seriously.

Peter

On Sat, Apr 25, 2026 at 9:08 AM Jones Kelly, Terence Carleton
<terence.jones at charite.de> wrote:
>
> Hi all
>
> Thanks for the interesting conversation. Like João and Michiel, I would also argue against a total ban, but rather in favour of a policy that allows AI to be used in some contexts, by some people, adhering to some conditions.
>
> BTW, I write "we" below, for convenience not because I consider myself part of the BioPython developer community, I'm just an interested user.
>
> There are two main reasons I think AI use should be allowed under agreed upon conditions. First, AI can already pass the Turing Test with natural language so there's no way we're going to be able to detect AI-written code going forward if it's created by a human who tells the AI to make its contributions look human. A ban may actually incentivize deceptive behaviour and make things worse. Second, the AI tools are so powerful that, in the right hands, they offer the possibility of getting things done at high speed and without sacrificing quality.
>
> It might be interesting for people to think about this from the following perspective: if you interviewed a programmer and they performed the way the AI does today, would you hire them?  A few years ago when I first tried getting ChatGPT to write some code for me, I decided to "interview" it, and I would never have hired someone who behaved in that way. Today the answer is completely the opposite, I'd hire the person on the spot. But I would know (or quickly learn) that that person needs to be carefully supervised. And if they made the kinds of mistakes AI makes today, I wouldn't fire them, I'd get better at managing/supervising them and assigning them tasks.
>
> So we could consider a policy that instead of a ban says that we welcome contributions that have been made with the assistance of an AI but you must follow some rules. And that the BioPython community reserves the right to summarily reject or completely ignore contributions which violate or appear to violate any of these conditions.
>
> Rule #1 would be that you have to declare AI usage.
>
> We could insist that people (or those not known to the BioPython community?) using an AI must provide a transcript of the AI sessions.  I've done this in several recent projects for accountability and review reasons. It's actually difficult to get Claude code to write a verbatim transcript with the inputs and outputs (excluding diffs along the way).
>
> I would encourage known contributors who understand the rules and are experienced enough programmers to use AI as much as they like. I'd do this for sure, even if just privately, because it doesn't make sense to forbid very good and experienced programmers from responsibly using what is basically a power tool to help get things done. That would be like telling a carpenter they can't use an electric drill because in the wrong hands a drill can be dangerous.
>
> I have no idea to what extent people on this mailing list have been using a tool like Claude code but if you haven't, I would strongly encourage you to give it a go. I'm not an overly excitable person but I find the capabilities of Claude code to be quite incredible. Not just for writing new code but also for debugging and investigating results. It's also capable of being incredibly dumb. And of course its code sometimes has bugs which may be difficult to detect, just like human code.  Using it requires careful thought about how to structure code and tests, and insisting that it prove to you that it has done what you asked. But this is the way we work when programming in isolation and with each other on human teams.  So to me this level of carefulness is already fairly normal.
>
> Sorry for so many words!
>
> Regards,
> Terry