How AI Quickly Reads Your Codebase: Three Evolutions of Joy-Code-Graph Cloud Service

1. Origin: AI coding lacks context

Today's AI programming assistants are powerful but share a common weakness: they cannot see the relationships between pieces of code. When you ask an AI to "modify this function," it must answer three questions: who calls the function and what downstream impact the change may have; which functions the target function calls and what downstream logic it depends on; and how large the "explosion radius" of the modification is.

Who calls this function? Will the change affect other places?

Which functions does it call? What downstream logic does it depend on?

How big is the modification's impact radius?

The traditional approach is to let the AI repeatedly grep or read files, which is slow and error‑prone. The CodeGraph idea parses the entire repository in advance into a "symbol relationship graph" that structures functions, classes, interfaces, call chains, and dependency edges, allowing the AI to retrieve precise global context with a single query.

2. Pain point: Deploying CodeGraph in a sandbox is cumbersome

Joygen is a cloud AI code generation and deployment platform. Using the CodeGraph service inside Joygen is difficult because running CodeGraph inside each sandbox requires a heavy runtime, multiple language parsers, and a series of dependencies. Installing and configuring this stack in every sandbox is both tedious and heavyweight.

Heavy dependencies, installation, and configuration make embedding the graph‑building capability into each sandbox uneconomical.

We changed the approach: we refactored CodeGraph from a tool that must be installed inside the sandbox into an independently deployed cloud service that can be accessed with zero installation—just a single connection.

3. Core Highlight 1: Self‑hosted deployment for security

The first and most important decision is that the service is fully self‑hosted, keeping code and data inside the user's boundary. For enterprise code, source is the most critical asset; handing graph‑building to an external third‑party would move the source outside the controllable range, which is unacceptable for security compliance.

Our solution packages the capability as an HTTP + MCP service that can run on self‑built servers, Docker, or an internal cloud platform. Internal communication uses process‑local calls to 127.0.0.1, never leaving the network, thus eliminating external leakage.

In‑process callback never leaves the network: graph‑building tasks communicate via 127.0.0.1 inside the process.

Auth sealing: external calls use Bearer Token authentication, and callback addresses are forced to stay on the intranet ( 127.0.0.1).

Git access whitelist: configuration limits cloning to trusted Git hosts, ensuring source only flows between approved repositories.

Data autonomy: graph data, SSH keys, and cloned source reside in a user‑specified data directory, fully controlled by the deployer.

One sentence: the capability is external, the data is internal—self‑deployment gives both.

4. Core Highlight 2: Direct MCP connection to Joygen

The second decision avoids a bulky plugin‑style integration and instead uses a standard Model Context Protocol (MCP) connection to Joygen.

All graph capabilities are exposed as 11 MCP tools; Joygen only needs a single SSE endpoint address to invoke the entire suite, eliminating any CodeGraph dependency inside the sandbox.

The integration’s elegance lies in “shared engine, isolated sessions”: each Joygen task gets an isolated session while sharing the same underlying engine, naturally supporting multi‑user, multi‑task concurrency—isolated yet efficient.

More importantly, the entire collaboration flow—from installing dependencies, building the graph, querying, to synchronizing code changes—is performed autonomously by the AI without any manual commands.

From "install dependencies, build graph, query" to "modify and sync," the AI completes the whole process in one go, giving Joygen an out‑of‑the‑box "global code brain".

5. Core Highlight 3: Persist graph in a dedicated branch

The third decision makes the design truly clever: after the graph is built, the service automatically creates a codegraph/<projectId> branch and pushes the graph files into it.

This "graph travels with the repository" design brings two advantages:

Reusable & shareable: multiple tasks and collaborators can share the same graph, avoiding repeated graph construction.

Version alignment: each code branch maps to its own graph, eliminating mismatches between code and graph.

From a one‑time tool to a reusable asset—this step gives the code graph true long‑term memory.

6. Three‑stage evolution, a cohesive whole

Looking back, the three highlights form an interlocked whole:

Self‑hosted deployment – solves the "can we use it?" security compliance question.

Direct Joygen link – solves the "is it easy to use?" zero‑dependency, out‑of‑the‑box experience.

Graph stored in branch – solves the "is it worth using?" turning a disposable tool into a lasting asset.

7. Conclusion: Giving AI a clear view of the whole codebase

Code knowledge graphs are not meant to replace AI intelligence; they are intended to fill the AI's blind spot regarding global code relationships.

When AI can instantly see who calls whom and what impact a change may have, and that knowledge stays securely in the user's hands, is callable by Joygen at any time, and is permanently persisted in the repository, AI‑assisted coding truly reaches a new level.

Ability sharing, data autonomy; one graph build, long‑term use.