How to get a system map from your existing code
You inherited a codebase and nobody knows how it fits together. Here is how GATE builds an interactive system map from the code itself, and what you can do with it.
GATE builds a system map from your existing code: a parser extracts every file, class, function and import, the code is grouped into areas by how it fits together, and a model writes plain-language summaries and three to five guided tours. You get an interactive map of the system you actually have, rebuilt every night by default.
Every small business that has been around a few years owns code nobody fully understands. The agency that built your site moved on. The freelancer who wrote the booking system is unreachable. The developer who knew where everything lived left last spring. The code still runs, but the knowledge of how it fits together walked out the door.
That is the situation a system map is for. Instead of paying someone to spend weeks reading the code and writing documentation that will be stale by summer, GATE reads the code and builds an interactive map of it: every file, every class and function, and which files depend on which.
What is a system map?
A system map is a knowledge graph built from your code. The nodes are the real things in the repository: files, classes, functions and methods. The edges are real relationships: this file imports that one, this file contains that function. A parser extracts the structure, so nothing in it is written by hand: it is what the code contains, read from the code itself.
On top of the structure, the map adds the layer people need:
- Areas. The code is grouped into areas that belong together, by how the files import and call each other rather than one area per folder. These are the real modules of your system, whether or not anyone ever organized them that way. A model gives each area a plain-language label and a summary.
- Tours. Three to five guided walkthroughs of up to ten steps each through the important paths of the codebase, so a new person can follow the flow of, say, a customer placing an order, file by file.
- Issues and pull requests. For a GitHub repository, the map pulls in the 20 newest open issues and the last 30 pull requests and links each one to the files its title names, so you see where the system has been hurting and where it is changing.
- Snags. Eight fixed rules, with no model involved, flag problems on every build: functions with 5 or more parameters, functions of 150 lines or more, files of 1,000 lines or more, nesting 4 levels deep, near-identical blocks of 15 lines in two or more files, unused exports, unused files, and files that do too much (30 symbols and 20 files importing them).
How does GATE build the map?
The build is a pipeline, not a one-shot guess:
- Extract. A parser reads the repository and pulls out files, classes, functions, methods and imports. No model is involved, and the same commit always gives the same result.
- Group. The graph is clustered into areas by how the code imports and calls itself.
- Summarize. A model writes short plain-language summaries of the files, a label and summary for every area, and the tours. On a rebuild, only files whose content changed get a new summary.
- Check and publish. The pieces are assembled into the interactive map and checked against an eleven-point list, from every file and symbol kept to at least three tours. GATE’s server refuses to mark a map ready until the code has been scanned and a valid graph has been written; a build that cannot get there is marked failed, with the reason.
You point GATE at the repository. The pipeline does the rest.
What can you do with a system map?
The map earns its keep the first time you have to touch code you did not write:
- “Where is X handled?” Search the map by name instead of grepping blind. Every file and function opens with its area and its neighbours, and for a GitHub repository a link to the exact lines in the source.
- Onboarding. A new developer walks the tours instead of spending their first two weeks reading files in alphabetical order.
- Blast radius. Before changing a file, see which files import it. The import edges are read from the code, so the answer is not a guess. The map does not trace calls between individual functions.
- Due diligence. Buying a business with software in it, or taking over a project from an agency? A map of the actual code, snags included, tells you what you are inheriting before you sign.
And because the map lives in GATE, your own agent can use it too: a code session started in a mapped repository is told the map exists and how to read it, and an agent with the map tool can search it and open any file or function.
How does the map stay current?
Documentation rots because updating it is a chore someone has to remember. GATE’s map rebuilds every night by default, and with the repository’s GitHub webhook added it rebuilds on every push. Between rebuilds it says how many commits behind it is. Nothing is deleted on a rebuild: a file that disappears stays on the map, marked gone. The source of truth is the repository, not anyone’s memory.
If you have a codebase nobody fully understands, the codebase maps solution page shows GATE’s own map building itself and how to get one for your repository. It pairs naturally with hosting and deploys on the same platform: one place where your code runs, ships and is understood.
Common questions
Can GATE map my repository?
GATE's codebase maps work on any repository on GitHub and on any site already hosted on GATE. You point GATE at the repository, a parser reads the code as it is, and the map shows every file, class, function and import. Nothing is taken from documentation, so the map reflects the code you actually have, not what someone once wrote about it.
Do I need to install anything in my codebase?
No. GATE builds the map by reading the code, not by instrumenting it: there is no package to add, no config file to commit and nothing running inside your application. The only optional step is adding GATE's webhook to the GitHub repository, which lets the map rebuild on every push instead of once a night.
How is a system map different from documentation?
Documentation describes what someone once believed the system did, and it drifts. GATE's map is extracted from the code itself: which files exist, which classes and functions each file holds, and which files import which. It rebuilds every night by default, and between rebuilds it says how many commits behind the code it is, so you always know how current it is.
Can a non-developer get anything out of a code map?
Yes. GATE groups the code into areas, the real modules of the system, and a model gives each area a plain-language label and summary. A founder can see the big pieces and how they connect without reading a line of code, and three to five guided tours walk through the important paths of the system step by step.
Does GATE's map show which functions call which?
No. GATE's map stores which files import which and which classes and functions each file holds, and it uses both imports and calls to group the code into areas. It does not keep a function-to-function call graph, so it answers which files depend on a file, not every place one function is called. It is a static map of the code as written, not a profiler.
What about private code?
GATE reads the code on its own servers, and a model writes the file summaries, area labels and tours through the worker bot you choose, so that model's provider reads those files. GATE's Data Processing Agreement lists every provider and whether it may train on data. The full map is visible only to your organization; a shared link shows structure only and is open to anyone with the link unless you set a password.