Why Some Maintainers Are Rejecting LLM-Generated Code in the Dependency Graph

The argument is not about attribution or licensing. It is about verifiability.

When a library maintainer ships LLM-generated code, downstream consumers inherit it without visibility. A senior engineer auditing a dependency cannot tell which functions were written by a human who understood the invariants and which were produced by a model that pattern-matched its way to something that compiles. That distinction matters for security-sensitive or correctness-critical paths.

The concern compounds at the dependency graph level. A project might vet its direct dependencies carefully. It has far less leverage over transitive ones. If LLM-generated code becomes normalized in library internals, the aggregate surface area of unverified logic grows faster than any team can audit.

The practical ask from maintainers holding this position: treat LLM output the same way you treat vendored third-party code. Label it. Review it as if it came from an unknown contributor, because in a meaningful sense it did. Do not let it slip through under the cover of a routine commit.

This is not a call to ban the tooling. Engineers using LLMs to draft, prototype, or accelerate their own application code operate in a different trust context. They own the review loop. Maintainers shipping to thousands of downstream consumers do not have that luxury — the review loop is theirs, but the blast radius belongs to everyone.

For technical founders building on open-source stacks, this surfaces a due-diligence question that did not exist two years ago: does your dependency audit process have any signal for LLM provenance? Most do not. Software composition analysis tools track known vulnerabilities and license conflicts. None currently flag code by generation method.

The gap between what tooling can detect and what maintainers are starting to care about is widening. That is the actual infrastructure problem here.

Source