Let's just clarify the individual points here: - Do we agree that the code is AI generated? - Do we agree that this was not honestly disclosed? - Do we agree that the AI policy prohibits that and says we will close a PR in that case?
I agree that it should be done more politely but if we don't have a clear "undisclosed AI means close PR" rule then I think that the policy is a failure. Any suggestion that more effort, thought, discussions etc goes into the decision to close an AI PR is missing the point that the problem they cause is the time that it takes to sift and review them. The effort ratio where someone can type a prompt and have an AI make a PR and then a reviewer has to spend actual time considering its technical merit is precisely the problem and we need a solution that is minimal effort on the maintainer side. I'm not sure if I even noticed that Chris was reviewing the PR. I just saw people mentioning LLMs, looked and saw that the code was AI generated and then looked and saw that the AI disclosure was dishonest. It is perhaps worth pointing out that the sympy repo has been drowning in PRs for a long time. There are 921 open PRs and that number only goes up. This was already unsustainable before the AI PRs came along. Oscar On Sat, 31 Jan 2026 at 06:56, Jason Moore <[email protected]> wrote: > > A core dev was engaging with the PR, so closing it over top of them is not > polite. Ideally we would not do such a thing at all (AI involved or not). We > should also be more polite in the comments to the contributor, even if we are > talking to an AI bot. > > My suggestion would be that any core dev who wants to apply the policy should > ask the other core devs involved in the PR discussion before making the > universal call. > > Jason > moorepants.info > +01 530-601-9791 > > > On Fri, Jan 30, 2026 at 11:12 PM Oscar Benjamin <[email protected]> > wrote: >> >> On Fri, 30 Jan 2026 at 20:28, Chris Smith <[email protected]> wrote: >> > >> > I’d like to raise a process question regarding the application of the AI >> > policy to reviewed pull requests. >> > >> > A recent PR addressing a long-standing performance issue in degree() was >> > closed with the label “AI slop,” >> >> I definitely should have been more polite so I will acknowledge that. >> I guess I must have been getting annoyed with there being so many low >> quality and AI PRs. >> >> If you want to review and merge that PR then go ahead. >> >> > The author disclosed AI usage and stated that finding the source of the >> > problem and design were manual >> > >> > The PR appears to comply with current AI policy as written (or at least I >> > don't see the violation) >> >> I think that this is a bit disingenuous and that you know that the >> code was all written by AI and that this was not honestly disclosed. >> The AI policy says that you should explain how you have used AI and >> that is in the PR template but what was written there was just "review >> suggestions were provided by an AI tool". Maybe you read that >> differently from me but what it should honestly say is "the code was >> all written by Claude". >> >> Much like I can see a few lines of code and know immediately that it >> was written by Christopher Smith I can also see a few lines of code >> and know that it was written by Claude or its ilk. I'm pretty sure >> that you can also read a few lines of code and say the same things. >> >> > As the AI policy currently stands, it permits AI-assisted contributions >> > provided the author understands and takes responsibility for the code. And >> > having reviewed the code, I can't see why labelling it as “AI slop” is a >> > sufficient basis for closure in the absence of technical objections. >> >> I think that you are misunderstanding what I would consider to be the >> problem of AI PRs. It is not about the actual code and its quality. >> Many AI tools can produce better code than many of the people >> currently opening SymPy PRs. The problem with the AI PRs is that they >> are harder to review and are overloading us with spam. The problem >> also is that if people don't explain honestly how they have used AI >> then that in itself makes it harder to review the code because you >> have to pick apart the AI hallucinations from the human >> misunderstandings. >> >> The other problem is that if we really want AI PRs then we don't >> actually need new contributors to bring them. It would be far more >> efficient for those of us who would have reviewed the PR to make AI >> PRs directly without the other person getting in the way. >> >> Technically the main problem with the PR is just the fact that it is >> classic more code on top of code creating more space for bugs without >> actually delivering much value. Unfortunately this is exactly what AI >> makes easy: you ask it to do something and it just spits out more and >> more code. The code might seem to work but if we merge it into the >> codebase then it needs to be maintained and soon there will be bug >> reports saying that degree doesn't work in this or that corner case >> and then someone will have to review the bug reports and then someone >> else will have an AI spit out more code on top of code and so on. >> >> The PR may "fix" some issue but how much actual value are you getting? >> It doesn't actually make it safe to call degree on an expression >> because it still has a fallback case where it would effectively go >> into an infinite loop like degree((x - 1)**1000000 - (x + >> 1)**1000000). The proper fix would be to have a version of Poly that >> does not expand everything and that would be something very useful >> that could be used in lots of places for much more than just degree >> like it could also get the leading coefficient, support different >> domains, evaluate and so on. >> >> In any case all of the low quality PRs around now are seriously >> getting me down. I think for now I will stop reviewing PRs from anyone >> but a select list of people whose PRs don't annoy me (people who can >> consistently produce something that does not require many iterations >> unless it delivers significant actual value). This will mean that >> unless other people do a lot more PR reviewing most GSOC-related PRs >> are not going to get reviewed. >> >> -- >> Oscar >> >> -- >> You received this message because you are subscribed to the Google Groups >> "sympy" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion visit >> https://groups.google.com/d/msgid/sympy/CAHVvXxTi4x5ZBAeUmWhLZsU%2B_ffYFCL7Y87HnKhRAjMd0XL3sQ%40mail.gmail.com. > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/d/msgid/sympy/CAP7f1AjKhWt1yq4aP1rOHxBr-6ctdA7NCJ7eqCeqNSgNVPMGNA%40mail.gmail.com. -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/sympy/CAHVvXxRx49c8U07sH6-2foEWA04LdrSjT82nCmX0M8pkXLuCKg%40mail.gmail.com.
