The Problem of "Big Code"
Imagine you work in a library with 5,000 rooms, each containing thousands of books. If someone asks you to find every book that mentions a specific phrase, you have two options: walk into every room and read every page, or consult a master index that tells you exactly which rooms and which shelves to check. The first approach works fine in a single room. It becomes physically impossible across 5,000.
Code search at scale faces exactly this problem. When you work on a single repository, git grep or your IDE's "Find in Files" is perfectly adequate. It scans every line of text and returns matches in milliseconds because the data fits comfortably in memory or on a fast local disk.
But modern companies don't have one repository. They have hundreds or thousands. A mid-sized engineering organization might have 500 repositories. A large enterprise or open-source platform might have 50,000. If you try to git clone all of them to a single machine and run grep on every search request, your disk fills up, your CPU saturates, and each query takes minutes — not milliseconds. Users stop using the tool, and the engineering organization loses the ability to answer critical questions like "Who is calling this deprecated API?" or "Where is this secret being used?"
Semantic Code Search tools — such as Sourcegraph, GitHub Code Search, and the open-source engine Zoekt — solve this by building a persistent, pre-computed index of all code. A developer can then search across millions of files and terabytes of source code in under a second, without cloning anything locally. The index does the heavy lifting once, so every query is fast.
The word "semantic" here is used loosely in the industry. At its most basic, it means the search understands code structure (identifiers, function calls, syntax) rather than treating source code as plain prose. More advanced implementations add true language-aware understanding — knowing that doLogin and do_login are likely related concepts, or that a symbol reference and its definition are connected.
Key Point: Text-based search is O(N) — it gets slower as code grows. Index-based search decouples query time from corpus size, making sub-second search across billions of lines of code possible.