Skip to content

Commit 3ac5138

Browse files
docs: add LLM integration feature planning document
1 parent ceb4c9a commit 3ac5138

1 file changed

Lines changed: 137 additions & 0 deletions

File tree

docs/llm-integration.md

Lines changed: 137 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,137 @@
1+
# LLM Integration — Feature Planning
2+
3+
> **Core principle:** Compute once at build time, serve compressed at query time. The graph tells you what's connected, the LLM tells you what it means, and the consuming AI gets both without reading raw code.
4+
5+
## Architecture
6+
7+
Two layers:
8+
9+
1. **Build-time LLM enrichment** — during `codegraph build`, an LLM annotates each function/class with semantic metadata (summaries, purpose, side effects, etc.) and stores it in the graph DB.
10+
2. **Query-time token savings** — the consuming AI model (via MCP) gets pre-digested context instead of raw source code.
11+
12+
```
13+
Code changes → codegraph build (+ LLM enrichment) → SQLite DB with semantic metadata
14+
15+
AI model queries via MCP
16+
17+
Gets structured summaries,
18+
not raw code → saves tokens
19+
```
20+
21+
---
22+
23+
## Features by Category
24+
25+
### Understanding & Documentation
26+
27+
#### "What problem does this function solve?"
28+
- `summaries` table — LLM-generated one-liner per node, stored at build time
29+
- MCP tool: `explain_purpose <name>` — returns summary + caller context ("it's called by X to do Y")
30+
31+
#### "Summarize this module in plain English"
32+
- Module-level rollup summaries — aggregate function summaries + dependency direction into a module narrative
33+
- MCP tool: `explain_module <file>` — returns module purpose, key exports, role in the system
34+
35+
#### "Auto-generate meaningful docstrings"
36+
- `docstrings` column on nodes — LLM-generated, aware of callers/callees/types
37+
- CLI command: `codegraph annotate` — generates or updates docstrings for changed functions
38+
- Diff-aware: only regenerate for functions whose code or dependencies changed
39+
40+
---
41+
42+
### Code Review & Quality
43+
44+
#### "Is this function doing too much?"
45+
- `complexity_notes` column — LLM assessment stored at build time: responsibility count, cohesion rating
46+
- Graph metrics feed into the assessment: fan-in, fan-out, edge count
47+
- MCP tool: `assess <name>` — returns complexity rating + specific concerns
48+
49+
#### "Are there naming inconsistencies?"
50+
- `naming_conventions` metadata per module — detected patterns (camelCase, snake_case, verb-first, etc.)
51+
- CLI command: `codegraph lint-names` — LLM compares names against detected conventions, flags outliers
52+
53+
#### "Smart PR review"
54+
- `diff-review` command — takes a diff, walks the graph for affected nodes, fetches their summaries
55+
- Returns: what changed, what's affected, risk assessment, suggested review focus areas
56+
- MCP tool: `review_diff <ref>` — structured review the consuming AI can relay to the user
57+
58+
---
59+
60+
### Refactoring Assistance
61+
62+
#### "Can I safely split this file?"
63+
- `split_analysis <file>` — graph identifies clusters of tightly-coupled functions within the file, LLM suggests groupings
64+
- Returns: proposed split, edges that would cross file boundaries, risk of circular imports
65+
66+
#### "Which functions are extraction candidates?"
67+
- `extraction_candidates` query — find functions called from multiple modules (high fan-in, low internal coupling)
68+
- LLM ranks them by utility: "this is a pure helper" vs "this has side effects, risky to move"
69+
70+
#### "Suggest backward-compatible signature change"
71+
- `signature_impact <name>` — graph provides all call sites, LLM reads each one
72+
- Returns: suggested new signature, adapter pattern if needed, list of call sites that need updating
73+
74+
---
75+
76+
### Architecture & Design
77+
78+
#### "Why does module A depend on module B?"
79+
- `dependency_path <A> <B>` — graph finds shortest path(s), LLM narrates each hop
80+
- Returns: "A imports X from B because A needs to validate tokens, and B owns the token schema"
81+
82+
#### "What's the most fragile part of the codebase?"
83+
- `fragility_report` — combines graph metrics (high fan-in + high fan-out + on many paths) with LLM reasoning
84+
- `risk_score` column per node — computed at build time from graph centrality + LLM complexity assessment
85+
- CLI command: `codegraph hotspots` — ranked list of riskiest nodes with explanations
86+
87+
#### "Suggest better module boundaries"
88+
- `boundary_analysis` — graph clustering algorithm identifies tightly-coupled groups that span modules
89+
- LLM suggests reorganization: "these 4 functions in 3 different files all deal with auth, consider consolidating"
90+
91+
---
92+
93+
### Onboarding & Navigation
94+
95+
#### "Where should I start reading?"
96+
- `entry_points` query — graph finds roots (high fan-out, low fan-in) + LLM ranks by importance
97+
- `onboarding_guide` command — generates a reading order based on dependency layers
98+
- MCP tool: `get_started` — returns ordered list: "start here, then read this, then this"
99+
100+
#### "What's the flow when a user clicks submit?"
101+
- `trace_flow <entry_point>` — graph walks the call chain, LLM narrates each step
102+
- Returns sequential narrative: "1. handler validates input → 2. calls createOrder → 3. writes to DB → 4. emits event"
103+
- `flow_narratives` table — pre-computed for key entry points at build time
104+
105+
#### "What would I need to change to add feature X?"
106+
- `change_plan <description>` — LLM reads the description, graph identifies relevant modules, LLM maps out touch points
107+
- Returns: files to modify, functions to change, new functions needed, test coverage gaps
108+
109+
---
110+
111+
### Bug Investigation
112+
113+
#### "What upstream functions could cause this bug?"
114+
- `trace_upstream <name>` — graph walks callers recursively, LLM reads each and flags suspects
115+
- `side_effects` column per node — pre-computed: "mutates state", "writes DB", "calls external service"
116+
- Returns ranked list: "most likely cause is X because it modifies the same state"
117+
118+
#### "What are the side effects of calling this function?"
119+
- `effect_analysis <name>` — graph walks the full callee tree, aggregates `side_effects` from every descendant
120+
- Returns: "calling X will: write to DB (via Y), send email (via Z), log to file (via W)"
121+
- Pre-computed at build time, invalidated when any descendant changes
122+
123+
---
124+
125+
## New Infrastructure Required
126+
127+
| What | Where | When computed |
128+
|------|-------|---------------|
129+
| `summaries` — one-line purpose per node | `nodes` table column | Build time, incremental |
130+
| `side_effects` — mutation/IO tags | `nodes` table column | Build time, incremental |
131+
| `complexity_notes` — risk assessment | `nodes` table column | Build time, incremental |
132+
| `risk_score` — fragility metric | `nodes` table column | Build time, from graph + LLM |
133+
| `flow_narratives` — traced call stories | New table | Build time for entry points |
134+
| `module_summaries` — file-level rollups | New table | Build time, re-rolled on change |
135+
| `naming_conventions` — detected patterns | Metadata table | Build time per module |
136+
| LLM provider abstraction | `llm.js` | Config: local/API/none |
137+
| Cascade invalidation | `builder.js` | When a node changes, mark dependents for re-enrichment |

0 commit comments

Comments
 (0)