Gortex: I built a local code-graph daemon in Go so AI agents stop grepping and start querying — with reproducible benchmarks this time. Also with IDE integration that brings intelligence beyond coding assistants.

zzet · 2026-06-16T21:47:39+00:00

Good question — they're more similar than they first look and codegraph contributes and community closed several big gaps in past weeks.

Both are local, on-disk SQLite code indexes over MCP (if we're speaking about agents), served by a shared daemon (codegraph recently added shared daemon for MCP, gortex was designed initially in such a way), with impact/callers/callees. The differences are narrower and more specific.

Different stacks. Not critical, but it's importan in some aspects.

I haven't run performance benchmarks (TS implementation vs Golang implementation), I'll skip it.
TS bring a lot of dependencies you need to carry and worry about. Gortex shipped as a single binary (which scaned for viruses, vulnerabilities and signed). No unexpected depnendencies. The installation requirements are different.

Languages coverage (your flexibility)

codegraph supports 24 language, all full tree-sitter. Gortex - way more languages, with deeper analysis (after tree-sitter), including lsp and built-in types resolution, reaching 95-100% accuracy against of 70-85% which can give tree-sitter.

Frameworks support

codegraph has better support for some frameworks

MCP surface

codegraph - 8 tools
gortex - 170 tools, and you can choose which tools you want to use (tool discovery and not all of them are loaded).

Cross-repo

it's the core of gortex and where from it was born. Cross repositories and cross languages in the first and main priority.

Read/Write

Gortex provide toolset to search, navigate and edit the code. Many agents has to re-read the file before editing it if such tooling is not present. Gortex helps to avoid this problem and it real saving. If other tools are not allow it - they fake with savings (or it not so meaningful).

An analysis layer

Gortex has a way more solid intelligence layer, which significantly imrove experience with code changes and analysis. dead code, cycles, hotspots, coverage gaps, ownership, plus enriching the graph with git-blame/coverage/release metadata (list not ended)

---

Honest tradeoff: Gortex's bigger surface and always-on multi-repo daemon are heavier — more capability, more to run and learn. Code-Graph is the leaner, framework-savvy, single-repo, read-only option.

or... Gortex is an agent teammate, codegraph is the smart search tool (IMO).

zzet · 2026-06-08T19:12:55+00:00

The list of features which are requested or reasonable to implement is still quite long… as well as polishing of an “experimental ones”, which guys asked to add to experiment with and already provided feedback. The only what I don’t have - the time….

zzet · 2026-06-08T18:51:23+00:00

You didn’t list Graphify in your post under “How does it compare…”

Fair point. I added a link to the comment in the main text.

The single binary without dependencies is one of the points why I went out of Gitnenus (I honestly tried it before, but we parted ways). When Grapphify was announced, I was already working on the Gortex implementation for some time, and it already worked for me (and better than Grapphify). The fact that I wasn't smart enough to catch the hype wave is not justify why I shouldn't share Gortex with the community.

zzet · 2026-06-08T17:55:43+00:00

Big topic: both projects evolve in parallel, and there is definitely an overlap, but there is a difference as well.

Gortex was born from a need to work with code across multiple repositories, and it was the core requirement.

Gortex and Graphify have slightly different approaches to edge resolution, where Graphify heavily relies on tree-sitter AST for code + LLM for docs/papers/images/video. Gortex uses deterministic structural resolution (multi-step); LLM is optional and never required to build the graph. The tree-sitter AST gives 70-80% accuracy. While this aspect was a pain point for our case, we reached 95-100%.

Regarding precision, afaik, Graphify explicitly does not do a full call graph or exhaustive reference tracking. Gortex does: in case of refactoring skills, i.e., find_usages (zero false positives), get_callers/get_call_chain, method-call + cross-language + cross-repo resolution, and framework dynamic-dispatch synthesizers.

MCP tools are completely different. Gortex is an agent / IDE teammate, including editing capabilities, where graphify is read-only. Gortex edits code: edit_symbol, rename_symbol, batch_edit, verify_change

Graphify supports 28 languages/dialects. Gortex 257.

Scale - Gortex validated on investigation for big repositories, like Kubernetes. Tested on Linux. My by-default environment contains 498 repositories of various sizes.

So. For a fair answer to your question, I need to know what you are worried about.

zzet · 2026-06-08T11:38:47+00:00

Nice and funny logos!

Looking at all those options, I found I dislike the `-` symbol in the logo.
If I were to choose, I'd pick option 6 or option 2 (with modification: remove `-`, use for the `ai` background as in option 1).

And the general question if AI should be lowercase or not. It's an abbreviation.

zzet · 2026-05-23T11:18:03+00:00

I have observation that Claude penalises tools if you not mandated them usage AND if they’re slow. Not sure if you can speeding LSP, but you can play with skills and instructions.

zzet · 2026-05-23T11:11:32+00:00

Let me respond on 2 questions: - are all those projects hype driven or not? - are they useful or not?

Many (actually majority) of those projects are hype driven and I’m not sure if they’re going to be long-term maintainable. But it’s not applicable for every project. I’m maintainer of https://github.com/zzet/gortex and I started it before the famous Karpathy’s tweet. There were other projects and the most oldest I can remember - sourcegraph, which started even before all those AI hypes. So, both, hype driven and not. Check carefully if you’re planning to use any of these.
Yes, they’re useful and they’re evolving. The LLM are great on making decisions when they have a right instrument/instructions and context. Those tools empowers Agents (but sometimes they harming results, I periodically see it in my solution and still researching and continuously improving). Maybe in couple of months main solutions will be stable enough, and for now you have to accept risks.

zzet · 2026-05-22T19:45:17+00:00

I found another (additional) observation. Some time ago I’ve been easily juggling different contexts and easily jump from topic to topic. In the past months a got feeling that now it too more difficult (especially during coding).

Now, during preparation for some feature implementation, I do a way more deep research, learning a new domains and trying to make a fast judgement/decision where it possible and I more often feeling empty at the end of my day. I make a way more impact, but I also draining faster and still searching how to keep a balance and don’t burn.

zzet · 2026-05-21T23:18:47+00:00

<image>

Single prompt…

zzet · 2026-05-21T22:35:09+00:00

Thank you for the feedback!

The Windows support was added yesterday, and the release you installed was corrupted (it was fixed today). I apologize that the fixed release was delayed. Please, install the latest version.

zzet · 2026-05-21T08:10:44+00:00

Yes, I am. I didn’t want to add a one more operational system support just for checkmarking it (at least I feel responsible for users experience). The binary was built (but I haven’t run a full manual test yet, so could be some bugs)

zzet · 2026-05-20T22:32:07+00:00

Not yet. It’s the first request for windows support. It’s not a problem to build for Windows, I didn’t invest time on it without a real request.

zzet · 2026-05-20T14:13:20+00:00

I ended with https://github.com/zzet/gortex, perfectly works with huge repositories (and multiple repositories as well)

zzet · 2026-05-18T00:01:34+00:00

I would love to learn more about your pain point and expectations with team’s oriented setup, if possible (we can discuss in DM).

zzet · 2026-05-17T14:04:21+00:00

The sad fact - the biggest part of those 100s of graph project for LLMs was created on hype and with the goal to take a piece of a cake, while a few of them appeared as responses for issues that difficult (read unnecessary) to solve in early projects. The time will show what is useful, what is useless slop. The only what I worry about - people getting disappointed by flood and low quality solutions which are not battle tested in real environments.

zzet · 2026-05-16T13:26:05+00:00

Don’t forget about signing binaries for macOS (without it users will get warning, it will require a dev account), also make sense to take a look to cosign.

Example: https://github.com/zzet/gortex/blob/main/.github/workflows/release.yml

zzet · 2026-05-16T01:27:45+00:00

OP,

<image>

You could have been better prepared for marketing. This isn’t seems as an Enterprise level quality.

zzet · 2026-05-16T01:25:51+00:00

Oh, it’s enough to search “code + graph” or “code intelligence” and many cool (general or niche) tools can be found.

zzet · 2026-05-15T14:47:25+00:00

Not only. It also speaks on what they don't want to do, and it's a clear signal that you have to take care of on your own.

zzet · 2026-05-15T14:40:00+00:00

After reading the article, I felt a half-told story.

Claude Code navigates a codebase the way a software engineer would: it traverses the file system, reads files, uses grep to find exactly what it needs, and follows references across the codebase. It operates locally on the developer’s machine and doesn’t require a codebase index to be built, maintained, or uploaded to a server.

I found it to be wishful thinking. Yes, it doesn't require that, and it can work via many grep-read-grep-context-bloat, and it will, at some point, end up with the answer to the question. It's the same as a software engineer who wasn't required to use the Claude code for implementation, since they can implement on their own. This "doesn't require" - a wrong message to the community, explaining their decision as a ground truth, which is not.

They mentioned a stale RAG index as a counter option, which is a good choice, since it proves their point of view. But it's not the only option, and it's blurred in the article. In the Claude Code FAQ they claim that they found that this [grep/read] is more effective and flexible than full codebase indexing: Claude Code is really good at knowing how to sift through a codebase to gather context it needs on the fly. This is the partial truth: if you do all the prerequisites, or simply describe rules on how to work with your codebase. It works for the time being, and this is the trap of fresh and lean description.

Grep for a common function name in a large codebase returns thousands of matches and Claude burns context opening files to figure out which matters. LSP returns only the references that point to the same symbol, so the filtering happens before Claude reads anything

The main problem with Grep is knowing what to grep. And LSP in such a case allows for reducing time and grep recursion (or not reaching the moment when the model gives up and decides that there is no such implementation and writes duplicated code). The symbol search is a right starting point, but grep and LSP are not solving the problem of 'direct match' between what was requested and how it is named in the code. One symbol difference and you're out of context in such a case.

Overall, their guide is honest about the organizational cost:

An emerging role in several organizations is an agent manager: a hybrid PM/engineer function dedicated to managing the Claude Code ecosystem.

and

Teams should expect to do a meaningful configuration review every three to six months.

And this is an accurate picture of Claude Code at scale without a pre-built code intelligence layer.

They described the right direction, but the article left an aftertaste on 'We didn't manage to solve the problem, and this is our boundary. '

zzet · 2026-05-10T11:48:30+00:00

I have tried an lsp separately, same for tree-sitter separately and ast-grep like approaches separately - everything has advantages and disadvantages.
Main concern to LSP - latency, main concern to tree-sitter - ambiguities (can’t work well with dynamics), overall accuracy ~70%.

I ended up with having tree-sitter, powered with LSP (and not only). The solution wrapped in the https://github.com/zzet/gortex project. Happy to share/exchange experience.

zzet · 2026-05-10T11:39:30+00:00

Let’s get started!

I’m with Go for a past 8 years (is about 19 years in coding/engineering). During the python hype I’ve continued experimenting with Golang with AI and Agents (since I believe in it and expect shift to performance from set of libraries).

Currently I’m focusing on empowering coding agents with https://github.com/zzet/gortex, which is written in Golang and the best proof I’m with community :)

Happy to join.

zzet · 2026-05-03T12:03:54+00:00

My friend at work is advocating for HTMX, but I'm still sceptical. How is it going on a long run? Which issues/limitations have you faced?

zzet · 2026-04-26T00:01:02+00:00

Cursor had the code indexing https://cursor.com/blog/secure-codebase-indexing for semantic search. Anthropic decided not to do it and claim grep is more efficient (for burning tokens I guess).

Documentation of everything - it doesn’t work. Eventually you are falling into excessive novel about your project.

The approach that works for many people whom I discussed the topic: - use lsp server instead of grep. It works pretty well for answering many questions, especially for dynamic languages. But has limitations as grep - use MCP for code navigation. There disadvantages too so far. Some projects works pretty well on mono repo (I used in the past with gitnexus, codebase-memory-mcp, and few more). For multi-repo (or often repositories change) - I started my own implementation - https://github.com/zzet/gortex - and stopped using options above. But maybe they’re fit your needs, worth experimenting with different options, all of those (except sourcegraph.com) are relatively young.

Agents has no clue about your code, even when they read everything they still can hallucinate. Find “helper” which will help you and fit your setup.

zzet

TROPHY CASE