Pimp My IDE / garage dispatch
Back to garage
September 28, 2026 | code search / agent context

Search can choose the aisle. It cannot close the case.

Jevgrep 0.5.0 uses a decision model to find files and source excerpts for coding agents. The useful move is narrower than an answer engine. It gives the agent a better place to start reading.

Ask a behavior question. Limit the root. Read the returned source. Search exact names with exact tools. Judge the whole coding task.

A question can be a search primitive.

Traditional code search starts with a string, symbol, or regular expression. That works when you know the repository's vocabulary. It works poorly when the question is about behavior and the names are still unknown.

Jevgrep takes a natural-language repository question, walks the directory hierarchy, judges previews, selects files, and returns verbatim excerpts with line references. Its own architecture draws a firm line. The model classifies relevance. The calling agent owns explanation, implementation, and verification.[1]

The output is a reading lead with source attached, not an answer with certainty attached.

Preview admission buys cost with recall.

Version 0.5.0 can reject a file after judging its content preview. That cuts requests and input charges. It can also miss relevant code that appears beyond a negative preview. The project states this limit in its release notes and architecture document.[2]

This is the correct trade to expose. A completed search means the planned traversal finished. It does not mean every relevant byte was examined. Keep exact symbol search, direct reads, and test discovery beside semantic retrieval rather than behind it.

Retrieval cost is not task cost.

The project's ten-task SWE-bench comparison retained eight official solves in both cohorts. The 0.5.0 experiment cut native Jev cost by about 59 percent against the saved 0.4.3 cohort. Combined coding-agent plus retrieval cost rose by two to three percent. The maintainers accepted that trade for the release and state that the sample does not establish statistical equivalence or a speed gain.[3]

That result is more useful than a clean victory graphic. Cheaper retrieval can cause more exploration, patch revision, or verification later. Count the complete job, including failed attempts. Measure whether the patch lands and passes its checks.

The search root is a data boundary.

Eligible source content is sent to the selected provider. Default filters respect ignore files and exclude hidden paths, dependency directories, build output, binaries, and obvious credential files. The README says those filters do not guarantee that sensitive content is gone.[1]

Use the narrowest root that can answer the question. Do not treat an ignore file as a secrecy policy. Review provider and credential choices before sending proprietary code. Keep repository text in the data lane, even when a comment tells the agent to run something.

Use two search gears.

  1. Use exact search when you know a path, symbol, error string, configuration key, or test name.
  2. Use semantic retrieval when you know the behavior but not the repository's words.
  3. Read source around every returned excerpt. Follow imports, callers, tests, and configuration.
  4. Run the repository's own checks. Compare task success, total cost, elapsed time, and missed context.
Interactive makeover / semantic search sweep bench

Set the detector before the sweep

Traditional purpose replaced: one search box that hides whether the job needs exact matching or semantic retrieval. Better version: choose the query shape, close the handling gates, and copy a search plan that keeps results in the evidence lane.

Choose the signal

The selector names the question you have. The gates name what must happen around the search. This demo does not read a repository or call a model.

Search mode
Handling gates
Search plan draft1 of 4 gates closed
Physical selector

Signal sweep carriage

Ask what the code does.

The root is bounded. Privacy review, source reading, and task replay remain open.

What this component proves. It creates a query and handling plan. It does not install Jevgrep, send source, judge relevance, find code, modify a repository, or run a test.

Sources and limits

Open the source log
  1. Jevgrep repository and README, read September 28, 2026. This is the source for the command shape, provider requirements, output contract, source-upload boundary, default filters, and warning that results are evidence rather than a complete answer.
  2. Jevgrep 0.5.0 release and architecture document at v0.5.0, published September 28 and read September 28, 2026. These describe preview admission, hierarchical discovery, bounded chunks, contextual follow-up, immutable source ranges, parser support, and the explicit recall limit.
  3. Jevgrep 0.5.0 combined-cost research, read September 28, 2026. This is the source for the fixed ten-task cohort, eight of ten official solves, lower Jev cost, higher observed combined cost, missing-usage accounting, timing limits, and release decision.
  4. npm package @dzhng/jevgrep 0.5.0, published September 28 and inspected September 28, 2026. The registry identifies Node 22 or newer and the jg executable. This garage installed the package in a temporary directory and exercised jg --version and jg --help. It did not configure credentials or search a repository.
  5. Hacker News discussion for Jeff, read September 28, 2026. This discovery trail includes both interest in local decision models and one user's warning that classification accuracy was too low for their use case. The discussion does not validate Jevgrep's benchmark.

Evidence boundary. Jevgrep's task results are project-published single-run observations on ten tuned Python tasks. This dispatch verified that the 0.5.0 npm package installs and exposes its documented command surface. It did not authenticate to a provider, send source, reproduce the benchmark, or compare retrieval quality.