A developer on r/LLMDevs built doma (DOcument MAtcher) — a single-binary BM25 search tool written in Odin — because Claude Code kept “grepping wildly all over the place” and missing relevant results.
The tool and its sibling doyo (DOcument YOinker) were both built using Claude Code itself. The design philosophy is blunt:
- Single binary, no external dependencies — no NodeJS, no MCP servers, no supply chain bloat
- BM25 ranking instead of pattern matching — returns semantically relevant results, cutting search misses
- Written in Odin — low footprint, fast startup
- doyo handles document acquisition — companion tool for pulling docs, though the author admits it’s “not quite as elegant”
The core problem: when an LLM agent like Claude Code searches a codebase with grep, it pattern-matches strings. BM25 ranks documents by term relevance, so a search for “authentication middleware” surfaces the right files even without exact string matches. The author reports doma is “significantly faster than grep” in testing while also reducing search misses.
This matters because agent search behavior is a real bottleneck. Claude Code and similar tools burn tokens and time running repeated grep commands across a codebase, often missing context that a ranking approach would catch on the first pass.
NOTE
The author recommends adding doma instructions to your per-project CLAUDE.md so Claude Code knows when and how to invoke it instead of defaulting to grep.
The anti-MCP stance is deliberate. The author explicitly calls out MCP servers as part of the dependency bloat they’re avoiding — opting for a standalone binary an agent can shell into rather than a protocol-based integration.
Source thread and tool links on r/LLMDevs. No npm install required.