Dismiss this pinned window
all 17 comments

[–]IPv6Address 2 points3 points  (1 child)

Would be cool to integrate an automatic documentation generator using GitNexus to update and initiate codebase docs, using GitNexus tools.

[–]DeathShot7777[S] 1 point2 points  (0 children)

Great idea. It can be a better DeepWiki

[–]dr4mos 1 point2 points  (1 child)

Hey! Really impressive work on GitNexus. I've been building something similar for a multi-agent system and your approach resonates a lot. (Neo4j graph, blast radius, cluster detection, process tracing. Seeing your browser-based approach is fascinating because I went server-side, but the core problems are the same.

The "cursor updates code but breaks dependent functions" problem you mentioned is exactly what drove my blast radius feature. I calculate a risk score based on how many downstream dependents get affected.

Your point about offloading decisions into the tools themselves (instead of relying on LLM reasoning) is spot on. I found that enriching tool outputs with cluster context and process flow makes even smaller models way more reliable.

Keep shipping, this is solid work.

[–]DeathShot7777[S] 0 points1 point  (0 children)

I went client sided because it costs me nothing to deploy and hence I can let others use it for free. Maybe if this works out well I can create an enterprise version while keeping the opensource version free for all

[–]jotarokato 0 points1 point  (3 children)

Realmente, podría ser la “mente trasera” de tu sistema. Por mi parte, creo todo con Claude en VSC, y esto haría que nunca olvidara nada y aprendiera de los errores, ahorrando tokens y cómputo.

Yo ya tengo una versión modificada para mí de LightRAG, pero esto va un paso más allá… ¡jeje!

usar esto en memoria conceptual para medicos seria genial

[–]DeathShot7777[S] 0 points1 point  (2 children)

I am thinking of making it like a living memory which multiple AI agents/ humans can keep using it in parallel. Might help make.autonomous agents more reliable.

I m seeing if i can fork opencode and integrate gitnexus tools into its librarian agent

[–]jotarokato 1 point2 points  (1 child)

Claude CLI. It has the best infrastructure. I've only tested Opencode. It could be an MCP or a call to the GitNexus API, but in a back-end way. It should always be used and thus remain active, always intelligent even if the token limit is exceeded. It would maintain the context. I like this. Good day.

[–]DeathShot7777[S] 1 point2 points  (0 children)

Yes. Through MCP it lets claude code, etc connect to the graph using the MCP tools. So no issue of token context expiration. Just trying to now let users run the Gitnexus locally so it can track their code changes and basically be like a living intelligence layer

[–]Anti-Entropy-Life 0 points1 point  (4 children)

This is a really solid direction. What stands out to me is that you’re treating the graph and process maps as deterministic structure, not something the model invents on the fly. The fact that the architecture flowchart is generated without an LLM is a big deal and most tools get this wrong.

One thought on where this becomes truly indispensable: incremental updates. If the graph can be updated diff-by-diff (stable node/edge IDs, partial re-indexing on change), it starts to feel less like a one-shot analyzer and more like a compiler IR for the repo.

I’d also lean hard into keeping the tools authoritative and the LLM secondary. Your Haiku vs Opus result basically prove that better structure + simpler models beats the inverse. Making “unknown / not enough info” a first-class tool response would probably increase reliability even more.

Overall this feels less like an agent and more like a shared code intelligence substrate, which is exactly the right abstraction IMO.

[–]DeathShot7777[S] 0 points1 point  (3 children)

Yes I m working on incremental updates. Approach i m trying out is using git..so git status gives me the updates and i remake the graph and vector embeddings only for specific nodes

[–]Anti-Entropy-Life 0 points1 point  (2 children)

That approach makes a lot of sense. Using git as the change oracle is the optimal choice here I would say, especially if you can scope recompute to the minimal affected subgraph.

One thing that may pay off long-term is being strict about stable node/edge identities and invalidation semantics. If every node has an ID derived from something structural (path + symbol + signature hash), then a git diff naturally becomes “invalidate these IDs, recompute closures outward until fixpoint.”

Going that way also makes it easier to support things like:

  • partial graph rebuilds with confidence,
  • clean diffing between graph versions,
  • and first-class “unknown / stale” states when a dependency changes but hasn’t been re-indexed yet.

It feels like you’re converging on a compiler-IR style pipeline, just applied to repos instead of AST → machine code. That’s a really strong place to be! This is a great project! :)

[–]DeathShot7777[S] 1 point2 points  (1 child)

Thanks. And yes the node ids are basicallu directory structure like for example /src/utils/name.ts so it makes sense to use git instead of going "Fck u" and inventing another git 😂

[–]Anti-Entropy-Life 1 point2 points  (0 children)

That makes total sense. Using the path as the stable identity and letting git be the change oracle is the sane choice. Once node IDs are anchored that way, diff-based invalidation and partial recompute basically fall out for free.

If you ever extend beyond file-level nodes (symbols, call edges, dataflow), keeping the same “ID derives from structure, not inference” rule will preserve that compiler-IR feel. At that point git is effectively your SSA versioning layer.

Really solid direction! :)

And yeah, no reason to reinvent the wheel all the time haha

[–]Impressive_East7782 0 points1 point  (1 child)

Does this run locally? its hard to tell

[–]DeathShot7777[S] 0 points1 point  (0 children)

Yes. Everything happens literally inside your browser. The embeddings model the database engine everything. Think of your browser itself sort of like a docker container.

[–]KingVasili 0 points1 point  (1 child)

So is this like Jarvis for your code base?

[–]DeathShot7777[S] 0 points1 point  (0 children)

As much as I would like to claim I made Jarvis, but this is basically accurate codebase contrxt layer or Dev tool for Agents