No embeddings at all, neither stored nor on-the-fly.

Instead of converting queries to vectors, Mantic.sh uses structural inference, it ranks files based on path components, folder depth, naming patterns, and git metadata.

So "stripe webhook" matches /services/stripe/webhook.handler.ts highly because the path literally contains both terms in logical positions, not because their embeddings are close in vector space.

"Cognitive" just means it mirrors how developers already think about code organization, it encodes intent into paths, so searching paths directly often beats semantic similarity.

I'm guessing this is the ranker: https://github.com/marcoaapfortes/Mantic.sh/blob/main/src/br...

You should benchmark this against other rankers.

Working on it right now

This is just typical trash you get out of LLM. I flagged this AI slop.

Do you want to objectively state your criticisms instead of this handwaving dismissal?

What kind of agent workflow is it called when you post a hastily vibecoded Show HN, feed glaringly obvious user feedback reports one by one into the LLM, wait for the LLM to course-correct (YOU'RE ABSOLUTELY RIGHT!), then push a coincidentally timed "bugfix" while informing the user that their feedback was addressed by said bugfix?

So your complaint is what exactly? How quickly the developer is iterating and responding to market feedback?

Where you do think all those "weights" come from? They are all hallucinated. The rest of the code is too.

I think there’s a misunderstanding of mantic.sh architecture...

The “weights” as you described in Mantic.sh are not neural network weights. They’re deterministic ranking heuristics, similar to what IDE file pickers use. For example, extension weights, path depth penalties, and filename matches. You can see them directly in brain-scorer.ts (EXTENSION_WEIGHTS).

const EXTENSION_WEIGHTS: Record<string, number> = { '.ts': 20, '.tsx': 20, '.js': 15, '.jsx': 15, '.rs': 20, '.go': 20, '.py': 15, '.prisma': 15, '.graphql': 10, '.css': 5, '.json': 5, '.md': 2 };

There’s no LLM involved in the actual search or scoring, it’s a static heuristic engine, not a learned model.

I'd love to have the implementation critiqued on its merits!

> So "stripe webhook" matches /services/stripe/webhook.handler.ts highly because the path literally contains both terms in logical positions

This sounds a lot like document search ontop of your specific attributes and you have a custom ranking algorithm.

Correct! The key insight isn't the algorithm itself—it's that structural metadata is enough. Traditional tools assume you need semantic understanding (embeddings), but we found that path structure + filename + recency gets you 90% of the way there in <200ms.

The 'custom ranking' is inspired by how expert developers navigate codebases: they don't read every file, they infer from structure. /services/stripe/webhook.handler.ts is obviously the webhook handler—no need to embed it.

The innovation is removing unnecessary work (content reading, chunking, embedding) and proving that simple heuristics are faster and more deterministic.

So this basically competes with fzf?

https://junegunn.github.io/fzf/

so pretty close to how jetbrains ranks files in their search?

Actually, I haven't used JetBrains, didn't know they did something similar until now!

This came from a different angle I read about how the human brain operates on ~20 watts yet processes information incredibly efficiently. That got me thinking about how developers naturally encode semantics into folder structures without realizing it.

The "cognitive" framing is because we're already doing the work of organizing code meaningfully Mantic.sh just searches that existing structure instead of recreating it as embeddings. Turns out path-based search is just efficient pattern matching, which explains why it's so fast.

Interesting to hear JetBrains converged on a similar approach from the IDE side though!