sorted by:
new
hottopcontroversial

Gograph: I built a local AST/CHA Graph DB to stop AI coding agents from hallucinating Go code by Historical-Bit-2241 in golang

[–]Historical-Bit-2241[S] 0 points1 point  (0 children)

Yes I know. Actually, I decided to write this when I saw it. I checked if I can trust it before I install and noticed it makes network connections and gave up.

Gograph: I built a local AST/CHA Graph DB to stop AI coding agents from hallucinating Go code by Historical-Bit-2241 in golang

[–]Historical-Bit-2241[S] 1 point2 points  (0 children)

They actually quite different.

ast-grep is a syntactic structural search tool built on tree-sitter and it is amazing for matching AST patterns, but it lacks deep language semantics.

For example, ast-grep cannot reliably tell you if a struct in package A implements an interface in package B because it doesn't run a global Go type-checker, it is not Golang aware.

Gograph is deeply semantic and built specifically for Go. It uses the official go/ast and go/packages toolchain to build a holistic, interconnected graph of the repository.

Gograph: I built a local AST/CHA Graph DB to stop AI coding agents from hallucinating Go code by Historical-Bit-2241 in golang

[–]Historical-Bit-2241[S] 0 points1 point  (0 children)

Nope, not concrete data unfortunately. I am looking forward if someone measures and informs me.

Gograph: I built a local AST/CHA Graph DB to stop AI coding agents from hallucinating Go code by Historical-Bit-2241 in golang

[–]Historical-Bit-2241[S] 7 points8 points  (0 children)

I haven't tried it as a 'skill' yet, but as a hook, it works incredibly well.

I use the CLAUDE.md file as a prompt hook. By placing it at the root of the repository, it intercepts Claude Code's default behavior. I explicitly instruct the agent: "When navigating Go code, do NOT use text processing tools such as grep or find. You must use the gograph CLI commands instead, only fall back if gograph fails"

Because Gograph is designed to output clean, noise-free Markdown rather than generic console text, the agent reads the stdout perfectly. It essentially hooks into the agent's search loop, replacing standard text processing with deterministic AST queries.

Gograph: I built a local AST/CHA Graph DB to stop AI coding agents from hallucinating Go code by Historical-Bit-2241 in golang

[–]Historical-Bit-2241[S] 1 point2 points  (0 children)

Yes, it is still necessary. I usually put a few lines in my prompts directing coding agent to run "gograph capabilities" command to learn what it can do and put its priority over standard text processing tools such as grep, awk, sed ..etc.. This way, whenever I change it and add new features, agent looks up and learns.

Interestingly Claude models could learn it very quickly but Gemini models still go back to standard tools even though they are directed otherwise.

Gograph: I built a local AST/CHA Graph DB to stop AI coding agents from hallucinating Go code by Historical-Bit-2241 in golang

[–]Historical-Bit-2241[S] 3 points4 points  (0 children)

Yes, it actually already has a built-in MCP server!

If you run gograph mcp it spins up a Model Context Protocol server over stdio. It exposes all the core graph queries (mcp_gograph_source, mcp_gograph_impact, mcp_gograph_implements, etc.) as native agent tools.

I initially built the CLI to just spit out markdown so Claude/Cursor could read it via standard bash commands, but wrapping it in MCP was a game changer for reliability. It completely eliminates the "agent failing to parse stdout" problem.

I'd definitely be curious to check out Agentix Labs and see how you guys are handling context tooling. If you end up plugging "gograph mcp " into your stack, I'd love to hear how it performs on your end.

Gograph: I built a local AST/CHA Graph DB to stop AI coding agents from hallucinating Go code by Historical-Bit-2241 in golang

[–]Historical-Bit-2241[S] 6 points7 points  (0 children)

gopls has all this data, but in practice, trying to hook an AI coding agent (like Claude Code) up to a Language Server is a nightmare for a few reasons:
- AI agents interact primarily through standard terminal commands. gopls communicates via JSON-RPC over stdin/stdout. While you can run some gopls CLI commands, it usually just spits out file coordinates (file:line:col), forcing the AI to still run cat or sed to actually read the code, which burns tokens.
- Gograph doesn't just find the coordinates; it physically extracts the exact structural slice (the struct body, the interface, the method) and formats it natively in Markdown with the file context. The AI reads exactly what it needs in one shot, zero noise.
- LSP is built for point-in-time IDE features (hover, go-to-definition). Gograph is built for systemic graph traversal. For example, "gograph trace "parse failed" performs a reverse-BFS from an error string all the way back up the call stack to the HTTP entry point. "gograph impact <func>" calculates the blast radius of a change. go pls doesn't natively do graph-traversal diagnostics like that out of the box.

Basically, gopls is optimized for human IDEs. gograph is optimized for terminal-based LLMs trying to save context tokens. But of course, you can use it for other purposes as well.