131–140 of 188 posts
So this is just delegating certain work to dumber models? I certainly wouldn't use Gemini 2.5 Flash (!!?) for code writing as suggested. I've never had an issue with Codex or Claude reading massive files, they're really good at precise greps.
Am I missing something? Unless you have infinity money, would it not be very stupid to pay for "precise greps?"
Earlier quoted context omitted.
The spotify desktop app is one of the worst pieces of software by a major company I have ever used.
I timed how long it took to open Spotify and play a song on a $2500 Mac on low latency gigabit fiber internet. 15 seconds. Incredible stuff.
I wonder if the macOS build has a bunch of static libraries it has to load first.
What great productivity gains are Spotify achieving in making their product worse?
The spotify desktop app is one of the worst pieces of software by a major company I have ever used.
Earlier quoted context omitted.
> I've never had an issue with Codex or Claude reading massive files Reading files isn't a problem they want to solve. The idea seems to be using a cheaper model to "scout" for the intended code, instead of an expensive one that reads all the things (and spends more tokens / thinks about them). I think this might be useful because Opus 5 especially tends to over-read. So this looks like an "LLM Bloom filter", telling…
I have a stage-gated workflow that prioritizes “premium” token efficiency (Fable.) and getting the most out of my subscription services. (Which boils down to Fable running carefully prompted deepseek-flash agent teams that defer back to the managing agent for any design decisions in most work.) As part of that workflow the manager uses cheap reconnaissance agents to burn their tokens in order to build relevant repo c…
Earlier quoted context omitted.
> I've never had an issue with Codex or Claude reading massive files Reading files isn't a problem they want to solve. The idea seems to be using a cheaper model to "scout" for the intended code, instead of an expensive one that reads all the things (and spends more tokens / thinks about them). I think this might be useful because Opus 5 especially tends to over-read. So this looks like an "LLM Bloom filter", telling…
I have a stage-gated workflow that prioritizes “premium” token efficiency (Fable.) and getting the most out of my subscription services. (Which boils down to Fable running carefully prompted deepseek-flash agent teams that defer back to the managing agent for any design decisions in most work.) As part of that workflow the manager uses cheap reconnaissance agents to burn their tokens in order to build relevant repo c…
This is a Claudism, right? I feel like I never saw "gated" used this way before it.
The Bloom filter framing is right. What made it work for me: the cheap model is only allowed to point, never to decide. Once it stopped judging anything and just returned file paths and line ranges, the quality complaints disappeared. The expensive model still does all the reading that matters, just on 10% of the bytes.
Unlike an actual Bloom filter (which does not return false negatives), the cheaper model is still trusted to correctly recognize synonyms, equivalent functional constructions etc. One is strictly a performance optimization, the other is a speed/quality tradeoff. It might well be a very good one, but it’s a tradeoff nevertheless. The framing is misleading.
It takes true corporate dedication to publish technical thought leadership on a page that actively fights your ability to read it.
What great productivity gains are Spotify achieving in making their product worse?