s/Django/the codebase/g, and the point stands against any repo for which there is code review by humans:

> 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.

The best people I've worked with tended to go out of their way to make it as easy for me as possible to critique their ideas or implementations.

They spelled out exactly their assumptions, the gaps in their knowledge, what they have struggled with during implementation, behavior they observed but don't fully understand, etc.

Their default position was that their contribution was not worth considering unless they can sell it to the reviewer, by not assuming their change deserves to get merged because of their seniority or authority, but by making the other person understand how any why it works. Especially so if the reviewer was their junior.

When describing the architecture, they made an effort to communicate it so clearly that it became trivial for others to spot flaws, and attack their ideas. They not only provided you with ammunition to shoot down their ideas, they handed you a loaded gun, safety off, and showed you exactly where to point it.

If I see that level of humility and self-introspection in a PR, I'm not worried, regardless of whether or not an LLM was involved.

But then there's people that created PRs with changes where the stack didn't even boot / compile, because of trivial errors. They already did that before, and now they've got LLMs. Those are the contributions I'm very worried about.

So unlike people in other threads here, I don't agree at all with "If the code works, does it matter how it was produced and presented?". For me, the meta / out-of-band information about a contribution is a massive signal, today more than ever.

This is getting really out of control at the moment and I'm not exactly sure what the best way to fix it is, but this is a very good post in terms of expressing the why this is not acceptable and why the burden if shifting on the wrong people.

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.

I like the idea of donating money instead of tokens. I think django contributors are likely to know how to spend those tokens better than I might, as I am not a django core contributor.

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

"For a reviewer, it’s demoralizing to communicate with a facade of a human."

This is so important. Most humans like communicating with other humans. For many (note, I didn't say all) open source collaborators, this is part of the reward of collaborating on open source.

Making them communicate with a bot pretending to be a human instead removes the reward and makes it feel terrible, like the worst job nobody would want. If you spent any time at all actually trying to help the contributor underestand and develop their skills, you just feel like an idiot. It lowers the patience of everyone in the entire endeavor, ruining it for everyone.

It's like every new innovation at this point is exacerbating the problem of us choosing short term rewards over long time horizon rewards. The incentive structure simply doesn't support people who want to view things from the bird's eye view. Once you see game theory, you really can't unsee it.

Great message but I wonder if the people who do everything via LLM would even care to read such a message. And at what point is it hard/impossible to judge whether something is entirely LLM or not? I sometimes struggle a lot with this being OSS maintainer myself

Perhaps we should start making LLM- open source projects (clearly marked as such). Created by LLMs, open for LLM contributions, with some clearly defined protocols I'd be interesting where it would go. I imagine it could start as a project with a simple instruction file to include in your project to try to find abstractions which can be useful to others as a library and look for specific kind of libraries. Some people want to help others even if they are sharing effectively money+time rather than their skill.

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.

Well said:

> 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.

Curious what simon thinks about using an LLM to work on Django...

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 agree with the sentiment but I am not sure the best way to go forward.

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.

AI so often doesn't actually increase productivity - it just shifts the burden of work from the person creating to the person who has to check and evaluate that creation.

In this case, offloading yet more work onto the maintainers of the package, because you can't be bothered, but still want credit.

I love Django. Ive been using it professionally and on side projects extensively for the past 10 years. Plus I maintain(ed) a couple highly used packages for Django (django-import-export and django-dramatiq).

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.

Interesting breadth of takes in the comments.

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)

With my type of development, I haven't run into the types of things, directly, that you very well explained, but I have personally run into the pain, I confess, of being OVERLY reliant on LLMs. I continue to try and learn from those hard lessons and develop a set of best practices in using AI to help me avoid those pain points in the future. This growing set of best practices is helping me a lot. The reason that I liked your article is because it confirmed some of those best practices that I have had to learn the hard way. Thanks!

I totally get this and I also think it's now the case that making a PR of any significant complexity, for a project you're not a maintainer of, isn't necessarily giving that project anything of value. That project's maintainers can run the same prompts you are running - and if they do, they'll do it with better oversight and understanding. If you want to help then maybe's it's more useful to just hashout the plan that'll be given to an AI agent by a maintainer.

By what metric is “the level of quality is much, much higher” in the Django codebase? ‘cause other than the damn thing actually working, the primary metric of a codebase being high quality is how easy it is to contribute to. And evidently, it’s not.

> it’s such an honor to have your name among the list of contributors

I can't help but feel there's something very, very important in this line for the future of dev.

The solution to this problem is for LLMs to get better at producing code and descriptions that doesn't look LLM generated.

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.

Very well said.

I see the problem everyday and am just playing devil's advocate but it doesn't really do a good job explaining the "why".

They hint at Django being a different level of quality compared to other software, wanting to cultivate community, and go slowly.

It doesn't explain why LLM usage reduces quality or they can't have a strong community with LLM contributions.

The problem is that good developers using LLM is not a problem. They review the code, they implement best practices, they understand the problems and solutions. The problem is bad developers contributing - just as it always has been. The problem is that LLMs enable bad developers to contribute more - thus an influx of crap contributions.

A decade or more of people copy-pasting rote solutions from StackOverflow only supports the notion that many people will forego comprehension to foster the illusion of competent productivity.

This ain't an AI problem, it's a people problem that's getting amplified by AI.

Hey, thank you for the compliment!

> Will humans take this to heart and actually do the right thing? Sadly, probably not.

I would like to think that individuals who are interested in joining an OSS community will.

> Will humans take this to heart and actually do the right thing? Sadly, probably not.

Don’t blame the people, blame the system.

Identifying the problem is just the first step. Building consensus and finding pragmatic solutions is hard. In my opinion, a lot of technical people struggle with the second sentence. So much of the ethos in our community is “I see a problem, and I can fix it on my own by building [X].” I think people are starting to realize this doesn’t scale. (Applying the scaling metaphor to people problems might itself be a blindspot.)

> One of the main issues is that pointing to your GitHub contributions and activity is now part of the hiring process.

If I were hiring at this moment, I'd look at the ratio of accepted to rejected PRs from any potential candidate. As an open source maintainer, I look at the GitHub account that's opening a PR. If they've made a long string of identical PRs across a wide swath of unrelated repos, and most of those are being rejected, that's a strong indicator of slop.

Hopefully there will be a swing back towards quality contributions being the real signal, not just volume of contributions.

Obviously the solution is better AI PR reviewers with more context for FOSS projects /s

And I’m 100% sure there are dozens of startups working on that exact problem right this second.

Already back in ye olde times, "let me google that for you" which I see so often posted on Reddit. Sometimes you just wanna exchange with a human, and absorb some of their wisdom, which is the whole point of asking a question. Not so different than wanting to shop at a butcher you can establish a relationship with, rather than a faceless supermarket meat counter.

This is a similar hot issue in academia right now. The ability to generate content in papers via llm is much easier than the ability to thoughtfully review them. There are now two tracks, at least in ICML that I saw, one for AI submitted papers and one for non AI submitted papers. And it works the same respectively for reviewers. However even for AI submitted papers, you cannot have only AI review it. Of course it needs human analysis, but still its tricky what you are going to get. And they are reviewing whether anonymity can still stand or if tying your credibilty to the review process is now necessary.

As for open source PRs, I wonder if for trust's sake you would need to self identify the use of AI in your response (All AI, some AI, no AI). And there would need to be some sort of AI detection algorithm flag your response as % AI. I wonder if this would force people to at least translate the LLM responses to their own words. It would for sure stop the issue of someone's WhatsApp 24/7 claw bot cranking out PR slop. Maybe this can lessen the reviewers burden. That being said, more thought is needed to distinguish helpful LLM use that enhances the objective vs unhelpful slop that places burden on the reviewer.

For instance I copy pasted the above to gemini and it produced an excellent condensing of my thoughts, "It is now 10x easier to generate a "plausible" paper or Pull Request (PR) than it is to verify its correctness."

It’s probably already too late to put these horses back in the barn, but having an “allow AI commits / PRs” would have probably been a good idea for GitHub to make available to projects. Even better might have been something like a robots.txt for repos with rules that could be auto-evaluated and PRs auto-rejected if they weren’t followed.

Then again, we see how well robots.txt was honored in practice over the years. As with everything in late-stage capitalism, the humans who showed up with good intentions to legitimately help typically did the right things, and those who came to extract every last gram of value out of something for their own gain ignored the rules with few consequences.

There may not be many, but these people do exist.

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.

On a widely used open source project I maintain I've been seeing PRs in the last month that are a little off (look okayish but are trivial or trying to solve problems in weird ways), and then when I look at their account they started opening PRs within the last few weeks, and have opened hundreds of PRs spread over hundreds of repositories.

Agreed. Imo, it is important to distinguish which parts of “everything” carry the weight of the concern. By doing that - we may be able to remove “LLM” from that equation entirely.

The direct problem isn’t that people are using LLMs for everything - it’s that some people can’t be bothered to provide reasonable diligence. Phrasing that concern by blaming LLMs implies that these were perfectly diligent human workers before LLMs came along. Do we really believe that to be the case?

They do exist; if "professional" means "hired" it has no bearing on quality, it is not in any shape equivalent to "judicious" nor "careful". If salary goes into "push features" that's gonna be the only incentive.

If you follow any of the programming subs on Reddit, especially the AI-oriented ones, there are a lot of people that at least claim to not code at all anymore-- 100% of their contributions are from prompts.

I know a few of them. Anything than can be done by an LLM, will done by an LLM. They practically worship Claude

While I see the point you're trying to make, truth is 90% of the times at least it will be a workaround instead of a proper solution. Even if it's a proper solution, there's a high chance it will only work on your specific setup - most open source software are made for a range array of systems, configurations, etc.

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.

It depends on the complexity and if your LLM-driven changes fight the architecture of the project.

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?

I don't think anybody would complain about working code. Your PR would explain your reasoning and choice of solution, and that on its own could make or break through acceptance criteria. At least it would by mine.

Errors are fine too. Just not negligence.

the thresholds of quality for "this works on my machine, for my purposes" and "this is viable to merge upstream" are _extremely_ different. claude code has no effect on this, except to confuse certain would-be contributors.

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?

I think that's perfectly fine to upstream, provided there's understanding and you're communicating as yourself. Having Claude generate all the communication for you without your input makes it really, really hard to tell who you are. For some smaller packages, the review may be small and "LGTM". For others, like Django, there's going to be a few rounds of back and forth, and for that a reviewer shouldn't have to communicate with a bot without their consent. Does that make things a bit clearer?

I don't think most maintainers are opposed to LLM-generated bug fixes or solutions _in general_, just the ones that are pure slop: Generated end-to-end by a Claude-maxed computer enthusiast who thinks that enough green boxes on their GitHub profile means they can somehow BS their way into a high-paying FAANG software engineer position. (Spoiler: it won't work.)

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.

There is a clear correlation between the rise in LLM use and the volume of PRs and bug reports. Unfortunately, this has predominately increased the volume of submissions and not the overall quality. My view of the security issues reported, many are clearly LLM generated and at face value don't seem completely invalid, so they must be investigated. There was a recent Django blog post about this [1].

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...

Its weird that still so many consider bug triage a problem to be circumnavigated, somehow in the way of "actual" contributions. Those are actual contributions! Even if they never make it into structured documentation or even python code. And especially so since that work can less usefully be augmented with newly available tool use.

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.

I agree somewhat, as I deal with an internal legacy codebase that's pretty hard to follow, and I use Gemini, Claude, etc to help learn, debug solutions and even propose solutions. But there's a big difference in using it as a learning tool and just having the LLM "do it". I see little value in first time contributors just leaning on an LLM to just do it.

I picked up a change that had broad consensus and quite a bit of excitement over even by some core devs.

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.

Thank you for maintaining those packages! I've used django-import-export a few times.

For anybody else in this position, would heavily plug the djangonauts program

Thank you. django-dramatiq has been fantastic.