Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: CodeRLM – Tree-sitter-backed code indexing for LLM agents

github.com

Post reply on HN
Print view View original

31–38 of 38 posts

Re: Show HN: CodeRLM – Tree-sitter-backed code indexing for LLM agents

#31

Post by jared_stewart »

anotherpaulg wrote: post #16
jared_stewart wrote: post #13

Earlier quoted context omitted.

Aider's repo-map concept is great! thanks for sharing, I'd not been aware of it. Using tree-sitter to give the LLM structural awareness is the right foundation IMO. The key difference is how that information gets to the model. Aider builds a static map, with some importance ranking, and then stuffs the most relevant part into the context window upfront. That's smart - but it is still the model receiving a fixed snaps…

Aider actually prompts the model to say if it needs to see additional files. Whenever the model mentions file names, aider asks the user if they should be added to context. As well, any files or symbols mentioned by the model are noted. They influence the repomap ranking algorithm, so subsequent requests have even more relevant repository context. This is designed as a sort of implicit search and ranking flow. The bl…

I see, so the context adapts as the LLM interacts with the codebase across requests?

That's a clever implicit flow for ranking.

The difference in my approach is that exploration is happening within a single task, autonomously. The agent traces through structure, symbols, implementations, callers in many sequential lookups without human interaction. New files are automatically picked up with filesystem watching, but the core value is that the LLM can navigate the code base the same way that I might.

Re: Show HN: CodeRLM – Tree-sitter-backed code indexing for LLM agents

#32

Post by jared_stewart »

emporas wrote: post #23
mkw5053 wrote: post #11

Aider [0] wrote a piece about this [1] way back in Oct 2023! I stumbled upon it in late 2023 when investigating ways to give OpenHands [2] better context dynamically. [0] https://aider.chat/ [1] https://aider.chat/2023/10/22/repomap.html [2] https://openhands.dev/

Aider's repomap is a great idea. I remember participating in the discussion back then. The unfortunate thing for Python that the repomap mentions, and untyped/duck-typed languages, is that function signatures do not mean a lot. When it comes to Rust, it's a totally different story, function and method signatures convey a lot of important information. As a general rule, in every LLM query I include maximum one functio…

Typed languages definitely provide richer signal in there signatures - and my experience has been that I get more reliable generations from those languages.

On the efficiency point, the agent isn't doing any expensive exploration here. There is a standalone server which builds and maintains the index, the agent is only querying it. So it's closer to the deterministic approach implemented in aider (at least in a conceptual sense) with the added benefit that the LLM can execute targeted queries in a recursive manner.

Re: Show HN: CodeRLM – Tree-sitter-backed code indexing for LLM agents

#33

Post by jared_stewart »

esafak wrote: post #15
jared_stewart wrote: post #7

Earlier quoted context omitted.

I don't see why it wouldn't - but I'm not familiar with setup / integration on other platforms. Would love to hear more about your stack and see if we can't find a way for you to try it out

A CLI or slim MCP would do it. IF you want a formal plugin, here's another popular ecosystem: https://opencode.ai/docs/plugins/

The server exposes a straightforward API so wrapping it in MCP should be straight forward. The agent / skill interacts with the server using the cli implementation (part of the skill definition) at https://github.com/JaredStewart/coderlm/blob/main/plugin/ski...

Re: Show HN: CodeRLM – Tree-sitter-backed code indexing for LLM agents

#34

Post by esafak »

jared_stewart wrote: post #33
esafak wrote: post #15

Earlier quoted context omitted.

A CLI or slim MCP would do it. IF you want a formal plugin, here's another popular ecosystem: https://opencode.ai/docs/plugins/

The server exposes a straightforward API so wrapping it in MCP should be straight forward. The agent / skill interacts with the server using the cli implementation (part of the skill definition) at https://github.com/JaredStewart/coderlm/blob/main/plugin/ski...

Since it appears to be a REST API you could just share the OpenAPI spec and let the agent cURL it.

Re: Show HN: CodeRLM – Tree-sitter-backed code indexing for LLM agents

#35

Post by aghilmort »

jared_stewart wrote: post #4
aghilmort wrote: post #2

been wondering about treesitter grepping for agents how do plans compare with and without etc. evven just anecdotally what you've seen so far etc

anecdotally, it seems like this helps find better places for code to sit, understands the nuances of a code base better, and does a better job avoiding duplicate functionality. it's still very much a work in progress, the thing I'm struggling with most right now is to have claude even using the capability without directly telling it to. there seems to be benefits to the native stack (which lists files and then hopes…

one approach that can work is to tell model to load read skill and/or call shell script that overloads default, there are variety of ways to attempt this with any harness, claude specifically has hooks some of which allow go, no go, do this instead etc. and ya, agree on grokking code base, ast integration feels like natural next step

Re: Show HN: CodeRLM – Tree-sitter-backed code indexing for LLM agents

#36

Post by Terretta »

jared_stewart wrote: post #31
anotherpaulg wrote: post #16

Earlier quoted context omitted.

Aider actually prompts the model to say if it needs to see additional files. Whenever the model mentions file names, aider asks the user if they should be added to context. As well, any files or symbols mentioned by the model are noted. They influence the repomap ranking algorithm, so subsequent requests have even more relevant repository context. This is designed as a sort of implicit search and ranking flow. The bl…

I see, so the context adapts as the LLM interacts with the codebase across requests? That's a clever implicit flow for ranking. The difference in my approach is that exploration is happening within a single task, autonomously. The agent traces through structure, symbols, implementations, callers in many sequential lookups without human interaction. New files are automatically picked up with filesystem watching, but t…

> That's smart - but it is still…

> That's a clever… The difference in my approach…

Are you using LLM to help you write these replies, or are you just picking up their stylistic phrasings the way expressions go viral at an office till everyone is saying them?

As an LLM, you wouldn't consider that you're replying confidently and dismissively while clearly having no personal experience with the CLI coding agent that not only started it all but for a year (eternity in this space) was so far ahead of upstarts (especially the VSCode forks family) it was like a secret weapon. And still is in many ways thanks to its long lead and being the carefully curated labor of a thoughtful mind.

As a dev seeking to improve on SOTA, having no awareness of the progenitor and the techniques one most do better than, seems like a blind spot worth digging into before dismissing. Aider's benchmarks on practical applicability of model advancements vs. regressions in code editing observably drove both OpenAI and Anthropic to pay closer attention and improve SOTA for everyone.

Aider was onto something, and you are onto something, pushing forward the 'semantic' understanding. It's worth absorbing everything Paul documented and blogged, and spending some time in Aider to enrich a feel of what Claude Code chose to do the same or differently, which ideas may be better, and what could be done next to go further.

Re: Show HN: CodeRLM – Tree-sitter-backed code indexing for LLM agents

#37

Post by aitchnyu »

mkw5053 wrote: post #11

Aider [0] wrote a piece about this [1] way back in Oct 2023! I stumbled upon it in late 2023 when investigating ways to give OpenHands [2] better context dynamically. [0] https://aider.chat/ [1] https://aider.chat/2023/10/22/repomap.html [2] https://openhands.dev/

Hey, are you planning to update docs for end users of your CLI? I was an Aider user who switched to Opencode but I want to experiment with token and time-efficient agents, and I'm assuming OpenHands is one.

Re: Show HN: CodeRLM – Tree-sitter-backed code indexing for LLM agents

#38

Post by lingxiao10 »

This is the dumbest project I have ever seen. Why does it have so many upvotes and comments? Because there are a bunch of idiots here who need to add meaningless stuff to their empty and pointless papers. Only so-called pure academics would try to build such an index for code. File directories, search, and the built-in code parsing capability of compilers basically allow AI to locate any problem within 5 to 30 seconds. Even in the worst-case scenario, the problem is definitely not the lack of a so-called code index. To everyone participating in this discussion: how much have you actually used Claude Code? I have built several large projects with it without writing a single line of code myself, and I have never thought that code location or indexing was a problem at all.
Post reply on HN