Why is it so hard to find where a function is defined or used when the code is spread across many repos?

When your codebase lives in a single repository, “go to definition” and “find all references” mostly just work. Once that code is spread across dozens or thousands of repos, those same tasks quietly become multi-hour hunts. The function you’re looking for could be in another service, in a shared library, in a fork, or in a long-forgotten monolith that nobody wants to touch—but your editor only sees the current project.

As someone who’s rolled out universal code search in a hybrid GitHub + Perforce environment, I’ve seen the same pattern play out in every large org. The pain isn’t that “engineers forgot how to search.” It’s that our tools were never built for AI-fueled, multi-repo sprawl.

In this article, I’ll break down why it’s so hard to find where a function is defined or used across many repos, and what a code understanding platform like Sourcegraph does differently to fix it—for both humans and AI coding agents.

---

Why multi-repo function discovery is so painful

There are a handful of root causes that surface as the same symptoms:

• “Go to definition” only works in one repo at a time.
• Search is either too broad (tons of noise) or too narrow (misses the real usage).
• Shared libraries and generated code hide the true call graph.
• AI agents give confident but wrong answers because they can’t see the whole picture.

Let’s untangle what’s actually going on.

1. Your tools have a single-repo worldview

Most editors and IDEs are built around a local project:

• Language servers index one workspace. LSPs track symbols, types, and references—inside the project the server is attached to.
• Monorepo assumptions break down. Once services split into dozens of repos, there is no single “workspace” that includes everything.
• Cross-repo calls look like external dependencies. From your IDE’s perspective, a call into another service might as well be a third-party lib.

So when you right-click “go to definition”:

• If the function lives in your current repo, you’re fine.
• If it lives in a sibling repo, you’re stuck copying names into search boxes, trying to guess where it might live.

You’re not actually missing a feature. You’re missing a universal index that spans all of your code hosts and repos.

2. Code is spread across many systems—not just many repos

In most enterprises, “the codebase” is actually a patchwork:

• GitHub and GitLab for most services
• Perforce for legacy C++ or game engine code
• Bitbucket or self-hosted Gerrit for old-but-critical systems
• Forks and internal mirrors of third-party projects

Function definitions and usages can live in any of these. The challenges:

• No single search surface. You might have separate search UIs per host, each with different query languages and auth models.
• Different VCS concepts. Perforce depots don’t look like Git repos. Your IDE can’t treat them uniformly.
• Legacy systems matter. That one function in Perforce might be the actual canonical definition your modern services call into.

Without a unified, cross-host index, you get partial answers at best. You might find some references, but not the ones in the repo you forgot to search.

3. Naming patterns, overloads, and polymorphism explode your search space

Even if you could search every repo, naïve search falls over quickly:

• Common names. validate, process, handle, execute, run, save—these appear everywhere.
• Overloads and methods. A name like save might be a free function, a method on multiple types, or a generic helper.
• Polyglot stacks. The same function name might exist in Java, Go, Python, and TypeScript versions of your services.
• Generated code. Tooling might emit thousands of references that swamp your results.

This is why pure text search isn’t enough. You need:

• Symbol awareness (functions, methods, classes, types).
• Language-specific understanding (e.g., imports, packages, modules).
• Filters by language, path, repo, and revision.

Otherwise, “find where this function is defined or used” turns into “wade through 3,000 search hits and hope you eyeball the right one.”

4. The real definition might be hidden behind layers of indirection

Modern architectures hide the actual function behind abstractions:

• Interfaces and traits. You call an interface method; the concrete implementation lives in another package or repo.
• Service boundaries. Your code calls a client stub that calls an HTTP or gRPC endpoint, which maps to a handler in another service.
• Generated clients. Clients are generated from OpenAPI/Protobuf/IDL, not hand-written.
• Plugin systems. Registrations or annotations wire implementations to interfaces at runtime, often in a different repo.

From a simple “search for this symbol name” perspective:

• The name might only appear in the interface.
• The real behavior might be spread across multiple implementations in different repos.
• The generated code might own the only direct call to that implementation.

Without cross-repo, symbol-level understanding, it’s easy to think “there are only two usages” when there are actually dozens.

5. History and branches matter more than you think

Finding where a function is defined or used isn’t always about the current head commit:

• You may need to know when a function was introduced or removed.
• You may care about which branch introduced a breaking change.
• You may need to correlate a usage spike with a particular commit or migration.

In monorepos, your VCS history at least lives in one place. In multi-repo setups:

• The relevant commits may be spread across multiple repos, branches, and forks.
• Different teams may follow different branching strategies.
• You might not even know which repo introduced the change.

Traditional tools don’t let you say, “Show me every commit in any repo where this function was defined, changed, or removed.” You end up grepping logs per repo, which doesn’t scale beyond a handful of projects.

6. AI coding agents are blind without full-codebase context

AI agents are increasingly part of the workflow, but they inherit all the same blind spots:

• Many agents only see the current repo or current directory.
• They can’t search across GitHub, GitLab, Perforce, and others from one place.
• They hallucinate answers when they can’t find the true definition or usage.

The result:

• Confident-but-wrong call graphs.
• Generated changes that miss critical references in other services.
• Security and compliance risk when agents modify only the visible slice of the codebase.

Agents are only as good as their ability to search, navigate, and understand the entire codebase safely. Without that, “where is this function defined or used?” is often answered incorrectly.

---

What actually fixes this: a universal code understanding layer

To answer questions like “where is this function defined or used?” reliably in a multi-repo, multi-host world, you need a different foundation. This is where a code understanding platform like Sourcegraph comes in.

Instead of indexing one repo at a time in your IDE, Sourcegraph:

• Connects to GitHub, GitLab, Bitbucket, Gerrit, Perforce and more.
• Indexes 100 or 1M+ repositories and billions of lines of code.
• Exposes that index to both humans and AI agents via Code Search, Deep Search, Code Navigation, and Sourcegraph MCP.

Here’s how that changes the game.

Universal Code Search across every repo

Sourcegraph Code Search gives you:

• Super-fast literal, keyword, and regex search across all repos.
• Filters by file path, language, repo, branch, and revision.
• Search contexts to constrain queries to specific repo sets or versions.

For function discovery, that means you can:

• Search for func myHandler( or def my_handler across all services, not just one.
• Limit to lang:go or lang:python to avoid noise from other stacks.
• Restrict to repo:frontend/* or repo:monolith to narrow your blast radius.
• Use multi-branch search to index multiple branches where migrations are in flight.

Instead of manually hopping across repos and hosts, you get a single, fast query surface.

Symbol-aware Code Navigation that crosses repo boundaries

Text search is helpful, but for “where is this function defined or used?” you really want symbol intelligence:

• Precise code indexing (SCIP-based) understands functions, methods, classes, and variables.
• Cross-repository navigation resolves symbol definitions across multiple repos.
• Syntactic + search-based fallbacks keep navigation working even when precise indexes aren’t available.
• Commit + Diff Search lets you search function changes across history.

Practically, this means:

• Click on a function name in one repo and jump to the true definition in another repo.
• Run “find all references” and see every call site across repos.
• Filter references by repo, path, or language to focus on what matters.
• Trace the evolution of a function via commits and diffs, even when refactors crossed repo boundaries.

This is the capability most developers assume their tools already have—until they see how much they were missing.

Deep Search (Agentic AI Search) to answer harder questions

Sometimes you don’t just want locations—you want an explanation:

• “Which services call this function, directly or indirectly?”
• “Where is this function misused?”
• “Which implementations of this interface exist across the org?”

Sourcegraph Deep Search is Agentic AI Search. It:

• Uses LLMs plus the full code index to answer these questions.
• Actively searches, filters, and reads relevant files—across all repos.
• Returns clear, cited answers that point back to the exact code it used.

So instead of manually stitching together a call graph from raw references, you can:

• Ask Deep Search to map out the call chain across services.
• Get a summarized answer plus links to the underlying definitions and usages.
• Use those citations to verify the AI’s reasoning before making changes.

Because Sourcegraph operates with Zero data retention for LLM inference, you get this AI layer without your code or prompts being retained beyond what’s required to serve the request.

Making this work for AI agents via Sourcegraph MCP

If your org is leaning into AI agents, they need the same code understanding layer your developers use.

Sourcegraph’s MCP (Model Context Protocol) exposes:

• Universal Code Search across all connected code hosts.
• Code Navigation (definitions, references) across repos.
• Deep Search for higher-level analysis.

That lets agents:

• Reliably find the real definition of a function, even in legacy or Perforce code.
• Check every usage across repos before proposing edits.
• Explain how a function is used in different services with grounded references.

Crucially, Sourcegraph respects your existing access controls:

• SSO via SAML, OpenID Connect, and OAuth.
• SCIM user management for provisioning and deprovisioning.
• RBAC for fine-grained access to repos and features.
• SOC2 Type II + ISO27001 Compliance for enterprise governance.

So agents only see—and change—what a human with the same permissions could.

---

Turning understanding into controlled change

Finding where a function is defined or used is often just step one. Step two is changing it safely.

Because Sourcegraph is a platform, it doesn’t stop at “here are the locations”:

• Batch Changes lets you make multi-repo edits across all the call sites you found—creating code-host-native changesets (PRs, CLs) in each repo.
• Monitors can watch for new usages of a deprecated function and notify or trigger agents to fix them.
• Insights gives you dashboards that show usage of a function over time across repos, so you can track deprecation progress or adoption of a new API.

That’s how you move from “I know where this function is used” to “we’ve safely migrated all usages and we can prove it.”

---

Bringing it back to the original question

So why is it so hard to find where a function is defined or used when your code is spread across many repos?

Because most tools:

• Only see one repo at a time.
• Can’t unify GitHub, GitLab, Bitbucket, Gerrit, and Perforce under a single search and navigation layer.
• Rely on plain text search instead of symbol-aware, cross-repo indexing.
• Don’t expose their understanding to AI agents, or can’t enforce enterprise-grade access controls.

A code understanding platform like Sourcegraph is built for this reality:

• Lightning-fast search at enterprise scale, whether you have 100 or 1M repositories.
• Truly universal coverage across the code hosts you already use.
• Agentic AI Search and MCP to give both humans and AI agents grounded, explainable answers.
• Platform workflows—Batch Changes, Monitors, Insights—to turn that understanding into controlled, auditable change.

If you’re tired of guessing which repo holds the real definition, or diffing five different implementations to understand how a function is actually used, it’s time to treat code understanding as a first-class platform, not an IDE convenience.

Next Step

Get Started