Bibabomas

5 ms·

1.
by Bibabomas 2mo ago
"it works fine and this is not a bottleneck. For large projects, other parts are much slower": I don't think this is true, especially for large projects. I just ran your tool on the Kubernetes repo with 1536-dim embeddings. T
2.
by Bibabomas 3mo ago
I don't understand what you mean with your first sentence. Both SemHash and Slopo are deduplication libraries right? Regardless, finding similar code is the core functionality that enables (semantic) deduplication. I also don't th
3.
by Bibabomas 3mo ago
Have you compared this to https://github.com/MinishLab/semhash (or considered using that for the deduplication backend)?
4.
by Bibabomas 4mo ago
Fair, many tools trade off cost for performance/adherence. So far our experience is good with Semble (at least with Anthropic/OpenAI models), but if you have any feedback feel free to reach out. We're working on evaluations f
5.
by Bibabomas 4mo ago
There's a "semble savings" command you can run to see token savings. It varies heavily based on the repo: in general, the larger the project the larger the savings. Output code quality is something we're still trying to
6.
by Bibabomas 4mo ago
Hey, this skepticism is fair and we share it, which is why we don't claim end-to-end agent improvements since we haven't measured those (yet). The benchmark we published measures retrieval quality and token count during search, no
7.
by Bibabomas 4mo ago
Wow, thanks for sharing, and cool that you're working on similar things! Feel free to drop any feedback on the repo if you want!
8.
by Bibabomas 4mo ago
This is mostly done with the prompt. To be fair, we are still evaluating and improving this as well!
9.
by Bibabomas 4mo ago
Hey, what's the issue with a disk search-lib in python specifically? The library is extremely fast. Yes, we could probably squeeze some more performance in Rust, but that's not our native programming language, so we opted for doin
10.
by Bibabomas 4mo ago
In theory maybe, but in practice it hurts more than it helps I think. Irrelevant context makes the model more likely to reason from the wrong code (and it's slower and more expensive).
11.
by Bibabomas 4mo ago
Hey, thanks for the detailed feedback. For the bug, would you mind opening an issue with your setup details? This is definitely something we want to investigate and fix. The multiple queries thing is really good feedback, thanks for that, w
12.
by Bibabomas 4mo ago
The 98% is vs the grep+read loop, not grep output alone. When an agent hits an unfamiliar codebase it typically does "cat file" or reads the whole thing first, at least in my experience. If you're reliably getting agents to d
13.
by Bibabomas 4mo ago
What do you mean by this exactly?
14.
by Bibabomas 4mo ago
Hey, we do a couple of things specifically to prevent supply-chain attacks. We use trusted publishing on PyPI, and --exclude newer for uv's package resolution. We also try to use the least amount of dependencies possible. A transitive
15.
by Bibabomas 4mo ago
Yeah this is a good point, but it's complicated to do well since semble then has to be aware of everything else that happens in a session, which would then make it more intrusive (and it's deliberately designed as a local, non-int
16.
by Bibabomas 4mo ago
In practice this rarely happens though, at least in practice I rarely see agents "grep -C N" or something like that on files it didn't read yet. I use Claude Code and OpenCode extensively, and especially during the first pass
17.
by Bibabomas 4mo ago
I've had the same experience with RTK, where my agent got stuck in a loop with a faulty RTK command and could not escape it since RTK hard overwrites anything automatically. I've uninstalled it again for the time being.
18.
by Bibabomas 4mo ago
Nice! Let us know if you have any feedback or results to share, would be happy to do the same.
19.
by Bibabomas 4mo ago
Sorry to hear about the MCP integration, that's definitely something we'll look into. If you have any info about your system or how to reproduce it please let me know. Very nice to hear about the results, thanks for checking this!
20.
by Bibabomas 4mo ago
The first is hard to test for us unfortunately since we don't use Cursor. But the Claude thing is interesting. I think that providers (especially the ones that directly sell LLM calls like Anthropic) are not incentivised per se to thin
21.
by Bibabomas 4mo ago
Serena does a lot more than semble (I actually used serena before building this and didn't like how much it does by default). That also made it hard to see if it was actually working well with how many moving parts there are. Semble on
22.
by Bibabomas 4mo ago
Afaik many harnesses ship the "default" which is grep+read (like Claude Code). But I agree, IMO it's a weird gap. To be fair I don't think providers are that incentivised to reduce token burn at the moment, but my guess
23.
by Bibabomas 4mo ago
Interesting, will have a look at this, thanks for sharing.
24.
by Bibabomas 4mo ago
Hey, this is something we're actively working on, but this is hard (and expensive) to do well across harnesses/models. The grep pretraining thing is very interesting though, I've noticed the same. E.g. Sonnet 4.6 seems to tru
25.
by Bibabomas 4mo ago
Hey, codebase-memory-mcp and semble are not exactly the same, but it's an interesting comparison, I'll put it on the todolist to check that out and add it to our benchmarks if feasible. If you ever get a chance to do this same com
26.
Show HN: Semble – Code search for agents that uses 98% fewer tokens than grep(github.com)
445 points by Bibabomas 4mo ago|151 comments
27.
Show HN: Agentcheck – Check what an AI agent can access before you run it(github.com)
4 points by Bibabomas 6mo ago|1 comments