21–30 of 49 posts
Does Claude's grep still prepend the relative path of the file before _every_ single line? Because that is nasty, especially in java projects.
Also, for java projects we do support a more deeper graph, a few of our contributors are working on making it better for java projects, let us know if you have any ideas there.
>"The problem: Every task, your coding agent starts blind. Before it changes anything, it re-explores the repo: grep a term, open a file, follow an import, back out, try again. It is rebuilding a picture of a codebase it mapped an hour ago and threw away. That rediscovery burns most of a run's tool calls, tokens, and latency, and it is pure overhead " The author of this article brings up a very interesting problem --…
What's the benchmark against graphify?
You feel it while working too. graft hands the agent the exact file and line it needs for each question, so Claude keeps using graft.
Same is true for any other cli tools, claude never actually uses them as it's trained to use grep. but for graft as we set the directive to use graft at the start of the session and before the turn, claude just knows graft exists and also get the relevant context without it going and calling tools it was not trained on.
Why these animations in the github README? why? It just made understanding anything more difficult
First of all, the whole readme section about benchmarks appears to be Claude/Codex written. What a slog to read this.
Second, they claim success on SWE-Bench Verified, but it's only on 50 tasks, not making clear how these tasks are chosen. I know from experience that you can keep selecting sets of tasks until you get a result. Also, this was run 1x, and the lift they show actually only has a p val of 0.22.
There's a famous book "how to lie with statistics". I don't think the continual posts about benchmark results here are purposeful lies, but I think it's just so easy to fool yourself (and I've been burned, most recently building http://pellmell.ai ). Also I don't think this post is the most egregious example.
I intuitively and perhaps naively thought that Claude using the LSP server would negate a lot of grep use. Is this tool solving the same problem or something else?
so graft solves for making claude code understand your codebase every session.
And I feel you can save a lot more tokens and also increase accuracy by just switching to new claude session without worrying about your codebase context. (doesn't solve for the session context yet, but we are still figuring out how can we solve for that. Maybe hooks that can manage your CLAUDE.md)
Love the idea, I was thinking about this problem a few weeks ago, but never got anywhere with it. I'm intrigued by the latency savings in particular, that sounds great. One concern I have is that right now each session gets fresh "eyes" on the problem. Right now I find I get a lot of mileage out of a combination of long-running sessions and fresh ones. I worry with a single generated concept graph that gets only incr…
For the staleness specifically we are using hooks on claude code and codex, where on every turn, or post edit or pre-tool use, we sync the graph. so that graph never goes stale. We have run tests on DeepSWE as well which are long running tasks, we got 20% better accuracy on the tasks where sonnet 5 failed. didn't want to post that numbers yet as I think we can do better on DeepSWE and on a cheaper model like gpt-5.6-…
This looks cool and the mechanism looks plausible. I found the experience of trying to understand whether the claims here are legit to be aggravating. First of all, the whole readme section about benchmarks appears to be Claude/Codex written. What a slog to read this. Second, they claim success on SWE-Bench Verified, but it's only on 50 tasks, not making clear how these tasks are chosen. I know from experience that y…