I agree that this PR can be closed based on the new policy. It sounds like you missing Chris's review was then just an oversight.
Jason moorepants.info +01 530-601-9791 On Sat, Jan 31, 2026 at 1:15 PM Oscar Benjamin <[email protected]> wrote: > 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 > . > -- 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/CAP7f1Ai-zEjOaJJ9rBXzXA%2B3i9o5hGhmfO2VPBrt_mtZNRdviQ%40mail.gmail.com.
