Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rethinking search as code generation

research.perplexity.ai

Post reply on HN
Print view View original

1–10 of 22 posts

Re: Rethinking search as code generation

#3

Post by 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.

Re: Rethinking search as code generation

#4

Post by 1zael »

anthonypasq wrote: post #3

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 sequent…

Yeah I think this maps onto grep-based code search well. Right now agents grep, read the results, grep again, and every hit lands in context. This architecture turns that into one program: fan out the greps, filter and dedupe in the sandbox, hand back only what matters. The "won't know the codebase" worry flips around too. The first program shouldn't be "find the bug," it should be "build me a map" (grep the file tree, import graph, symbols). That needs zero prior knowledge, then the model plans the real search over that map. So it's less about replacing sequential exploration and more about making each grep step way wider without flooding context

Re: Rethinking search as code generation

#6

Post by aszen »

anthonypasq wrote: post #3

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 sequent…

Coding agents prefer to do iterative search, I have yet to see them create a complex search script. They try different search cmds in parallel, evaluate their results and then refine or dive deeper.

This approach usually works great but I can see many use cases where a smarter search strategy may make sense especially to optimize context.

Re: Rethinking search as code generation

#7

Post by aszen »

1zael wrote: post #4
anthonypasq wrote: post #3

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 sequent…

Yeah I think this maps onto grep-based code search well. Right now agents grep, read the results, grep again, and every hit lands in context. This architecture turns that into one program: fan out the greps, filter and dedupe in the sandbox, hand back only what matters. The "won't know the codebase" worry flips around too. The first program shouldn't be "find the bug," it should be "build me a map" (grep the file tre…

Claude code already fans out and sandboxes context by calling sub agents so I'm not sure this approach brings much benefit there. A complex search strategy only makes sense if the search is slow and compute intensive.
Post reply on HN