Joey Hess published a post arguing that LLM-generated code should not enter software dependencies. The piece gained traction on Hacker News with 21 points and three comments.
The core claim is straightforward: code written by large language models introduces unverifiable authorship and hidden risks into the supply chain that other developers must trust.
What It Is
Hess advocates a simple rule. Any dependency pulled into a project must contain only code written and reviewed by humans. LLM output is treated as off-limits even when it appears functionally correct.
The position stems from the inability to audit training data origins or confirm that generated snippets do not embed subtle bugs or license conflicts.
How to Try It
Teams can adopt the rule with three concrete steps. First, add a CONTRIBUTING.md clause that explicitly bans LLM-written patches. Second, require signed commits or clear human authorship metadata on every file. Third, run periodic audits of transitive dependencies using tools such as cargo tree or pipdeptree to flag packages whose provenance is unclear.
These checks integrate into existing CI pipelines without new infrastructure.
Pros and Cons
- Human-only code preserves clear authorship trails for license compliance and security reviews.
- It reduces the chance of hallucinated API usage that only surfaces after an update.
- Drawback: slower iteration when simple boilerplate tasks could be accelerated by models.
- Smaller projects may struggle to attract contributors who already rely on LLM assistance.
Early HN comments noted that enforcement remains difficult once code leaves the original repository.
Alternatives and Comparisons
Developers currently choose between three approaches.
| Approach | Authorship Trace | Audit Effort | Speed Impact |
|---|---|---|---|
| Strict human-only rule | Full | Low | Medium |
| LLM code with heavy review | Partial | High | Low |
| Unrestricted LLM use | None | Very high | High |
The strict rule trades short-term velocity for long-term maintainability. Heavy-review workflows add reviewer time without eliminating provenance questions.
Who Should Use This
Maintainers of widely used libraries and security-sensitive projects benefit most. Teams shipping to regulated industries or handling cryptographic code should adopt the rule immediately. Solo developers building short-lived prototypes can safely ignore it.
Bottom Line / Verdict
Hess's position forces a deliberate tradeoff between generation speed and supply-chain integrity that every dependency graph must eventually confront.
The discussion on Hacker News suggests the community remains divided on enforcement practicality but agrees provenance matters.
Top comments (0)