121–130 of 187 posts
The bigger problem with solutions like these is that most AI already know how to use grep and search really well because of their training. Any such new tool that you handle to the AI, takes away from the cognitive capability of the AI. Humans would normally 'learn' how to operate tools like this - but the learning in LLM's is frozen and they already with a very strong depth in existing tools like grep. For example,…
Feedback: codex-cli hangs when calling this through the MCP. The semble process even sticks around as a zombie, forever stalled out. No idea why, logs have nothing. When called through a skill via CLI style calling, GPT 5.5 loves to give a ton of search terms like it is used to doing with ripgrep. Not sure how effective this is, the short docs in the github and the instructions the agent has isn't clear on what is op…
Do inefficient grep/sed behaviors have a secondary benefit in seeding the context with breadcrumbs of code from irrelevant matches?
Would this replace something like codebase-memory-mcp[1] or improve when both is being used? [1] - https://github.com/DeusData/codebase-memory-mcp
Earlier quoted context omitted.
> These agentic AI's are already smart enough to figure out a highly optimized path to code exploration or search. Hasn't been my experience. We used to use Augment Code at work which has a thing called Context Engine - basically an MCP that can answer natural language queries about pre-indexed code. Then we switched to Claude Code, which for some reason prefers to use sed to read from files using line ranges from it…
Lol... I noticed it does weird stuff sometimes. I'll see it generate a python script inline on the CLI to edit files. Like... Yo what the fuck? It literally used the edit tool until 5 turn ago. Also, it'll run a formatter, read, edit to undo auto formatting and then continue on its merry way. What is the point of that??? Lol
Earlier quoted context omitted.
Try running both on the CK codebase. CK takes like 15 minutes to index itself and gives hundreds of completely irrelevant doc comments as results for “run model on CPU” query. Semble indexes for like 3 seconds and prints out the actual code that runs the model on the CPU.
You didn’t use `ck` directly, you instructed Claude Code to use `ck`, right?
Tried against a 84K loc C project. ck took at least 5 minutes to index, but replies are indeed fast. semble indexing (if any) took no noticeable time (except for the first download of HF model, which took a couple seconds), and replied in a couple of seconds.
Unrelated but ck was a pain to install / compile (install instructions do not say you have to lock the build / you have to have latest libc).
I'd be interested in seeing actual agent benchmarks (eg CC or Copilot CLI with grep removed and this tool instead). For example, I have explored RTK and various LSP implementations and find that the models are so heavily RL'd with grep that they do not trust results in other forms and will continually retry or reread, and all token savings are lost because the model does not trust the results of the other tools.
Interesting. I too have been working in this space, though I took a different approach. Rather than building an index, I worked on making a "smarter grep" by offering search over codebases (and any text content really) with ranking and some structural awareness of the code. Most of my time was spend dealing with performance, and as a result it runs extremely quickly. I will have to add this as a comparison to https:/…