|
| 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