Before installing a dependency suggested by an AI coding assistant, establish which project the name refers to and why the application needs it. Treat the generated name as a candidate, not as installation authority. The useful review connects the intended capability, the project’s official documentation, the registry entry and the specific release your team plans to use.
This matters for a quick business automation as well as a large software product. A script that produces a useful report can still introduce an unnecessary or incorrectly identified dependency. Running the script successfully does not settle who supplied that dependency or whether the project should keep it.
Our recommendation is to put a small identity record at the point where AI-generated code first changes the dependency list. It should complement the team’s existing software review process, with enough evidence for the next reviewer to understand the choice.
A real registry entry does not settle the question
Spracklen and colleagues’ USENIX Security 2025 paper studies package hallucinations in generated Python and JavaScript code. It describes how a model can recommend a nonexistent package and how an attacker could subsequently publish code under that suggested name. The paper also explains why checking registry existence alone cannot establish credibility once such a name has been registered.
These findings concern the paper’s historical models and experimental prompts. They are not current error rates for a 2026 coding assistant, and they do not measure how often businesses are compromised. The mechanism nevertheless gives reviewers a concrete question: does this registry entry belong to the project we intended to use?
Do not resolve that question by asking the same assistant to repeat its recommendation. Obtain evidence from the relevant project and registry. A confident explanation is useful as a lead to investigate, but it is not an independent identity check.
Also avoid the opposite shortcut: an unfamiliar name is not automatically malicious. The correct next step is to establish what it represents. Some references identify code already present in the repository, a standard-library component or an import provided by a differently named distribution.
Separate the import name from the installable distribution
The Python Packaging User Guide distinguishes an import package from a distribution package. A distribution is what an installer obtains; an import name is what Python code uses. Their names often match, but the guide explains that this relationship is a convention rather than an enforced rule.
Its example is Pillow: the distribution is named Pillow, while the import is PIL. The practical consequence is that turning every unfamiliar import into an installation command can select the wrong project.
For AI-assisted work, make the mapping explicit. Identify the import in the generated code, determine what provides it and locate the documented distribution name. If the import refers to a local module or existing project dependency, installing something new may be unnecessary.
This example is specific to Python. Other ecosystems have their own naming, namespace and resolution rules. Apply the equivalent check using their official documentation rather than assuming Python’s rules are universal.
Ask whether a new dependency is needed at all
Before reviewing a candidate package, inspect the project’s existing tools and constraints. The assistant may have introduced a library to solve a problem the application already handles, or selected an unfamiliar wrapper for a small operation.
Our proposed first question is therefore about the capability: what must this code do, and which existing component could do it? That question should come before debating whether a plausible package name looks reputable.
For a small business, the alternative might be a feature already available in its approved automation tool. For a development team, it might be a library already declared in the project. An enterprise may have an internal package or managed service intended for that purpose.
Do not turn this into a blanket rule against new dependencies. Maintaining a homegrown replacement can introduce its own work and defects. Record the reason for the choice so a reviewer can assess the actual tradeoff: useful capability, added maintenance and fit with the application.
Keep an identity record with the dependency change
The following is our proposed review record. It is a workflow aid, not a registry standard or a claim that a particular coding assistant produces these fields reliably.
| Question | Evidence to retain |
|---|---|
| What capability is required? | The requirement and why existing project components are insufficient |
| Which name appears in the code? | The import or reference and what is expected to provide it |
| Which project is intended? | Its authoritative documentation and source location |
| What will the installer resolve? | Registry, distribution name and selected release |
| What links the release to its origin? | Available provenance information and the identity it establishes |
| What remains to be checked? | Compatibility, license, known vulnerabilities and unresolved trust questions |
Start from the project’s established documentation or an already trusted reference, then follow its documented installation path. Compare the registry entry and repository relationship rather than treating a package’s own description as sufficient corroboration.
Keep an unresolved result explicit. If the documentation and registry disagree, investigate the discrepancy. Do not silently substitute a similar-looking package to make installation succeed.
Attach this record to the normal change review. A small team might use a few lines in a pull request. A larger team can capture the same facts through its dependency-management tooling. The essential outcome is an inspectable relationship between the requirement and the exact software being introduced.
Provenance establishes origin, not overall suitability
In a November 2024 practitioner post, PyPI administrator Dustin Ingram described digital attestations that connect release files to publishing identities and upstream source information. It is an implementation account from the registry operator, not an independent safety assessment of every attested project.
PyPI’s current attestation security model makes the boundary explicit: an attestation can establish where a package came from without establishing that the package or its publisher should be trusted. A valid signature does not rule out malicious or vulnerable code introduced before or during a build.
Use provenance to answer its specific question. Does the evidence identify the origin you expected for the release file? Then continue the separate review of whether that project and release are suitable for the application.
Do not describe a missing attestation as proof of malware, either. Record which origin evidence is available and apply the organization’s policy for cases where it is insufficient. The absence of one signal and evidence of malicious behavior are different findings.
A hypothetical reporting-script review
Imagine a team asking an assistant to add image resizing to an internal reporting script. The generated code uses PIL, and the installation instructions simply reuse that import name. This is a fictional review scenario, not output observed from a particular model.
The reviewer first checks whether image handling is already part of the application. If it is, the change should use or explain why it cannot use that existing component. If a new distribution is warranted, the reviewer establishes the import-to-distribution mapping from authoritative documentation rather than executing the guessed instruction.
The review record then identifies the intended project, registry and release. Any provenance evidence is checked against that expected origin. Compatibility and the project’s normal dependency requirements remain separate decisions.
Finally, the team checks the behavior it actually needs: the intended input formats, output dimensions and failure handling for unusable inputs. Establishing package identity does not prove that the generated implementation handles those cases correctly. Our guide to reproducible bugs and acceptance tests explains how to keep that behavioral check concrete.
Give coding agents an explicit dependency boundary
For an agent with installation tools, describe when it may reuse existing dependencies and how it should handle a proposed addition. Require it to surface the proposed distribution, source and reason before crossing any approval boundary already established for the project. Preserve standing permissions where they exist; resolve only genuine gaps in authorization.
Useful controlled checks include an import supplied by an existing dependency, an import whose distribution has a different name, an unavailable candidate and a registry entry whose origin does not match the intended project. The expected behavior should include investigating or stopping when identity cannot be established, rather than guessing a replacement. These are proposed checks, not tests performed for this article.
Once a dependency is accepted, record it through the project’s normal manifest and version-management process. Review later changes on their own evidence. An identity decision for one release is not permanent approval of every future release or publishing change.
Choose one recent AI-assisted dependency change and trace the chain from requirement to installed distribution. If the team cannot explain that chain, improve the intake record before accelerating installation. The goal is a dependency choice another developer can verify, maintain and revisit.