Joy-Code-Graph Turns a Million-Line Repo into a Queryable Map for AI Coders

Let AI Quickly 'Understand' Your Code Repository: The Three Evolutions of the Joy-Code-Graph Cloud Service

When an AI programming assistant faces a million-line code repository, it is essentially 'blind men touching an elephant.' What we are doing is giving it a pair of eyes that can see the big picture—and these eyes are deployed in your own hands, directly connected to Joygen, and can permanently store 'memories' into your code branch.

1. Origin: What AI Coding Lacks Is Never Computing Power, but 'Context'

Today's AI programming assistants are already very powerful, but they share a common weakness—they cannot see the relationships between code.

When you ask AI to 'modify this function,' it needs to answer several questions:

Who calls this function? Will changes implicate other places?
Whom does it call? What downstream logic does it depend on?
What is the 'blast radius' of the modification?

The traditional approach is for AI to use Grep and Read to flip through files repeatedly, like looking for a needle in a haystack, which is slow and prone to omissions. The idea behind a Code Knowledge Graph (CodeGraph) is to pre-parse the entire code repository into a 'symbol relationship network'—functions, classes, interfaces, call chains, and dependency edges are all structured, allowing AI to obtain precise global context with a single query.

The graph itself is not a new concept. But what we have done this time is to turn it into a cloud service that can deeply collaborate with Joygen—and in this process, solved three truly tricky engineering problems.

2. Pain Point: Installing CodeGraph in a Sandbox Is Too Troublesome

Joygen is a cloud-based AI automatic code generation and deployment platform. The real trouble with using a code graph service in Joygen is: the cost of running CodeGraph inside a sandbox is too high.

CodeGraph requires a specific runtime, multi-language parsers, and a series of dependencies. Stuffing this entire set of things into each sandbox and installing and configuring them one by one is both cumbersome and heavy:

Heavy dependencies, complex installation, messy configuration—forcing graph-building capabilities into each sandbox is not a cost-effective path.

So we changed our thinking: refactor CodeGraph from 'a tool that needs to be installed inside the sandbox' into 'an independently deployed, remotely callable cloud service.' Zero installation inside the sandbox, usable with a single connection. The three key decisions behind this are exactly what this sharing really wants to talk about.

3. Core Highlight 1: Self-Deployment, Security Firmly in Your Own Hands

The first decision, and the most important one: this service is completely self-deployed, code and data do not leave your own boundaries.

For enterprise-level code, source code is the core asset. If graph-building capabilities are handed over to an external third-party service, it means the source code must leave the controllable range—this is unacceptable in terms of security and compliance.

Our solution is to package the entire capability into a self-deployable HTTP + MCP service that can run on self-built servers, Docker, or internal Xingyun platforms. More critically, its internal communication has a strict 'gateway' design:

Security is reflected in several layers:

In-process callbacks do not go out to the network: Internal calls for graph-building tasks go through 127.0.0.1 in-process communication, never passing through the external network, eliminating leaks in intermediate links.
Authentication gateway: External access uniformly uses Bearer Token authentication, and callback addresses are forcibly locked to the internal network 127.0.0.1, with configuration explicitly stating 'Do not set external domain names.'
Git access whitelist: Configurable to limit 'allowed Git hosts for cloning,' source code only circulates among trusted repositories.
Data autonomy and controllability: Graph data, SSH private keys, and cloned source code all reside in your own designated data directory; whoever deploys it controls it.

In one sentence: Capabilities are external thoughts, data is an internal asset. Self-deployment achieves both.

4. Core Highlight 2: Direct Connection with Joygen, One Link Handles Everything

The second decision: No bloated plugin-style integration, but a direct connection to Joygen using a standard MCP link.

MCP (Model Context Protocol) is a standard protocol for AI to collaborate with external tools. We encapsulated all graph capabilities into 11 MCP tools, and Joygen only needs one SSE endpoint address to remotely call all capabilities—no need to install any CodeGraph dependencies in the sandbox.

The ingenuity of this connection lies in 'shared engine, independent sessions':

Each Joygen task has independent session isolation but shares the same underlying engine—natively supporting multi-user, multi-task concurrency, both isolated and efficient.

More importantly, the entire collaboration process is completely autonomously completed by AI, requiring no manual command input from the user:

From 'installing dependencies, building graphs, querying' to 'synchronizing after modifications,' AI does it in one go. What Joygen gets is an out-of-the-box, on-call 'global brain for code.'

5. Core Highlight 3: Store the Graph in a Code Branch, So 'Memory' Never Evaporates

The third decision is the most ingenious stroke in the entire design: automatically save the built graph to a dedicated branch of the project's own code repository.

After the service completes graph building, it automatically creates a new codegraph/<projectId> branch and pushes the graph into it as files:

This design of 'the graph follows the code repository' achieves two benefits in one stroke:

Reusable and shareable: Share the same graph across multiple tasks and multiple collaborators, avoiding redundant graph building.
Naturally aligned versions: It is clear at a glance which code branch corresponds to which graph, never again will 'the graph and the code mismatch.'

From a 'one-time tool' to a 'reusable asset'—this step truly gives the code graph 'long-term memory.'

6. Three Evolutions, One Whole

Looking back, these three highlights are actually an interlocking whole:

Self-deployment solves 'dare to use it'—the baseline of security and compliance;
Direct connection to Joygen solves 'easy to use'—zero dependency, out-of-the-box experience;
Storing graphs in branches solves 'worth using'—turning a one-time consumption into a long-term asset.

7. Conclusion: Give AI a Pair of Eyes to See the Big Picture

The code knowledge graph is not meant to replace AI's intelligence, but to fill its cognitive blind spot regarding global code relationships.

When AI can see at a glance 'who calls whom, and where changes will ripple,' the code it writes is truly reliable; when this cognition is securely kept in your own hands, callable by Joygen at any time, and permanently deposited in the code repository—the AI programming experience has truly reached a new level.

This is our original intention for creating the Joy-Code-Graph cloud service.

Capabilities shared, data autonomous; build once, benefit long-term.