Nx Should Make Code Graphs Cacheable

Part Two of two. Nx already knows which files changed, which projects own them and how to share cached outputs. Its opportunity is to make finer indexes revision-aware, reusable and queryable.

Nx is an open-source monorepo platform and build system. It maps projects and their dependencies, uses that graph to decide which tasks must run, and can share cached task outputs through Nx Cloud.

Our monorepo contains 1,091 Nx projects and 9,946 captured dependencies. From a distance, the graph is impressive. It shows Angular and TypeScript, .NET, workspace tooling and the first coarse outlines of native code. The test is whether finer resolution cuts agent discovery time, token use and usage-based AI spend without lowering the change success rate.

Then I try to zoom in.

Nx can tell me which project depends on another project and which source file created the edge. It cannot normally tell me which method calls another method, which implementation satisfies an interface or which route reaches a particular service. The image has structure, but it runs out of resolution just when an unfamiliar codebase becomes interesting.

Nx's v21 documentation called its workspace model a knowledge graph. The current model remains a Project Graph of projects and dependencies. Either description fits, but only from a great height. The surprise is not that a build graph stops at projects. It is that Nx already owns valuable infrastructure around the next level down.

The hypothesis worth testing is not simply whether Nx can build another local index. It is whether code analysis is expensive and repetitive enough for Nx Cloud to reuse indexes across developers, agents and continuous integration when declared inputs match. The value depends on indexing cost, branch overlap and cache-hit rate. Nx already has much of the machinery needed to run that experiment.

This follows A Monorepo Is a Knowledge Graph. Part One argues that repositories and build systems should own source and build facts; this part asks whether Nx should help map the code within each project.

The Graph Stops at Projects

The public Project Graph contains projects, external packages and dependencies. Nx can record the source file that created a static dependency. It combines that model with targets to decide what runs, in what order and which cached outputs it can restore.

That is operational knowledge. A missing or incorrect edge can miss tests or permit stale cache reuse; an unnecessary edge usually creates extra work. Nx has good reason to keep the model quick and conservative.

It stops at project knowledge. A project node may conceal thousands of functions, classes, routes and message handlers. An edge proves that two projects are related, but not the call path that matters to the engineer standing in one of them.

The gap appears even where source is already co-located. Our native wrapper projects contain Swift and Kotlin, yet the Project Graph exposes no internal relationships. What is missing is resolution, not source.

That gap is not an argument for abandoning the Project Graph. It is an argument for placing a Code Graph beside it.

Nx Already Owns Part of the Plumbing

A useful Code Graph must answer three questions before it answers anything about code: which source state does this fact describe, which extraction rules produced it, and when should it be recomputed?

Nx already knows when declared inputs change. Its daemon keeps the Project Graph warm. Plugins map files to projects, and the change calculation identifies projects a change can influence. Its task system hashes declared source, configuration, dependency and runtime inputs. Nx Cloud can restore outputs for a matching computation hash.

This machinery detects changed inputs and distributes matching outputs. A computation hash identifies declared computation inputs, not the unique checkout that requested them. The cache key must include every source, configuration and extractor input the analysis can read; the index should record those inputs and the extractor version as provenance. At query time, the service should record the current commit and dirty-working-tree state, verify that the checkout produces the same computation hash, and attach that checkout identity to the answer.

An index cached by computation hash can save the organisation from repeated analysis when those declared inputs match. The cache supplies computation identity; the query layer supplies revision provenance. This preserves reuse without mislabelling one commit as another.

For change-impact questions, the Project Graph can seed the search with affected projects. It should not necessarily bound the search because symbol paths may cross dependants or relationships the build graph does not capture. Polygraph could eventually federate such indexes across repositories; its current public tools federate repository context, sessions, pull requests and continuous integration.

KiroGraph Shows the Missing Resolution

As of 17 August 2026, KiroGraph demonstrates one practical shape for the lower layer. Its documentation describes Tree-sitter extraction across more than 30 languages, with functions, classes, calls, routes and type hierarchies stored in local SQLite. Optional modules add architecture metrics, documentation retrieval, embeddings and persistent observations.

This is useful code knowledge, but KiroGraph maintains another index beside the build. Its index and sync lifecycle must determine freshness independently because it does not own the project graph, affected calculation or build cache.

KiroGraph is a useful feasibility example, not proof of broad demand or production-scale accuracy. It supplies the resolution Nx lacks while exposing work that an independent index must repeat: mapping files to projects, tracking source state and keeping results current.

The combination could be stronger than either tool alone. Nx could seed the search with affected projects. The Code Graph could trace relevant symbols. Compilers and tests would challenge the inferred path. A plausible call edge can guide exploration without silently deciding that a test need not run.

The Public Roadmap Travels Sideways

Nx's 2026 roadmap, reviewed on 17 August 2026, uses the phrase full codebase intelligence. Its concrete graph investments broaden or accelerate the Project Graph: synthetic monorepos, additional languages and loading parts of very large graphs only when needed. Polygraph's public tools coordinate repositories, agents, pull requests and continuous integration; they do not document symbol or call-graph queries.

In the public roadmap and open-source surface I reviewed, the clearest movement towards symbols was an external proposal for tree-shaking-based dependency narrowing. It remained low priority on 17 August 2026. The proposal uses symbol analysis to narrow Project Graph edges and improve change selection; it does not create a persistent graph that an engineer or agent can query.

That search cannot establish Nx's private plans. It suggests that full codebase intelligence is currently broader product language than a commitment to a persistent symbol graph.

Keep the Two Graphs Honest

Millions of queryable symbol nodes should not be added wholesale to the Project Graph. Dynamic dispatch, reflection, generated code, dependency injection and network calls make some relationships uncertain. High-confidence semantic extraction often needs language-specific, compiler-aware analysis. Symbol identities must survive renames, and advisory nodes could slow a graph on the critical path.

Those constraints do not automatically make a Code Graph an Nx product. Language servers and compilers already hold much of the semantic truth. The bounded opportunity is for Nx to own the source-state, project, invalidation and cache contract that makes code indexes incremental and composable. First-party indexes could prove that contract in selected ecosystems; external analysers could supply the rest.

The Project Graph should remain operational: small, fast and conservative enough to govern builds, tests and caching. The Code Graph should be advisory: detailed, provenance-rich and allowed to say that an edge is inferred. They should connect at the project and file boundary without pretending to share the same authority.

That separation also protects Nx from turning a build tool into a general knowledge platform. It need not ingest every deployment, incident, ownership judgement or business process. It needs to model the code closely enough that other systems do not have to begin by rediscovering the source tree.

Add the Missing Lens

Start with four commands: nx code callers, nx code implementations, nx code path and nx code impact. Offer the same contract through an API or Model Context Protocol adapter if consumers need one; the graph should not depend on either interface.

Platform teams should own the indexing contract, provenance model and query service. Language-integration owners should maintain extractors. Product teams should not curate a second description of relationships the source can reveal.

Nx Cloud could distribute versioned Code Graph indexes as cached task artefacts, avoiding repeated analysis across developers and agents. Polygraph could later join those indexes across repositories.

For Nx, this could become a versioned indexing capability. For an engineering leader, the test is simpler: does it raise the change success rate and dependency recall, or reduce discovery time and token use, enough to repay indexing latency, language maintenance, source-code access risk and vendor dependence? Measure cache-hit rate, branch freshness, false edges and cost per successful change against the Project Graph alone before centralising the Code Graph.

Nx does not need to build every parser or own every semantic fact. It already knows where each project lives and when its declared inputs change. It needs to make finer code indexes revision-aware, incremental and queryable, then prove which parts deserve to become Nx products.