Arcaide: Understanding Codebase Structure Through Multi-Level Call Graph Visualization

Codebases Keep Growing, and So Does the Cost of Understanding Them

For any engineer, inheriting an unfamiliar codebase is a headache. Functions nest within one another, modules call each other back and forth, and simply figuring out "what actually happens when a request comes in" often requires jumping around the editor repeatedly, tracing through dozens or even hundreds of files. Traditional IDE features like "Go to Definition" and "Find References" are certainly useful, but they provide fragmented, point-to-point views that make it hard for developers to build a holistic understanding of an entire system.

Recently, a tool called Arcaide made its debut in Hacker News' Show HN section. Its core capability revolves around one central idea—exploring and understanding code through multi-level call graphs. The pain point it addresses is one every developer can relate to: reading code is harder than writing it.

What Is a "Multi-Level Call Graph"

The call graph itself is not a new concept. Its history dates back to compiler theory research in the 1960s, where it was originally used for program optimization and dead code elimination. It uses nodes and edges to represent calling relationships between functions: each node represents a function, and each edge represents "A calls B." It's a familiar sight in static analysis tools and performance profilers.

Worth noting is that the call graph plays a role far beyond "documentation aid" in modern compiler systems. In industrial-grade compilers such as LLVM and GCC, the call graph is one of the core intermediate representations (IR) used when performing optimizations like Inlining and Interprocedural Constant Propagation. This means the call graph is backed by decades of rigorous theoretical accumulation and engineering practice—it's far from being a mere visualization gimmick.

Based on how they're constructed, call graphs fall into two major categories: static call graphs are built through lexical/syntactic analysis of source code or bytecode—fast, but with limited accuracy for scenarios involving polymorphic calls, reflection, and so on; dynamic call graphs record actual call paths through runtime instrumentation—more precise, but requiring the program to actually run. Arcaide takes the static analysis path, meaning developers can instantly obtain calling relationships without running the code, which better fits everyday code reading scenarios.

Arcaide's differentiation lies in those two words: "multi-level." Developers can observe code at different levels of abstraction, achieving genuine layered exploration.

Switching Between Macro and Micro Levels

Module-level view: First, get a clear picture of which major modules or packages make up the system, and understand the overall dependency relationships.
File/class-level view: Drill down into a specific module to observe the calls flowing between files or classes.
Function-level view: Finally, pinpoint a specific function to see clearly who calls it and what it calls.

This "zoomable" exploration approach lets developers work like they would with a map application—first viewing the overall picture, then gradually zooming into specific details. Compared to diving straight into function-level details, the top-down approach better aligns with how humans naturally understand complex systems. Cognitive science research shows that when humans process complex information, they rely on a "Progressive Disclosure" strategy—building a high-level mental model first, then filling in the details downward. This is precisely the psychological rationale behind the multi-level view design.

What Real Problems Can Multi-Level Call Graphs Solve

An Accelerator for Onboarding

For engineers who have just joined a team, the biggest challenge isn't writing code—it's "understanding existing code." Visualizing call chains can significantly shorten this ramp-up period—developers no longer need to repeatedly Ctrl+Click to manually trace things, and can quickly build a mental model of the project structure. Studies show that software engineers spend an average of 58% of their working time understanding code rather than writing it; the efficiency gains that visualization tools provide in this dimension are often underestimated.

Assessing the Impact Scope of Changes

When modifying a core function, the biggest worry is "will changing this affect something elsewhere?" A multi-level call graph can clearly display a function's upstream callers (who depends on it) and downstream callees (what it depends on), helping developers assess the potential impact scope of a change and reducing the risk of introducing regression bugs. This capability is equally valuable during the Code Review stage—reviewers can intuitively see the calling context of a modified function, rather than relying on the committer's textual description to judge the scope of changes.

Visual Identification of Technical Debt

Call graphs often expose architectural-level hidden dangers—a module that should be independent being overly coupled, unexpected circular dependencies, or a "god function" referenced by dozens of places in the code. These structural problems, hard to detect in plain-text code, become immediately obvious once presented graphically. In the field of software architecture, "circular dependencies" are a classic precursor to a system degenerating into a "Big Ball of Mud" architecture. Call graphs allow teams to spot and intervene in this kind of structural rot early, before the problem becomes too entrenched to fix.

Arcaide's Positioning Among Similar Tools

The field of code visualization and comprehension is not a blank slate; its development has already gone through several generations of evolution. The first generation was represented by Doxygen (1997), which focused on generating documentation from comments, accompanied by simple dependency diagrams. The second generation was represented by JetBrains IDEs and Sourcegraph, which deeply integrated code navigation capabilities into the development workflow.

Understanding the technical background of this generation of tools is especially important. LSP (Language Server Protocol) was introduced by Microsoft in 2016 alongside VS Code. It decoupled language analysis capabilities from the editor, enabling any editor to obtain completion, navigation, and reference-finding capabilities through a standard protocol, pioneering a new paradigm for IDE intelligence. SCIP (Semantic Code Intelligence Protocol) is Sourcegraph's further extension built on top of LSP: LSP was originally designed for real-time interaction within a single codebase, whereas SCIP is purpose-built for extremely large-scale scenarios (hundreds of repositories, billions of lines of code), supporting offline batch indexing and precise symbol-level cross-repository reference graphs. It's an important complement to LSP in enterprise-scale scenarios. CodeSee, meanwhile, presents dependency relationships in microservice architectures in the form of a "service map," oriented more toward the system architect's perspective.

The path Arcaide has chosen leans toward structured visual exploration rather than relying purely on natural language Q&A. Behind this lies a judgment worth pondering: graphical structural information is often more precise and more verifiable than AI-generated textual descriptions. For scenarios that require rigorous understanding of calling relationships (refactoring, security audits, etc.), a deterministic call graph is more trustworthy than probabilistic LLM output.

Of course, the two are not mutually exclusive. One foreseeable evolutionary direction is using call graphs to provide structured context for large models, giving AI a "map to rely on" when understanding code. This idea already has early practices in the industry: when a developer asks "what impact will modifying this function have," the system first retrieves all relevant upstream and downstream functions through the call graph, then injects the corresponding source code snippets into the large model's context window, thereby preventing the LLM from "blindly guessing" based on a single file alone.

Microsoft Research's GraphRAG project provides an important theoretical framework in this direction. Unlike traditional RAG (Retrieval-Augmented Generation), which relies on vector similarity to retrieve text snippets, GraphRAG first builds the knowledge base into an entity-relationship graph, then performs multi-hop reasoning along the graph structure during retrieval, enabling it to answer complex questions that require synthesizing implicit associations across multiple documents. Migrating this paradigm to the code domain, the call graph naturally serves as the skeleton of a "code knowledge graph," providing LLMs with cross-file structural context that is more precise than pure text embeddings. GitHub Copilot's "workspace context" feature is also exploring a similar path. Compared to pure text vector retrieval, structured retrieval based on call graphs holds a natural advantage in cross-file impact analysis scenarios.

Opportunities and Challenges Facing an Early-Stage Product

As a freshly launched Show HN project, Arcaide is still in its early stages and faces several typical challenges:

Multi-language support: The difficulty of parsing calling relationships varies enormously across programming languages, and building call graphs for dynamic languages (such as Python and JavaScript) is especially tricky. Take Python as an example: variable types are only determined at runtime, functions can be assigned to variables or dynamically obtained via getattr; JavaScript, meanwhile, has mechanisms like prototype chain inheritance and asynchronous callback chains. Static analysis tools can often only provide an approximate set of "possible calls," and the industry typically employs Points-to Analysis techniques to improve accuracy. Points-to analysis aims to statically infer which objects a variable may point to at runtime. Classic algorithms include the more precise but computationally complex Andersen analysis at O(n³), as well as the near-linear but less precise Steensgaard analysis. Pyright in the Python ecosystem and Flow in the JavaScript ecosystem strike a balance between accuracy and engineering feasibility precisely by combining type inference with heuristic points-to analysis.
Performance on large-scale codebases: When facing million-line codebases, ensuring that graph generation and rendering remain smooth is a hard threshold. Graph visualization itself faces a classic "layout algorithm performance bottleneck"—the commonly used Force-directed Layout algorithm has O(n²) complexity, and for graphs with more than a few thousand nodes, real-time rendering requires engineering measures such as Hierarchical Aggregation or Virtualized Rendering.
Balancing accuracy and noise: A call graph that's too detailed becomes a tangled mess, while one that's too simplified loses key information. How to intelligently collapse and filter is a core proposition for the product experience. In the field of graph visualization, this is known as the balance problem between "Information Density" and "Cognitive Load," typically requiring heuristic importance scoring (such as PageRank variants) to decide which nodes and edges are displayed by default and which are collapsed and hidden.

Summary: The Value of Code Comprehension Tools Is Being Reassessed

Arcaide represents a category of tools whose direction has always been in demand yet never perfectly solved—helping developers understand codebase structure faster and more deeply. In an era of ever-larger software systems and increasingly widespread AI-assisted programming, the importance of the "code comprehension" step will only continue to climb. One noteworthy backdrop: as AI code generation tools (GitHub Copilot, Cursor, etc.) have dramatically increased the speed of code production, the rate at which codebases bloat is accelerating in tandem—meaning the challenge of "understanding legacy code" will pile up faster, and the market space for code comprehension tools is therefore being dynamically amplified.

The multi-level call graph is a pragmatic and valuable entry point. It doesn't chase flashy AI gimmicks but instead returns to the most fundamental engineering need: seeing clearly how code actually connects to each other. For developers plagued by the "pain of reading code," this kind of code visualization tool is worth keeping an eye on.