LightRAG and graphrag are two open-source frameworks with overlapping functionality — both perform graph-based retrieval-augmented generation. We ran a cross-repo-intelligence analysis across both, and the result was zero cross-repo edges. This is not a tool failure. This is the correct answer. The two systems have no integration relationship, so zero results actually draw a clear boundary: cross-repo analysis solves a fundamentally different problem than single-repo analysis.
What This Is
So-called "cross-repo analysis" treats multiple code repositories as a single whole and maps the call relationships between them. Its job is concrete: scan all projects for HTTP route definitions (Route) and external requests (HTTP_CALLS), then perform path matching — if service A sends a request to an endpoint on service B, draw an edge between the two repos. The same logic applies to message queues (Kafka topics), gRPC, Redis pub/sub (a message subscribe/publish mechanism), and similar channels.
We chose LightRAG and graphrag for this experiment because they look alike — both are graph-enhanced RAG. But reading the code closely reveals a sharp difference in roles: LightRAG is a REST API (a web interface specification) server, exposing endpoints like /query and /documents that wait to be called; graphrag is a command-line tool plus a Python SDK (software development kit) that only makes outbound calls to the large-model service litellm, and does not expose its own endpoints. The two are parallel substitutes, not an upstream-downstream pair — returning zero cross-repo edges is entirely reasonable from an engineering standpoint.
Industry View
Supporters see this as progress in engineering capability: under microservices architecture, a single-repo call graph cuts off abruptly at service boundaries, leaving an incomplete map full of "dangling terminal nodes." Cross-repo analysis connects those breakpoints and can answer questions that single-repo analysis is physically incapable of answering — "if I change an endpoint, which upstream services are affected?" and "if the message format changes, will downstream consumers notice?"
The objections are equally worth noting. One criticism: cross-repo analysis depends heavily on deployment conventions. Slight differences in HTTP paths, topic names, or gRPC service names cause matching to miss; inside a 50-microservice enterprise, simply agreeing on consistent naming conventions can take months. Another, sharper voice argues: rather than pouring effort into drawing cross-repo dependency graphs, just deploy a service mesh (dedicated infrastructure for managing inter-service communication, e.g., Istio) — it automatically collects call relationships at runtime, and includes circuit breaking and rate limiting, making it more accurate than static code analysis. Of course, critics acknowledge the two aren't in conflict: service mesh handles runtime; cross-repo analysis handles code review and change-impact assessment. Each covers its own turf.
Impact on Regular People
For enterprise IT: if your company is breaking systems into microservices, this is a wake-up call — the more you split, the more invisible inter-service dependencies become. When something breaks, root-cause cost rises exponentially. A single team's call graph is no longer enough.
For individual careers: readers working in backend development or architecture, next time you're debugging across services, try listing the complete call chain — if you find you can't draw it, your team's dependency governance is already flashing red. That's worth prioritizing over overtime crunches.
For the consumer market: this story doesn't directly affect ordinary consumers right now. But flip the angle — when the banking app or e-commerce app you're using fails, the speed of "which service is down" diagnostics depends, to some degree, on whether the engineering team has that cross-repo map.