This is a deep topic and the relevant concerns and ideas could go on for months. However, it isn’t the job of this forum to solve the world’s AI ethics and economics problems. We may be part of a much larger conversation and move its needle a little, given numpy’s visibility, but the main concern should be the product.
I suggest formalizing a list of product-oriented code values to evaluate decisions against. Suggestions (This is NOT a formal proposal! It’s food for discussion. It’s been a long time [pre-GIT!] since I contributed to the project and others will have a better sense for what will actually work.): 1. Code must be demonstrated to be under an acceptable license. 2. Code must solve a specific problem within the scope of the package. 3. Code must be clear to human readers. For short calculations or processes, it should be easy to verify by inspection. 4. Code must be well documented both internally (comments) and in text (docstring, design documents, tutorials, etc.). 5. Code must be written in good and project-compliant style. 6. Code must be demonstrated to be correct by a significant number of tests that exercises every line and includes corner and branch cases, comparing to known correct results. 7. Code must not present extraordinary difficulty to human coders who wish to find bugs, to fix them, or to extend the code. 8. Code must not present extraordinary difficulty to human students trying to learn from it. 9. Etc. My point is simple: Break this down to fundamental code requirements and require them of all new code. If AI code satisfies them, then perhaps we’ll be happier with it, too. This lets us regulate AI code on merits valid over the long term, letting AI grow into utility for us, rather than locking in short-term rules about current AI technology that will be obsolete in a month. I think it will be clear if someone tries to add a value that only serves to eliminate AI code. The list above could have been written in the project’s infancy, long before AI coding existed. It would have served a useful purpose and it would not have looked strained or contrived. Today, it requires a human to evaluate it. Someday, we might trust an AI to do that. Yes, there will be existing code that doesn’t quite satisfy all the requirements (e.g., someone recently wanted more internal design documents). This doesn’t mean we can’t require that for new code going forward, and it might motivate us to provide incentives for improving the codebase. Also, the last two are about code clarity. We are not writing a textbook, but I think that it’s a good coding metric to be able to say that numpy code is clear enough to be pointed to as an example of how to do something right in the real world. If it isn’t done right, do we want it in numpy? And, I think some AI code could be ready today. If you prompt an AI to write something short (a simple bug patch, say), you can take that code and tweak it, verify it, make sure it’s clear and well documented, verify the tests for it, etc. If it’s short enough, or you change it enough, the license question will be moot. But, at the moment, I think that’s a very short piece of code. –jh– Joe Harrington University of Central Florida (Long-ago founder and funder of the numpy and scipy docs project.) On 2/9/26 17:48, [email protected]<mailto:[email protected]> wrote: Subject: [Numpy-discussion] Re: Current policy on AI-generated code in NumPy From: "Stefan van der Walt" <[email protected]><mailto:[email protected]> Date: 2/9/26, 17:26 To: "Discussion of Numerical Python" <[email protected]><mailto:[email protected]> On Mon, Feb 9, 2026, at 13:58, Ralf Gommers via NumPy-Discussion wrote: On Mon, Feb 9, 2026 at 6:23 PM Matthew Brett via NumPy-Discussion <[email protected]<mailto:[email protected]>> wrote: I think it's correct that it's not sensible for policies to reflect things like dislike of AI's use of energy or the effects on the environment of AI data centers. However, it seems obvious to me that it is sensible for policies to take into account the effect of AI on learning. Why would that be obvious? It seems incredibly presumptuous to decide for other people what methods or tools they are or aren't allowed to use for learning. We're not running a high school or university here. The way I read Matthew's comment is not that we should prescribe how people use their tools, but that we should be aware of the risks we are facing, and also communicate those risks to contributors who want to use AI tools to do NumPy development. This also presumes that you, or we, are able to determine what usage of AI tools helps or hinders learning. That is not possible at the level of individuals: people can learn in very different ways, plus it will strongly depend on how the tools are used. And even in the aggregate it's not practically possible: most of the studies that have been referenced in this and linked thread (a) are one-offs, and often inconsistent with each other, and (b) already outdated, given how fast the field is developing. It is true that things are moving fast, and while the original METR study (which has been informally replicated in other settings) is perhaps outdated, Anthropic's just-released paper shows a broadly similar trend. Specifically, they show that time-to-solution is faster for junior developers, but not so much for senior developers. They also show that knowledge about the library is worse, having done a task with AI vs without. I'm sure, over time, we will figure out the best patterns for using AI and how to avoid the worst traps. Best regards, Stéfan
_______________________________________________ NumPy-Discussion mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3//lists/numpy-discussion.python.org Member address: [email protected]
