Give Django your time and money, not your tokens
Maintainers of the Django web framework are pushing back against AI-generated pull requests, arguing that LLMs used as a “facade” for understanding flood the project with low‑quality changes and drain scarce reviewer time. Commenters describe a broader trend across open source: AI tools make it far easier to generate plausible code, bug reports, and documentation than to reliably review them, eroding trust and demoralizing volunteers. While some advocate embracing AI with clearer policies or automated reviews, others are moving toward stricter rules, private collaboration, or simply refusing external PRs, and suggest that people who want to help should donate money or do work they truly understand.
Money vs tokens & alternative support models
- Many agree that donating money or funding specific features is more helpful than “spending tokens” on AI-generated PRs.
- Some note big projects may already get free credits from AI providers, so extra “AI budget” donations may be limited.
- A few argue contributors should be free to offer AI-generated PRs instead of cash; maintainers can simply reject them.
Impact of LLMs on OSS contributions
- Strong consensus that LLMs have greatly increased volume of PRs, bug reports, and “security” reports, with only modest or negative impact on quality.
- Maintainers report many obviously LLM-generated issues that seem plausible enough to demand investigation, draining limited time.
- Several commenters distinguish between using LLMs as learning/assist tools vs. outsourcing understanding and communication entirely.
Maintainer experience, quality, and trust
- Django and similar mature codebases are described as dense, high-quality, and hard to enter; LLMs don’t naturally produce code in that style.
- Reviewers find it demoralizing to interact with PR authors who appear to be “facades,” with AI replying to review comments and faking understanding.
- Broad worry that trust is eroding: previously PRs were assumed to be in good faith by people who understood their changes; that assumption no longer holds.
Policies and proposed mitigations
- Examples cited: projects requiring AI-use disclosure, banning external PRs, disallowing users from opening issues directly, or enforcing strict no-LLM policies.
- Others adopt “allowed with conditions” rules (e.g., DCO signoff, no LLM-based security reports).
- Suggestions include repo-level AI policy files (like robots.txt) or explicit “LLM honeypot” projects to isolate low-effort contributions.
- Some advocate private or more tightly curated contributor communities and mentoring programs.
Culture, incentives, and broader concerns
- Hiring practices that reward GitHub activity are seen as driving people to game contributions with LLMs.
- Debate exists over whether OSS should “embrace” AI (e.g., AI code review) or largely exclude it to preserve quality and sanity.
- Multiple comments stress that the real problem is contributors who lack diligence or understanding; LLMs amplify their impact, rather than creating the issue.