Re: Current policy on AI-generated code in NumPy
Matthew Brett via NumPy-Discussion <[email protected]> Mon, 9 Feb 2026 22:05:28 +0000
| Newsgroups | gmane.comp.python.numeric.general |
|---|---|
| Message-ID | <CAH6Pt5q=k+y8x=3wxhzmBCdUBfiTe4H36STdvest6_R8xYsaNg@mail.gmail.com> |
Hi, On Mon, Feb 9, 2026 at 10:00 PM Ralf Gommers via NumPy-Discussion <[email protected]> wrote: > > > > On Mon, Feb 9, 2026 at 6:23 PM Matthew Brett via NumPy-Discussion <[email protected]> wrote: >> >> Hi, >> >> I thought your (Ralf's) distinction was interesting, so here's some >> more reflection. The distinction starts at: >> >> > we don't prescribe to others how they are and aren't allowed to contribute (to the extent possible) >> >> 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. > > At most we can provide docs and a happy path for some types of tools, but that's about it. We cannot prescribe anything. > >> But why the distinction? >> >> On reflection, it seems to me that policies should reflect only on the >> interests of the project, but those interests should be seen broadly, >> and include planning for future community and maintainers. Thus, >> environmental concerns might well be important in general, but do not >> bear directly on the work of the project. Therefore the project's >> managers have no mandate to act on that concern, at least without >> explicit consensus. However, any sensible project should be thinking >> about the state of maintenance in 5 or 10 years. Therefore, the >> project does have a potential mandate to prefer tools that will lead >> to better overall understanding, communication, community building, or >> code quality in the future. > > > 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's easy to think of ways that using AI tools for contributing could help with learning: > > Simple time gain: once one has done the same thing a number of times and it becomes routine, automate it with AI so the contributor can spend more time focusing on learning about new topics. > Improved code quality and internal consistency from letting AI tools fix up and verify design rules (e.g., how type promotion is handled) will lead to the ability to learn the concepts from the code base in a more consistent fashion. > Use as a brainstorming tool to suggest multiple design options, broadening discovery. > We could ask AI tools to write internal design documentation, of the kind that only a few handfuls of maintainers would be able to write (but almost never do, because we're too busy). There are important parts of the code base that have no documentation beyond some scattered code comments. > Give contributors feedback that the maintainers often don't have the time or interest to give, in a timely fashion or at all. > Writing throwaway prototypes of ideas for NumPy that would otherwise take too long to implement and would never get done, thereby allowing to learn if something is feasible at all, or a good idea. > Learning to use the AI tools themselves: this may well become an essential skill for most software-related roles in the near future. > > Same for future community & new maintainers: > > Current maintainers may enjoy both learning something new and automating the more tedious parts of maintenance, so they can focus on the more interesting parts. That will aid maintainer retention. > > Ilhan's point is a great example here. He just finished a massive amount of work rewriting code from Fortran into C. And now found that AI tools can be quite helpful in that endeavour (while 6 months ago they weren't). This work must have been extremely tedious (thanks again for biting that bullet Ilhan). And it really wasn't fun to review either. > > New contributors may default to working with these tools more often than not, and be turned off from contributing by rules that say they cannot use their default workflow. > > I'm sure it's not hard to think of more along these lines, but I hope the point is clear. Yes - but that's a different point - I was only pointing out learning is relevant, and that it is worth discussing. Cheers, Matthew _______________________________________________ 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]