What the tests showed
Jev finds the right files more often than keyword search, on small projects and big ones. That didn't make Claude Code faster on small changes. Here's how I found out, including what didn't work.
The test
A tool like this is only useful if the files it puts first are the ones a change needs. Git history already records that. So each test is a real past commit: its message is the task, the files it changed are the answer, and the tool sees the project as it was just before.
The score is simple. Of the files the change needed, how many made the top 10? I used real changes from six open-source projects, and made every decision on a separate set of changes, so the results weren't tuned to the tests.
It finds the right files
Plain keyword search put 69% of the needed files in its top 10. Jev put 78%. The gap was biggest in the top 5, where an agent looks first.
Commit messages are terse, though, and people type longer requests. So I had a language model rewrite each change as a request, without naming the files involved. With those, keyword search reached 75% and Jev 91%.
Two things that didn't work
Jev first reads a short summary of every file. I expected summaries tailored to each language to help. They didn't: the same files came out on top, at a higher cost, so they didn't ship.
Laya is a small model that runs on your own computer, so no code leaves it. It found fewer files than plain keyword search, which also runs locally, and took up to a minute per search. It's still there for anyone who needs everything local.
Big projects
The first projects were small to medium, so I added vscode and airflow, using only changes from when they already had 8,000 to 11,000 files. Everything finds less in a codebase that size, but Jev kept its lead: 60% of needed files in its top 10, against 47% for keyword search, at about 5 seconds and a few cents a search.
It didn't make Claude Code faster, yet
This was the question that mattered most. Claude Code with Opus made 40 of the changes three times: on its own, with Jev's file list, and with the list plus the most relevant lines of code.
All three took about 10 steps, 20 cents and 40 seconds a change. The changes were easy for Opus: it found the right files with a couple of searches, so a list had little to save. It's like handing a map to someone who already knows the neighborhood.
A trial on 10 changes had looked better, with a fifth fewer steps. The full 40 showed that was mostly those 10.
What's next
The tool is good at its own job. What's untested is whether that saves work where searching is actually hard: large projects, changes that span many files, and weaker models that search less well. A test with Sonnet and Haiku had started when the Jev credits ran out. The harness picks up where it stopped.