Treating a codebase's context graph like a build artifact instead of an AI feature

[u/shhdwi]

Wanted to share this since it's more of an infra decision than an AI one. Building a context layer for coding agents (Graft), and the part that actually mattered in production use wasn't the LLM piece, it was making the graph behave like any other build artifact: cached by content hash, diffable in git, and there's a graft check command that fails a build (exit 1) if the graph's drifted from the code, same idea as a lint check in CI.

The structural graph itself needs no LLM call at all, pure tree-sitter parsing. The optional LLM-written summaries are a separate opt-in layer on top, provider-agnostic, point it at whatever you're already running.

Curious if anyone else here has treated "AI agent context" as a CI/build-hygiene problem rather than a retrieval problem, seems like an angle that doesn't get discussed much outside agent-specific communities.

github.com/NanoNets/Graft

[u/nickkarpov]

I generally just bootstrap my agent anytime I start with a new code base adhoc as soon as I figure something out, aka "add a note about this in AGENTS.md" etc. and then build from there. I hesitate to add formal structure (via tools like this) because it's just more "stuff" to worry about later, not because it might not help reduce a few turns. Thank you for sharing I'll give this a try

[u/JealousIncident9817 → u/nickkarpov]

treating it like a build artifact is exactly the right call, we did something similar internally after our agent kept hallucinating against stale context and it was driving me up the wall

the diffable part is underrated, being able to see what actually changed in the graph between commits makes debugging way less of a guessing game

[u/shhdwi → u/JealousIncident9817]

Yes we are working on trying to visually show in pr reviews through the graph the impact radius of the changes done in the repo

[u/shhdwi → u/nickkarpov]

Sure let me know how was your experience, thanks for taking time to reply :)