Practical use.
The graph is a review aid for estimating impact around changed files. It helps widen a handoff from what changed to what else may depend on it.
ShardStitch maps file relationships, impact radius, and central god nodes so the next AI knows which files are dangerous to touch.
The graph is a review aid for estimating impact around changed files. It helps widen a handoff from what changed to what else may depend on it.
This feature focuses on impact: it helps identify related files and dependency risk so the next AI does not treat an isolated diff as the whole task.
Use the graph when a stuck session left a broad or uncertain change surface. ShardStitch can point from touched files toward related files, high-centrality nodes, and likely impact areas so the next AI has a bounded inspection list.
This is a risk map, not a substitute for tests or a complete language-server call graph. Confirm the suggested relationships against the repository and run the project’s own checks before accepting a change.
After identifying the changed files, inspect their nearby relationships and use the result to build a short review list before asking another agent to continue.
For example, if a changed file defines a shared request type, use its graph neighborhood to find likely consumers and tests. Inspect those files before changing the interface, then run the focused tests that cover the consumers. If the graph shows no relationship but code search finds one, trust the code and update the review list; the graph is a lead, not an exhaustive dependency oracle.
A repository graph is an approximation of dependencies, not a proof of runtime behavior or a complete call graph. Dynamic imports, generated files, reflection, build-time wiring, and external services can be absent. Use it to ask better review questions, then confirm with code search and tests.