No LLM Code in Dependencies
A maintainer of the git-annex project has decided to avoid depending on code generated by large language models, even dropping or freezing major tools like newer versions of Git and GHC to do so. Commenters debate whether this stance is principled protection against “AI slop,” licensing uncertainty, and unsustainable reviewer burden, or an impractical purity test that will leave projects outdated and overworked. More broadly, the exchange highlights growing fault lines in open source over how (or whether) to accept AI-assisted contributions, the impact on volunteer maintainers, and the contrasting risk tolerances of corporations versus FOSS communities.
Detection of LLM-Generated Code
- Some want tools to flag LLM-generated commits using heuristics: large blobs with extensive comments, unusual lines-of-code per hour, and commit styles trained on pre-LLM-era repos.
- Others argue “AI detection” is inherently unreliable, likening it to polygraphs, and warn about high false positives.
- A softer position: detection doesn’t need to be perfect—just good enough to surface “obvious” cases for human review.
- Simple heuristics like checking commit co-author tags are proposed as low-hanging fruit.
Practicality of No-LLM Dependencies
- One side sees refusing LLM-tainted dependencies as a principled but potentially impractical stance, especially when it blocks newer versions of critical tools and languages.
- Others consider it a reasonable defense against “AI slop,” even if it means more work, dependency freezing, or using fewer dependencies.
- There’s recognition that this may become untenable long-term and could force trade-offs between purity and access to language/tool improvements.
OSS Governance and Contribution Policies
- Suggestions include: not accepting external contributions at all, paywalling PRs to fund additional review, or moving to “AI-free” hosting.
- Some argue that open source can simply refuse LLM-generated patches while staying open; forking remains an option for disagreeing users.
- A recurring concern is maintainer burnout from low-quality AI PRs and the risk of volunteer projects “imploding” under review burdens.
- Several comments emphasize the qualitative difference between mentoring junior humans (who can grow into maintainers) and reviewing LLM output, which offers no long-term community benefit.
Quality of LLM Code vs Human Code
- One camp claims LLMs resemble mid-to-low-tier developers and can be useful if wielded responsibly; the problem is sloppy users, not the tool.
- Critics say LLMs are worse than typical devs, lack understanding, and produce subtle, large-scale messes at superhuman speed.
- There’s fear of a future saturated with opaque, churn-heavy “slopcode,” where comprehension and reliability degrade.
Security, Ethics, and Corporate vs OSS Attitudes
- Some advocate LLMs as essential for future-scale security auditing; others respond that analysis and code generation are distinct issues.
- Tension exists between being “forced” to use LLMs by the job market and the belief that this situation is nevertheless bad.
- Several comments highlight unresolved copyright/licensing questions around training data and code reuse.
- Contrast is drawn between idealistic, publicly scrutinized open source projects and corporations quietly using LLMs internally with less concern about provenance.