3 ms·
Because the LLM is faster at typing the input, and faster at reading the output, than I am... the amount of input I have to give the LLM is less than what I hav
by gpm 1y ago
Because the LLM is faster at typing the input, and faster at reading the output, than I am... the amount of input I have to give the LLM is less than what I have to give the search tool invocations, and the amount of output I have to read from the LLM is less than the amount of output from the search tool invocations.
To be fair it's also more likely to mess up than I am, but for reading search results to get an idea of what the code base looks like the speed/accuracy tradeoff is often worth it.
And if it was just a search tool this would be barely worth it, but the effects compound as you chain more tools together. For example: reading and running searches + reading and running compiler output is worth more than double just reading and running searches.
It's definitely an art to figure out when it's better to use an LLM, and when it's just going to be an impediment, though.
(Which isn't to agree that "context engineering" is anything other than "prompt engineering" rebranded, or has any staying power)
- skydhash 1y agoSo instead of building better tool, we're patching the last one with another tool that is not even reliable, just using it faster. That reminds me of the first chapter in "The Programmer Brain" by Felienne Hermans. There's an explanation there that confusion when reading code is caused by three things: - Lack of knowledge: When you don't have the faintest idea of the notation or symbol being used, aka the WHAT. - Lack of information: When you know the WHAT, but you can't figure out the WHY. - Lack of processing power: When you have an idea of the WHY, but can't grasp the HOW. We already have methods and tooling for all the above and they work fine without having to do shamanic rituals.