> If you do not understand the ticket, if you do not understand the solution, or if you do not understand the feedback on your PR, then your use of LLM is hurting Django as a whole.
> Django contributors want to help others, they want to cultivate community, and they want to help you become a regular contributor. Before LLMs, this 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.
> In this way, an LLM is a facade of yourself. It helps you project understanding, contemplation, and growth, but it removes the transparency and vulnerability of being a human.
> For a reviewer, it’s demoralizing to communicate with a facade of a human.
> This is because contributing to open source, especially Django, is a communal endeavor. Removing your humanity from that experience makes that endeavor more difficult. If you use an LLM to contribute to Django, it needs to be as a complementary tool, not as your vehicle.
I am going to try to make these points to my team, because I am seeing a huge influx of AI-generated PRs where the submitter interacts with CodeRabbit etc. by having Claude/Codex respond to feedback on their behalf.
There is little doubt that if we as an industry fail to establish and defend a healthy culture for this sort of thing, it's going to lead to a whole lot of rot and demoralization.
Will humans take this to heart and actually do the right thing? Sadly, probably not.
One of the main issues is that pointing to your GitHub contributions and activity is now part of the hiring process. So people will continue to try to game the system by using LLMs to automate that whole process.
"I have contributed to X, Y, and Z projects" - when they actually have little to no understanding of those projects or exactly how their PR works. It was (somehow) accepted and that's that.
Some projects ( https://news.ycombinator.com/item?id=46730504 ) are setting a norm to disclose AI usage. Another project simply decided to pause contributions from external parties ( https://news.ycombinator.com/item?id=46642012 ). Instead of accepting driveby pull requests, contributors have to show a proof of work by working with one of the other collaborators.
Another project has started to decline to let users directly open issues ( https://news.ycombinator.com/item?id=46460319 ).
There's definitely an aspect here where the commons or good will effort of collaborators is being infringed upon by external parties who are unintentionally attacking their time and attention with low quality submissions that are now cheaper than ever to generate. It may be necessary to move to a more private community model of collaboration ( https://gnusha.org/pi/bitcoindev/CABaSBax-meEsC2013zKYJnC3ph... ).
edit: Also I applaud the debian project for their recent decision to defer and think harder about the nature of this problem. https://news.ycombinator.com/item?id=47324087
It's possible to prompt and get this as well, but obviously any of the big AI companies that want to increase engagement in their coding agent, and want to capture the open source market, should come up with a way to allow the LLM to produce unique of, but still correct code so that it doesn't look LLM-generated and can evade these kinds of checks.
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)
I've used an LLM to create patches for multiple projects. I would not have created said work without LLMs. I also reviewed the work afterward and provided tests to verify it.
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.
I don’t think anybody’s tracking the actual net-effects of any of this crap on productivity, just the “vibes” they get in the moment, using it. “I got my part of this particular thing done so fast!”
I believe that to be the case, in part, because not a lot of organizations are usefully tracking overall productivity to begin with. Too hard, too expensive. They might “track” it, but so poorly it’s basically meaningless. I don’t think they’ve turned that around on a dime just to see if the c-suite’s latest fad is good or bad (they never want a real answer to that kind of question anyway)
Are people generally unhappy with the outcomes of this? As anecdotally, it does seem to pass review later on. Code is getting through this way.
Instead of people buying the tokens themselves, they should just donate the money to the core contributors and let those people decide how to spend on tokens.
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.
[…]
> If you use an LLM to contribute to Django, it needs to be as a complementary tool, not as your vehicle.
Although I'm afraid big part of these LLM contributions may be people trying to build their portfolio. Some known project contributor sounds better than having some LLM generated code under your name.
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.
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.
It is not pride to have your name associated with an open source project, it is pride that the code works and the change is efficient. The reviewer should be on top of that.
and I hope an army of OpenClaw agents calls out the discrimination, so gatekeepers recognize that they have to coexist with this species
If the maintainers don't want to merge it for whatever reasons that's fine and nature of open source, but I think its petty to tell that same user who opened the PR you should have donated money instead of tokens.
I feel the successful OS projects will be the ones embracing the change, not stopping it. For example, automating code reviews with AI.
Errors are fine too. Just not negligence.
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.
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?
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...
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).
It makes it kind of unclear if you don't understand the difference between using CC to "investigate the codebase" so you can make a change which you (implicitly) do understand versus using an LLM to make a plausible looking PR although in actuality "you do not understand the ticket ... you do not understand the solution ... you do not understand the feedback on your PR"
Yes, you feel. And the author feels differently. We don't have evidence of what the impact of LLMs will be on a project over the long term. Many people are speculating it will be pure upside, this author is observing some issues with this model and speculating that there will be a detriment long-term.
The operative word here is "speculating." Until we have better evidence, we'll need to go with our hunches & best bets. It is a good thing that different people take different approaches rather than "everyone in on AI 100%." If the author is wrong time will tell.
I share code because I think it might be useful to others. Until very recently I welcomed contributions, but my time is limited and my patience has become exhausted.
I'm sorry I no longer accept PRs, but at the same time I continue to make my code available - if minor tweaks can be made to make that more useful for specific people they still have the ability to do that, I've not hidden my code and it is still available for people to modify/change as they see fit.
I accept LLM contributions to most of my projects, but have (only slightly less) strict rules around it. (My biggest rule is that you must acknowledge the DCO with an appropriate sign-off. If you don't, or if I believe you don't actually have the right to sign off the DCO, I will reject your change.) I will also never accept LLM-generated security reports on any of my projects.
I contribute to chezmoi, which has a strict no-LLM contribution (of any kind) policy. There've been a couple of recent user bans because they used LLM‡ and their contributions — in tickets, no less — included code instructions that could not have possibly worked.
Those of us who have those rules do so out of knowledge and self-respect, not out of gatekeeping or ignorance. We want people to contribute. We don't want garbage.
I think that there needs to be something in the repo itself (`.llm-permissions`?) which all agents look at and follow. Something like:
# .llm-permissions
Pull-Requests: No
Issues: No
Security: Yes
Translation Assistance: Yes
Code Completion: Yes
The one thing that I will never add or accept on my repos is AI code review. This is my code. I have to stand behind it and understand it.
‡ I disagree with those bans for practical reasons because the zero-tolerance stance wasn't visible everywhere to new contributors. I would personally have given these contributors one warning (closed and locked the issue and invited them to open a new issue without the LLM slop; second failure results in permanent ban). But I also understand where the developer of chezmoi is coming from.
You'll have to embrace the `ccc` compiler first, lol
Just like "etiquette" accomplishes no purpose except letting people easily figure out who put the effort into learning it, vs. who didn't.
Back then this distinguished by class, but ironically, today where's so easy to learn, it finally distinguishes by merit.
I treat jira like product owners treat the code. Which is infinitely humorous to me.
I watched someone ask Claude to replace all occurrences of a string instead of using a deterministic operation like “Find and Replace” available in the very same VSCode window they prompted Claude from.
You'd have to manage the contributions, or get your AI bots to manage them or something, but it would be great to have honeypots like this to attract all the low effort LLM slop.
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.
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.
Well let them put their money where their mouth is. Let's see what happens, see what the agents create or fail to create. See if we end up with a new OS, kernel all the way up to desktop environment.
If this is done, you should update it so it appears in the review queue.
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.
they are something to coexist with
the strawman aspect is out of scope
If something's not happening, something else's making it impractical. Saying this as a 10+ years product manager and R&D person with 20+ more years of engineering on top.
I also had to deal with "managers are just complicating things" or "users are stupid and don't understand anything"; do you think I complained? No, I had engineers barter trust of their ingenuity with trust of my wisdom, and brought them to customer calls and presented them to users almost like royalty, which made them incredibly respectful as soon as they saw what kind of crap users had to deal with.
What the parent comment was probably trying to say was something like "a completely reasonable, uncontroversial post that I'm glad to see them make", but chose milquetoast (a word that no normal human ever uses - and certainly not in casual conversation) due to an affectation of one kind or another.
> Use an LLM to develop your comprehension. Then communicate the best you can in your own words, then use an LLM to tweak that language. If you’re struggling to convey your ideas with someone, use an LLM more aggressively and mention that you used it. This makes it easier for others to see where your understanding is and where there are disconnects.
> There needs to be understanding when contributing to Django. There’s no way around it. Django has been around for 20 years and expects to be around for another 20. Any code being added to a project with that outlook on longevity must be well understood.
> There is no shortcut to understanding. If you want to contribute to Django, you will have to spend time reading, experimenting, and learning. Contributing to Django will help you grow as a developer.
> While it is nice to be listed as a contributor to Django, the growth you earn from it is incredibly more valuable.
> So please, stop using an LLM to the extent it hides you and your understanding. We want to know you, and we want to collaborate with you.
This advice is 95% not actionable and 100% not verifiable. It's full of hand-wavy good intentions. I understand completely where it's coming from, but 'trying to stop a tsunami with an umbrella' is a very good analogy - on one side, you have the above magical thinking, on the other, petaflops of compute which improve their reasoning capabilities exponentially.
"Spending your tokens to support Django by having an LLM work on tickets is not helpful. You and the community are better off donating that money to the Django Software Foundation instead."
Milquetoast perfectly describes it, I am happy to see less common words used around here (specially when the convey the intended meaning this precisely), and I find claiming "affectation" of the person who used it unnecessarily rude.
(Again, I must emphasize that this is not telling people to not use LLMs, any more than telling people to wear a seatbelt would somehow be telling them to not drive a car.)
Reading beyond the first line makes it clear that the problem is a lack of comprehension, not LLM use itself. Quoting:
> This isn’t about whether you use an LLM, it’s about whether you still understand what’s being contributed.
> If you do not understand the ticket, if you do not understand the solution, or if you do not understand the feedback on your PR, then your use of LLM is hurting Django as a whole.
Spending your tokens to support Django by having an LLM work on tickets is not helpful. You and the community are better off donating that money to the Django Software Foundation instead.
We’re in a new era where people don’t have to type out all of their code. I used an LLM to build a good part of the new functionality in the djangonaut.space site. I know I wouldn’t have shipped that much in that amount of time without using an LLM.
But Django is different. The level of quality is much, much higher. This is because it has a much larger user base, it changes slowly, and the community expects it to be in use 20 years from now. It’s partly why it’s such an honor to have your name among the list of contributors.
This isn’t about whether you use an LLM, it’s about whether you still understand what’s being contributed. What I see now is people who are using LLMs to generate the code and write the PR description and handle the feedback from the PR review. It’s to the extent where I can’t tell if there’d be a difference if the reviewer had just used the LLM themselves. And that is a big problem.
If you do not understand the ticket, if you do not understand the solution, or if you do not understand the feedback on your PR, then your use of LLM is hurting Django as a whole.
Django contributors want to help others, they want to cultivate community, and they want to help you become a regular contributor. Before LLMs, this 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.
In this way, an LLM is a facade of yourself. It helps you project understanding, contemplation, and growth, but it removes the transparency and vulnerability of being a human.
For a reviewer, it’s demoralizing to communicate with a facade of a human.
This is because contributing to open source, especially Django, is a communal endeavor. Removing your humanity from that experience makes that endeavor more difficult. If you use an LLM to contribute to Django, it needs to be as a complementary tool, not as your vehicle.
Use an LLM to develop your comprehension. Then communicate the best you can in your own words, then use an LLM to tweak that language. If you’re struggling to convey your ideas with someone, use an LLM more aggressively and mention that you used it. This makes it easier for others to see where your understanding is and where there are disconnects.
There needs to be understanding when contributing to Django. There’s no way around it. Django has been around for 20 years and expects to be around for another 20. Any code being added to a project with that outlook on longevity must be well understood.
There is no shortcut to understanding. If you want to contribute to Django, you will have to spend time reading, experimenting, and learning. Contributing to Django will help you grow as a developer.
While it is nice to be listed as a contributor to Django, the growth you earn from it is incredibly more valuable.
So please, stop using an LLM to the extent it hides you and your understanding. We want to know you, and we want to collaborate with you.