God node
Graphify glossary
A node with a disproportionate number of edges — the module everything imports — where changes carry the most risk.
A god node is a node with a disproportionate number of edges: the utility module everything imports, the config object every service touches, the base class half the codebase inherits from. Every codebase of any age has a few. They aren't necessarily bad design — sometimes a thing really is central — but they are always where change is most dangerous, because an edit to a god node ripples outward along every one of those edges.
The trouble is that god nodes are invisible until something maps them. No single file announces 'forty-one modules depend on me'; that fact only exists in aggregate, across the whole dependency structure. This is exactly the kind of property a graph computes trivially — count the edges per node, sort — and that grep-based exploration essentially never surfaces, because no one greps for 'what is imported the most.'
Graphify calls out god nodes in GRAPH_REPORT.md, generated when you run /graphify . on a repo. In practice they're useful in three moments: before an edit, to know your blast radius; during refactor planning, because a god node is usually either a genuine core or an accidental dumping ground, and the graph helps you tell which; and during onboarding, since the most-connected nodes are a decent first answer to 'where should I start reading?'
They matter to AI assistants for the same reason they matter to you. An assistant editing a god node without knowing it's a god node will happily make a 'small' change with forty downstream consequences; an assistant that can query the graph sees the degree count first and can check the callers before touching anything.
Related terms
- Community (cluster) — A group of nodes densely connected to each other and only loosely connected to the rest of the graph — usually a real subsystem like auth or billing.
- Blast radius — Everything transitively affected by a change — the callers of a function, their callers, and the configs and tests that reference them.
- Edge — A typed, directed relationship between two nodes — calls, imports, defines, references — each carrying a provenance tag.