Knowledge Graphs for Codebases: The Future of Developer Tools
Every IDE and code editor treats your codebase as a file tree. Some add symbol tables and call graphs. A few track git history. But fundamentally, they're all working with the same primitive data structure: directories containing files containing text.
This worked fine when codebases were 10K lines. It barely works at 100K. At 1M+ lines, it completely falls apart.
The real structure of a codebase isn't hierarchical. It's a graph. Features span multiple files. Teams own overlapping components. Functions call each other across service boundaries. Dependencies create cycles. Documentation refers to code that refers back to documentation.
Treating this as a tree is like using a spreadsheet for a relational database. You can technically make it work, but you're fighting the tool the entire time.
When you have 5,000 files, "find usages" and "go to definition" feel like magic. When you have 50,000 files, they feel like a coin flip.
The problem isn't the implementation. LSP servers are remarkably good at parsing syntax and following references. The problem is the mental model.
Say you're debugging a payment flow. The code touches:
A React component in apps/web/src/checkout
API routes in apps/api/payments
A service in packages/billing-core
Database migrations in migrations/2024-03
Shared types in packages/types
Feature flags in config/features.json
Monitoring dashboards in observability/grafana
Your IDE can jump between these files. But it can't answer: "What is the payment flow?" It can't show you that the billing-core package is owned by the payments team, who last touched it 3 months ago, and that it has unusually high complexity for its size.
This isn't a file tree problem. It's a graph problem.
What Is a Code Knowledge Graph?
A knowledge graph represents entities and their relationships. In a codebase:
Traditional tools give you some of this. Go to definition is following an "implements" edge. Find references is traversing "calls" edges in reverse. Git blame is a "last-modified-by" relationship.
But they give you these relationships in isolation. Want to know which features the payments team owns? You'd need to:
Find team membership (not in the code)
Map people to git commits
Analyze commit patterns per directory
Infer feature boundaries from directory structure
Hope the directory structure actually reflects features
A knowledge graph makes this a single query: MATCH (team:Team {name: "payments"})-[:OWNS]->(feature:Feature) RETURN feature
More importantly, it makes this kind of query composable. "Show me high-churn features with no clear owner" becomes possible. "Find APIs with breaking changes that weren't documented" becomes trivial.
The Onboarding Problem
New engineers spend their first month building a mental model of the codebase. They ask:
What features exist?
How do they work?
Who owns what?
Where should I add this new code?
Why was this built this way?
The answers are scattered across:
Code comments (sometimes outdated)
README files (often stale)
Architecture docs (if they exist)
Slack messages (unsearchable)
Institutional knowledge (locked in senior engineers' heads)
A knowledge graph centralizes this. Not as documentation you have to maintain, but as structure extracted from the code itself.
When Glue analyzes a codebase, it doesn't just parse syntax. It discovers features by clustering related files, traces feature boundaries across service boundaries, and maps ownership from git history. The graph emerges from the code, not from what someone remembered to document.
This matters for onboarding because the graph is always current. When a feature moves from the checkout team to the payments team (via commit patterns), the graph updates automatically. When a new service gets added, its relationships to existing features get discovered.
AI Tools Need Better Context
Current AI coding assistants have a context problem. They can see the current file. Maybe a few related files. But they don't understand the structure of what they're looking at.
Ask Claude to "add logging to the payment flow" and it doesn't know what the payment flow is. You have to manually paste in 6 different files, explain how they're connected, and hope the context window is big enough.
A knowledge graph solves this. The AI doesn't need the entire codebase in context. It needs the relevant subgraph.
For "add logging to the payment flow":
Query: MATCH (f:Feature {name: "payment-flow"})-[:CONTAINS]->(file:File) RETURN file
Get 6 specific files that comprise the feature
Include them in the LLM context
The AI now has exactly what it needs, nothing more
This is what Glue's MCP integration does. When you're coding in Cursor or using Claude, Glue acts as a context provider. The AI can query the knowledge graph to fetch relevant code, understand relationships, and see metadata like complexity and ownership.
The difference is dramatic. Instead of "here's a file, help me change it," you get "here's a feature, its dependencies, its owners, and its recent churn — now help me evolve it safely."
Health Scores as Graph Attributes
Code health metrics are useful, but only if you can query them in context.
"This function has cyclomatic complexity of 47" — okay, so what? Is it core infrastructure that's been stable for years, or a new feature that's changing daily? Is it owned by a single expert or split across three teams?
When health metrics live in the knowledge graph, they become contextual:
// High-complexity code with unclear ownership
MATCH (f:Function)-[:IN_FILE]->(file:File)
WHERE f.complexity > 30
AND size((file)<-[:OWNS]-(:Engineer)) > 3
RETURN f, file
// Frequently changing code touching sensitive areas
MATCH (f:File)-[:CALLS]->(auth:File {tag: "authentication"})
WHERE f.churnRate > 0.8
RETURN f
The graph makes these relationships explicit. It's not just "files with high churn" — it's "files with high churn that touch authentication and have changed ownership twice this quarter."
This is especially powerful for understanding risk. Before deploying, you want to know: what features are affected? Who needs to be in the on-call rotation? What other systems might break?
Traditional dependency graphs show you the technical connections. A knowledge graph also shows you the organizational connections. The payment feature calls the fraud detection API, which is owned by the risk team, who are all in Europe and about to go on holiday. Maybe wait until Monday.
Query Patterns That Matter
The real power shows up in queries you couldn't easily answer before:
Gap analysis: "What features have no documentation?"
MATCH (f:Feature)
WHERE NOT exists((f)-[:DOCUMENTED_BY]->(:Doc))
RETURN f.name
Ownership churn: "What code changed teams recently?"
MATCH (f:File)<-[o:OWNS]-(t:Team)
WHERE o.since > date() - duration('P90D')
RETURN f, t
Blast radius: "What features depend on this service?"
MATCH (s:Service {name: "auth-api"})<-[:DEPENDS_ON*]-(f:Feature)
RETURN DISTINCT f
Knowledge silos: "What critical code has a single owner?"
MATCH (f:File {critical: true})<-[:OWNS]-(e:Engineer)
WHERE NOT exists((f)<-[:OWNS]-(:Engineer WHERE Engineer <> e))
RETURN f, e
These aren't hypothetical. These are the questions engineering leaders ask every week. Right now, answering them requires manual investigation, spreadsheet archaeology, or just giving up.
With a knowledge graph, they're queries.
Building Your Own vs. Using Existing Tools
You could build this yourself. The technology isn't exotic. Neo4j or similar graph databases. TreeSitter for parsing. Git log for history. Some clustering algorithms for feature detection.
The hard part isn't the infrastructure. It's keeping the graph updated and accurate.
A codebase changes constantly. Files move. Teams reorganize. Features evolve. If your graph gets stale, it becomes worse than useless — it becomes misleading.
This is why tools like Glue exist. The value isn't just the initial graph construction. It's the continuous synchronization. Every commit updates ownership patterns. Every PR updates documentation links. Every deployment updates the risk model.
The graph stays fresh because it's derived from ground truth: the code itself, git history, and how people actually work.
The Composability Advantage
The real insight: a knowledge graph isn't a feature, it's a foundation.
Once your codebase is a queryable graph, everything becomes easier:
Documentation that shows live code examples
Search that understands "payment features touched by Alice last month"
AI assistants that fetch relevant context automatically
Dashboards that visualize team boundaries and code health
Migration tools that understand impact across features
This is why the data model matters more than any individual tool. File trees are the wrong abstraction. Graphs are the right one.
Where This Goes Next
The frontier is making graphs collaborative and real-time. Right now, most code intelligence tools work in isolation. You run analysis, get results, maybe update some dashboards.
But code is collaborative. Multiple people changing multiple things simultaneously. The knowledge graph should reflect this.
Imagine: you're reviewing a PR. The diff shows file changes. The graph shows feature impact, ownership conflicts, and related in-flight changes from other engineers. Before you approve, you see that merging this will temporarily break the admin dashboard (because another PR just changed a shared API), and the dashboard team isn't online for 4 hours.
This isn't future tech. It's just treating the codebase as a living graph instead of a static tree.
The tools will catch up. The question is whether you're building on the right foundation.