Posted by dcreager 1 day ago
Think most people recognize though that AI can generate more than humans can reviewing so the model does need to change somehow. Either less AI on submitting side or more on reviewing side (if that’s even viable)
Even before AI I used to ban linting so I could spot and reject code that clearly showed no effort was put in it.
First occurrence of "undreadable" got a note, and a second one got a rejection. And by "undreadable" I do not intend missing semicolons or parenthesis styles or meaningless things like that. I mean obscured semantics or overcrowding and so on.
Last year, I had some free time to try to contribute back to the framework.
It was incredibly difficult. Difficult to find a ticket to work on, difficult to navigate the codebase, difficult to get feedback on a ticket and approved.
As such, I see the appeal of using an LLM to help first time contributors. If I had Claude code back then, I might have used it to figure out the bug I was eventually assigned.
I empathize with the authors argument tho. God knows what kind of slop they are served everyday.
This is all to say, we live in a weird time for open source contributors and maintainers. And I only wish the best for all of those out there giving up their free time.
Dont have any solutions ATM, only money to donate to these folks.
The fellows and other volunteers are spending a much greater amount of time handling the increased volume.
[1] https://www.djangoproject.com/weblog/2026/feb/04/recent-tren...
A number of times now, I have found real value in someone just dropping into the bugtracker to restate the bug description in clearer terms or providing a shorter reproducer. Even if the flaw in Django had been fixed right away, I would not have pulled patches from master anyway. So the ticket comment was still a useful contribution to django, because I could use it in resolving the issue in how my software triggered it.
That ticket now just sits there. The implementation is done, the review is done, there are no objections. But it's not merged.
I think something is deeply wrong and I have no idea what it is.
If this is done, you should update it so it appears in the review queue.
Suppose I encounter a bug in a FOSS library I am using. Suppose then that I fix the bug using Claude or something. Suppose I then thoroughly test it and everything works fine. Isn’t it kind of selfish to not try and upstream it?
It was so easy prior to AI.
That plus ai sycophancy means, in my opinion, a great portion of contributions made in this manner will be bad, and waste maintainers time - which is obviously undesirable.
On my first week of claude code I submitted a PR to a FOSS and I was 100% sure it was correct - ai was giving me great confindence, and it worked! But I had no clue about how that software worked - at all. I later sent an email to the maintainer, apologizing.
Some changes are in the area of "Well no one did that yet because no one needed it or had time for it", or "Well shit, no one thought of that". If Claude Code did these changes with good documentation and good intent and guidance behind it, why not? It is an honest and valid improvement to the library.
Some other changes rip core assumptions of the library apart. They were easy, because Claude Code did the ripping and tearing. In such a case, is it really a contribution to improve the library? If we end up with a wasteland of code torn apart by AI just because?
Errors are fine too. Just not negligence.
imagine someone emailed you a diff with the note "idk lol. my friend sent me this, and it works on my machine". would you even consider applying it?
If I got a PR for one of my projects where the fix was LLM-generated, I wouldn't dismiss it out of hand, but I would want to see (somehow) that the submitter themselves understood both the problem and the solution. Along with all the other usual qualifiers (passes tests, follows existing coding style, diff doesn't touch more than it has to, etc). There's likely no one easy way to tell this, however.
I remember when I was getting started with Django in the 0.9 days most of the assistance you got on the IRC channel was along the lines of "it's in this file here in the source, read it, understand it, and if you still have a question come back and ask again". I probably learned more about writing idiomatic Python from that than anything else.
I can confirm that that was the general mindset back then, and I think that's what made the project last for 20 years. I myself ended up doing some monkey-patching for the admin interface on 0.92 (or 0.91? it's been a lot of time since then), all as the result of me going through the source-code. Definitely not the cleanest solution, even back then, but it made one getting to know the underlying code so much more.
Sure, I thought, this'll be fun.
Holy shit. It was something I'd started working on in the aforementioned 0.9x days, and which someone else had, uh, "extended and modified" after I left the web dev place where I'd worked at the time. Remarkably it was still pretty understandable.
I didn't want anything to do with the person that ran the site, not even just to take money off them, so I passed on it.
I think it's perfectly doable to use an LLM to write into the Django codebase, but you'll have to supervise and feedback it very carefully (which is the article's point).
I can't help but feel there's something very, very important in this line for the future of dev.
> Before LLMs, [high quality code contribution] was easier to sense because you were limited to communicating what you understood. With LLMs, it’s much easier to communicate a sense of understanding to the reviewer, but the reviewer doesn’t know if you actually understood it.
Now my twist on this: This same spirit is why local politics at the administrative level feels more functional than identity politics at the national level. The people that take the time to get involved with quotidian issues (e.g. for their school district) get their hands dirty and appreciate the specific constraints and tradeoffs. The very act of digging in changes you.