AI coding tools can produce an import statement that looks perfectly plausible but points to a package, module, subpath, or API that does not exist. This is an import hallucination: the model has generated a statistically likely reference rather than verified software metadata. The result may be a failed build, a vulnerable dependency, a broken deployment, or code that quietly uses the wrong library.
For Indian engineering teams, this problem is especially relevant when developers work across Python, JavaScript, Java, Go, and internal packages; use private registries; or generate code for Aadhaar-adjacent workflows, fintech, healthtech, logistics, and public-sector systems where reliability and auditability matter. A good review process should treat every AI-generated import as an untrusted claim until the package and symbol are verified.
What counts as a hallucinated import?
An AI-generated import can be wrong in several distinct ways:
- Non-existent package: The referenced library is not published in the intended registry.
- Invented module path: The package exists, but the suggested submodule does not.
- Wrong symbol: The module exists, but the imported class, function, or constant is absent.
- Version mismatch: The symbol existed in an older release, or is only available in a newer version than the project supports.
- Registry confusion: The model names a similarly titled package from npm, PyPI, Maven Central, or another ecosystem.
- Private-package assumption: The import resembles an internal module that the model cannot access or verify.
- Transitive dependency error: The code imports a package that may be installed indirectly today but is not declared directly in the project.
This is different from a normal coding mistake. A hallucinated import often has convincing naming, documentation-style comments, and realistic usage examples, making visual review unreliable.
Why AI models invent imports
Large language models learn patterns from source code, package documentation, tutorials, issue discussions, and generated examples. They do not automatically query a live package registry when producing code. If two libraries expose similar functionality, the model may combine their names or infer an API that would be reasonable but does not exist.
Risk rises when the prompt asks for a niche integration, an unfamiliar Indian service, a recently released framework, or a package with sparse documentation. It also rises when the developer provides no lockfile, supported runtime, registry, or version constraint. In those cases, the model is filling gaps rather than retrieving facts.
Teams evaluating broader reliability should pair import checks with a structured frontier models evaluation process. Import validity is a narrow but highly actionable measure of coding-model quality.
A practical detection workflow
1. Parse every import before running the code
Extract imports from the generated diff and classify them as standard library, first-party, or third-party. Standard-library imports should be checked against the target language version. First-party imports should be matched to the repository structure. Third-party imports must be checked against the approved registry and project manifest.
Do not rely on a successful local run alone. A developer’s environment may contain undeclared packages, cached artifacts, editable installs, or globally installed modules that will not exist in CI or production.
2. Verify the package in the correct registry
Check the exact package name, publisher, release history, supported versions, licence, and download or maintenance signals. For Python, inspect PyPI and the project’s pyproject.toml or requirements files. For JavaScript, use npm metadata and package.json. For Java and Go, verify Maven Central or the Go module path.
A package being present is not proof that it is safe. Typosquatting and dependency confusion can turn an AI mistake into a supply-chain incident. Use an allowlist for production dependencies, pin versions, and prefer internal mirrors where appropriate.
3. Resolve the symbol, not just the package
A real package can still contain a hallucinated import. Inspect the installed version’s exports, type definitions, generated documentation, or source tree. Run language-native checks such as Python import tests, TypeScript compilation, Java compilation, or Go module and build validation.
For example, a minimal Python check might be:
python -c "from package_name import ExpectedSymbol; print(ExpectedSymbol)"Use an isolated environment and the same interpreter version as CI. For JavaScript and TypeScript, install from a clean lockfile and run the compiler rather than relying only on an editor’s autocomplete.
4. Compare against the lockfile and manifest
Every accepted dependency should be declared directly when application code imports it. Generate or refresh the lockfile only after review; do not let an installer silently add an unexpected package. CI should fail when imports cannot be resolved from a clean checkout using the declared dependency set.
This simple control catches many failures before code review is complete and provides an auditable record of what entered the build.
5. Test the smallest executable example
Ask the model for a minimal usage example, then replace the import with a verified package reference if necessary. Run a smoke test that exercises the claimed API. If the package is obscure, require a link to primary documentation or a source repository and have a human confirm that the example matches the supported version.
Avoid accepting citations or URLs generated by the model without opening them. A fabricated documentation link is another form of hallucination.
Automating checks in CI
A robust pipeline combines static and runtime controls:
- Parse changed files and flag new third-party imports.
- Compare imports with declared dependencies.
- Install from a clean, locked environment.
- Run compilation, type checks, and import smoke tests.
- Scan dependencies for known vulnerabilities and licence conflicts.
- Block packages outside approved registries or organisation scopes.
- Record the model, prompt context, reviewer, and dependency changes for audit.
For repositories using AI agents, require the agent to produce a dependency manifest alongside its code. An AI agent app-building workflow should grant package-install permissions only when needed and should never allow an agent to publish or deploy unreviewed dependencies.
Handling false positives and private modules
Not every unresolved import is hallucinated. Monorepos, generated clients, namespace packages, private registries, and build-time aliases can confuse generic scanners. Make repository metadata available to the checker: workspace definitions, path aliases, registry configuration, and generated-code instructions.
Maintain separate rules for development, testing, and production dependencies. A test-only package should not be bundled into a customer-facing image, while an internal module should be verified through repository ownership or registry metadata rather than a public search.
A review checklist for builders
Before merging AI-generated code, confirm:
- The package exists in the intended registry and has an identified maintainer.
- The exact module path and symbol exist in the pinned version.
- The dependency is declared directly and appears in the lockfile.
- A clean environment can install and import it successfully.
- Licence, security, size, and maintenance risks are acceptable.
- The code does not expose secrets or send sensitive data to an unapproved service.
- A human reviewer understands why the dependency is necessary.
For teams building in India, this checklist should sit alongside data-protection, localisation, and vendor-risk reviews. AI-generated code can introduce operational and compliance dependencies even when the visible feature appears small.
Conclusion
AI detecting hallucinated imports is most effective when treated as a software supply-chain and verification problem, not as a question of whether an AI answer sounds credible. Combine registry checks, symbol resolution, clean builds, dependency policy, and human review. The goal is not to prevent developers from using coding models; it is to ensure that generated code earns its way into the repository through reproducible evidence.
For related implementation patterns, see hallucinated imports detection in AI code and AI for hallucinated imports.