Who Vets AI’s Code? The Scale Challenge Facing Open Source Ingestion

What happened

I'll draft the post from the given facts only, then count words so it stays in the 600–900 range with no invented figures.AI coding tools can introduce unvetted or hallucinated open source dependencies faster than traditional security reviews can keep pace. That is the claim ActiveState is pressing, as reported by BleepingComputer, and it names the bottleneck in the title question: who vets the code that AI places into a project. The issue is not that a model ships an entire product unreviewed. It is that the packages it suggests, imports, or pins can land in a codebase before anyone has confirmed those packages are real, maintained, and acceptable to the organization. ActiveState’s position is that organizations should govern packages at the point of selection, before they enter the development pipeline.

The mechanics sit at the seam between suggestion and install. An AI coding assistant works from training data and from the files already in the repository. When it needs a library, it proposes a name, a constraint, or a lockfile change. That proposal looks like ordinary developer work: a new line in a manifest, a new coordinate, a new pin. Traditional security review usually starts later. Scanners run on a pull request, a continuous integration job, or a production inventory after the dependency is already declared. Hallucinated packages exploit that delay. A model can emit a plausible package name that does not exist on the registry, or that exists only as a lookalike waiting for the first automated install. Unvetted packages are the quieter case. The name is real, the download succeeds, and the only miss is that nobody decided the organization should use that project at all. ActiveState’s argument moves the decision upstream. Selection is the moment a human or a policy engine says yes or no. After that moment, the pipeline should only see packages that have already been allowed.

The technical detail

For engineers and builders this is a change in where trust is placed. The assistant is now a high-volume package recommender. A developer who used to add a dependency after reading the project, the license, and the issue history can still do that work, but the assistant can propose several such additions in a single session. Reviewers who treat AI-authored diffs as ordinary human diffs will miss the scale problem. The risk is not only malware in a new package. It is also license drift, abandoned maintainers, transitive trees that no one on the team can explain, and build-time network calls to registries that were never part of the approved supply. Teams that already pin versions and vendor sources still need a gate before the pin is written. Otherwise the pin simply freezes an unreviewed choice.

Why it matters for builders

The market context is a collision between two mature habits. Open source ingestion has always been a scale problem. Organizations pull far more third-party code than they write. Composition analysis, artifact proxies, and internal registries exist because that fact is old. AI coding tools compress the time between a possible library and a library that is already in the tree. Security vendors and platform companies have spent years selling scan-after-the-fact. ActiveState is arguing that scan-after-the-fact is the wrong default once the proposer is a model that does not wait for a security review. That argument will sit next to existing private-repository products, allow-list policies, and approved-package catalogs. The competitive question is not whether anyone has ever governed open source. It is whether governance is attached to the selection step that AI tools now flood, or whether it remains attached to the later steps that those tools skip past.

Market and competitive context

The practical takeaway is to treat package selection as a control point, not as a side effect of autocomplete. Watch whether the organization can answer, for every new direct dependency, who selected it and whether that selection was allowed before the first install. If AI assistants can write lockfile changes, those changes should fail unless the package is already allowed or has been reviewed in the same change. Proxy the registries the assistants can reach. Reject unknown names instead of letting continuous integration discover that a hallucinated package is missing, or worse, that a lookalike name resolves. Count how many new packages appear and how many of those first appeared in AI-authored diffs. If that count is rising and the review queue is not, the scale problem BleepingComputer relayed is already inside the pipeline.

What to watch next

Risks and open questions remain even if selection is gated. An allow list that is too slow will be bypassed with personal credentials and direct registry calls. An allow list that is too loose is only a rename of the old scanner. Hallucinated names are a moving target: once a fake name is public, someone can publish a real package under it. Governing at selection does not inspect the behavior of a package after install, so later review still matters for packages that were correctly chosen. Related prior art is the same stack security teams already run: internal language-registry mirrors, repository managers, vendored sources, module proxies, and policy checks in continuous integration. ActiveState’s contribution, as framed here, is the insistence that those controls belong at the moment of choice, because AI coding tools have made that moment both more frequent and less visible than a human-typed import.