No LLM Code in Dependencies

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.