Rethinking search as code generation
1zael
69 points
20 comments
June 02, 2026
Related Discussions
Found 5 related stories in 99.8ms across 9,294 title embeddings via pgvector HNSW
- The future of code search is not regex – 100x faster than ripgrep neogoose · 14 pts · April 02, 2026 · 60% similar
- Show HN: Semble – Code search for agents that uses 98% fewer tokens than grep Bibabomas · 261 pts · May 17, 2026 · 53% similar
- Research-Driven Agents: When an agent reads before it codes hopechong · 161 pts · April 09, 2026 · 52% similar
- Using AI to write better code more slowly signa11 · 405 pts · May 25, 2026 · 52% similar
- Embarrassingly simple self-distillation improves code generation Anon84 · 582 pts · April 04, 2026 · 50% similar
Discussion Highlights (8 comments)
anthonypasq
I found this approach very interesting and was wondering if it could be applied to grep-based search for coding agents to increase speed and reduce LLM turns, but the part im not quite understanding is how the model will know enough about the codebase to construct a complicated multi-stage search pipeline based just on the prompt. Maybe this is just different from web search, but it seems like the model needs sequential tool calls to know where to look next, and coding agents have already put in a lot of work to encourage parallel tool calling.
AgentMasterRace
How does this compare to something like cocoindex-code? That indexes your code for semantic searches.
metalliqaz
What kind of tool does one use to create flowchart graphics like these?
esafak
Is there a need for this over simply providing a rich enough search API?
10000truths
Sounds like the goal here is to augment search with a sort of query language . One that's more structured than a mere list of keywords? Ribbing aside, the "rethinking" here sounds a lot like an AI-specific spin on the "bring the code to the data, instead of data to the code" paradigm. I imagine that the same multitenancy caveats of allowing arbitrary user-defined queries against a relational database (execution limits, access controls, etc.) will apply here as well.
vicentereig
It’s funny how many agentic things decompose into a DSPy RLM with specialized tools, although the tools here do the heavy lifting.
dopatraman
Perplexity still exists?
nitwit005
It feels like there will be some hard to deal with customer support issues related to limits. The generated Python code is unlikely to always run queries in an optimal way. Normally you'd tell your customer they need to fix their code if they're doing something inefficient, but here, they didn't write the code and are presumably not expected to understand it.