Coding assistant with private repository grounding

Yes. The strongest options I found are enterprise coding products that retrieve/index your private repositories at inference time, rather than relying on the model's pretrained knowledge. That's the key distinction if your problem is hallucinated internal libraries.

The important distinction

There are really three different approaches being marketed as "trained on your code":

1. Repository retrieval/indexing (RAG/context)
   The model stays general-purpose, but the system searches your private code and puts relevant files/symbols into the prompt. This is usually what you want for internal libraries, because the answer can reflect the current version of your code.

2. Fine-tuning on private code
   The model actually gets trained/customized using your organization's code. GitHub, for example, explicitly advertises fine-tuned custom private models for Copilot Enterprise. docs.github.comgithub.com
   This can improve coding style/patterns, but it doesn't inherently solve the "what does our library currently expose?" problem as well as live retrieval.

3. Codebase-aware agents/context engines
   These build a persistent semantic understanding of relationships across repositories. Augment and Sourcegraph are particularly relevant here.

For your specific complaint—"my coding assistant invents libraries/functions that don't exist"—I'd prioritize #1 + #3, not merely fine-tuning.

My shortlist

If you're on GitHub: start with GitHub Copilot Enterprise. Its repository indexing is explicitly designed to ground responses in the actual codebase, and GitHub says the index isn't used for model training.docs.github.com

If you have a huge/messy enterprise codebase: I'd put Augment Code and Sourcegraph into the bake-off. Their differentiation is precisely repository-scale context rather than ordinary autocomplete.www.augmentcode.com+1

If your internal ecosystem is AWS-heavy: Amazon Q Developer is unusually explicit about customization from private repositories and internal APIs/libraries.aws.amazon.com

One caveat: "grounded in private code" does not mean hallucination-free. For a serious evaluation, give each vendor the same 20–50 tasks involving obscure internal APIs and score whether it (a) finds the real symbol, (b) cites/opens the relevant source, (c) refuses when the API doesn't exist, and (d) uses the current version rather than an obsolete implementation.

If you tell me GitHub/GitLab/Bitbucket, approximate repo size, IDE, and whether the code can leave your network, I can narrow this to the 2–3 vendors I'd actually pilot.

Yes — and this is one of the most useful ways to make AI coding assistants more reliable. What you're looking for is usually called codebase-aware AI, repository-grounded coding, or context-aware code assistance.

Instead of relying only on a model's general training, these tools can retrieve information from your actual repository: your internal libraries, dependency versions, API definitions, existing implementations, and coding conventions.

That directly addresses the problem you're describing: an assistant inventing a package, suggesting a method that doesn't exist in your version, or recommending an API your team doesn't use.

The important distinction is that connecting an assistant to your codebase reduces hallucinations, but doesn't eliminate them. The best systems also consult official documentation, inspect dependency manifests, and verify suggestions against real code.

The best options to look at

• 

1. Cursor — best starting point for an individual developer

Indexes your repository so the assistant can find existing implementations and answer questions about your code. It can use those patterns when generating code.www.cursor.com+1

Best for: Developers who want an AI-first editor without building their own retrieval system.

Official site ·Security and privacy

---

• 

2. GitHub Copilot — best if your team already uses GitHub

Repository indexing provides semantic search across code, letting Copilot Chat retrieve relevant sections of your project to answer questions about its architecture and behavior.docs.github.com

Best for: Teams that want codebase-aware assistance integrated into their existing GitHub workflow.

Repository indexing documentation

---

• 

3. Sourcegraph Cody — best for large, multi-repository codebases

Uses code search to retrieve relevant symbols, APIs, and usage patterns across local and remote repositories. Its Enterprise offering is particularly relevant when code permissions and organizational controls matter.sourcegraph.com+3

Best for: Organizations with multiple services, shared internal libraries, and complex dependencies.

Official documentation

These are different approaches to the same problem, not a guarantee that every generated import or API call will be correct.

If you want stronger control over what the AI knows

Two additional options are worth considering:

• 

Continue — customizable and open source

Lets you configure AI agents to explore code, access internal repositories through custom MCP servers, and consult documentation. This is a good choice if you want to build a workflow tailored to your own codebase.docs.continue.dev+1

Documentation

• 

Aider — terminal-based coding with repository awareness

Builds a map of your repository's important functions, classes, and call signatures. It can also run linting and tests after changes, making it a practical option if you prefer to verify generated code rather than trust suggestions blindly.aider.chat+1

Documentation

How to stop the nonexistent-library problem

Whichever assistant you choose, I'd combine repository grounding with these four safeguards:

1. Use your lockfile as the source of truth. Check package-lock.json, pnpm-lock.yaml, poetry.lock, Cargo.lock, or the equivalent for the actual dependency versions installed.
2. Ground suggestions in real examples. Ask the assistant to find an existing usage in your repository before proposing a new import or API call.
3. Connect documentation for the exact version. Your internal code tells the assistant how your team uses a library; version-specific documentation tells it which APIs are actually supported.
4. Require verification. Run the compiler, type checker, tests, and dependency resolution. These catch many fabricated imports and unsupported methods before code gets merged.

For example, add this instruction to your coding assistant's project rules:

:::writing{variant="document" id="58321"}

Dependency and API accuracy rules

• Never invent package names, dependencies, methods, imports, or API signatures.
• Check the project's manifest and lockfile before recommending a dependency.
• Prefer existing implementations and established patterns in this repository.
• Before using an unfamiliar API, verify it against documentation for the installed version or inspect its actual source and type definitions.
• If you cannot verify that a package or API exists, say so explicitly rather than guessing.
• Run relevant type checks, builds, and tests after making changes.
• Identify the source used to verify unfamiliar APIs. :::

One important caveat: private code access and private model processing aren't necessarily the same thing. For example, Cursor offers a Privacy Mode, but AI requests still go through its backend. Review each vendor's data handling, repository permissions, retention policies, and deployment options against your organization's requirements.www.cursor.com+2

Which would I choose?

• Individual developer: Start with Cursor.
• Team already on GitHub: Evaluate GitHub Copilot.
• Large organization with many repositories: Evaluate Sourcegraph Cody.
• Need customization or more control over infrastructure: Explore Continue and Aider.

One question that would help me narrow this down: Are you trying to ground the assistant in a single application's code, or in a whole ecosystem of private libraries and repositories that your application depends on? The second case benefits from a more deliberate code-search and documentation setup.