The Struggle to Keep Git-Annex Free of LLM Code

Joey Hess spent 100 hours auditing git-annex dependencies to ensure they contain no LLM-generated code. The audit revealed numerous quality issues, including incoherent commits and potential copyright infringements caused by AI tools. Despite feeling isolated in this effort, the author remains committed to maintaining a human-written codebase for their users.

Key Points

• Auditing dependencies for LLM-generated code is a labor-intensive process that reveals significant quality and legal risks.
• LLM-generated commits often result in incoherent codebases and lack proper documentation or explanation.
• Major software freedom organizations are currently failing to provide effective guidelines or resistance against the influx of AI code.
• The author is reconsidering their community participation due to the widespread acceptance of low-effort LLM contributions.
• Using LLMs for quick fixes can alienate experienced collaborators and damage the long-term health of a project.

Sentiment

The overall sentiment is mixed and contentious, with a slight lean toward respecting the maintainer's concern even among people who do not fully endorse a strict anti-LLM boundary. Supportive commenters treat the article as a serious warning about maintainership, provenance, copyright, and the social function of open source. Opposing commenters push back on blanket bans, weak detection, and the assumption that all LLM-assisted work is slop. The result is not consensus, but a serious argument over where responsible tool use ends and maintainer burden begins.

In Agreement

• Volunteer maintainers should be free to reject generated code because reviewing opaque machine-produced changes can consume scarce maintainer time.
• Human contributors can be mentored into better community members, while giving feedback to an LLM-generated patch does not create a future maintainer.
• LLM-generated code creates a free-software concern because the practical preferred form for modification may be prompts, private context, and proprietary models rather than inspectable source.
• Copyright and provenance concerns are real enough that careful projects should avoid accepting generated code until the legal and ethical status is clearer.
• A ban on generated code can be compatible with using LLMs for lower-risk assistance such as research, searching, or triage.
• Simple heuristics such as disclosed co-authorship, unusual churn, and low-quality boilerplate can help maintainers identify obvious cases without claiming perfect AI detection.
• The dependency problem is a reason to reduce dependency surfaces, freeze or fork trusted dependencies, or limit outside contributions rather than absorb unknown generated code.

Opposed

• Avoiding every dependency that has touched LLM-generated code may become impractical if major tools and language ecosystems adopt it.
• LLMs should be treated as tools, with responsibility assigned to the developer who submits and reviews the work rather than the tool itself.
• The article and its supporters may be generalizing from worst-case slop and unfairly treating responsible LLM-assisted development as equivalent to careless generation.
• Reliable AI-code detection is difficult, and weak detectors or superficial signals can turn into pseudoscience or false accusations.
• LLMs can be useful for pair programming, code review, security analysis, and productivity, so a blanket refusal may sacrifice real engineering leverage.
• Some commenters saw the anti-LLM stance as purity or pedantry that could isolate a project from useful ecosystem improvements.
• Open source is likely to adapt through stronger review processes, better tooling, type systems, verification, or different contribution models rather than rejecting LLMs entirely.