In most cases it seems (at least to me and colleagues) to be turning out that picking best intelligence is a better option than picking better intelligence / dollar, assuming you can afford the cost. At least on interesting problems. If you’re doing generic web dev work, probably not the case.
What are interesting problems? Deepseek and some other open source models do decently well in the gpu kernel benches. https://kernelbench.com/hard Most people think they’re working on “very hard” problems and they really aren’t
Absolutely agree with this. As Louis Rossmann recently pointed out, it's the difference between a correct answer and a wrong answer; the correct answer is worth a good amount, while the wrong answer is worth nothing. Under this metric, for harder tasks, the most intelligent model is best per dollar.
That's why experience + cost effective model is IMO the best combination.
Experience allows you to design the skeleton where the implementation details are often inconsequential. There are relatively few scenarios where an LLM would need more guidance to render an outcome, but even dumb local models can do that.
Building a simple UI component vs an efficient multi-threaded bidirectional socket implementation (both examples of things I did recently with DeepSeek flash).
Angular can only be written in one way so the UI was trivial. I know the architecture for the socket implementation and the trade offs for various approaches, so I sketch out the implementation and get DeepSeek to complete it (error handling, keepalive messages, timeouts, etc).
I don't think I would have saved much time if I just asked Fable to "make the socket implementation" but even if it got it right the first time, it would have only saved me a few minutes given that's how long it took to write any way.
Even in more conventional applications, Node.js / React CRUD applications - "write a graphql query for blah" "add an endpoint to run query" "add validation to endpoint" are all trivial for DeepSeek flash. In most of these cases, I have found you're constrained by context window size because these are rarely well architected applications.
> Experience allows you to design the skeleton where the implementation details are often inconsequential.
Expanding on this thought a little more: it is possible to set up scaffolding that make incorrect implementations inconsequential. If the LLM can detect when the implementation is wrong, it can retry with the errors feeding back into the loop. This is shored up by up-front investments in tests, API definitions, strong types, linting rules, etc. the various cheap, fast Flash models do not need to 1-shot solutions if capable of autonomous reiteration.
This is a great point. In the past this is how I learned to architect software in general as you are never the only contributor and often must accommodate the contributions of contributors who are early in the careers. Good software architecture reduces the damage possible by low quality contributions.
I have had great success with contract driven development workflows in this regard.
LLMs being effectively very knowledgeable jr engineers, slot right into those patterns.
Another interesting thing is that Rust _really_ shines with LLMs. The compiler gives very helpful messages which the LLM bounces off very effectively. If it compiles, it works, you just need to double check the logic is correct.
By contrast, with something like Go, you'd need to be on the lookout for nil pointers, race conditions and so on. Node.js / TypeScript is less dangerous, but you still have memory leaks that aren't possible in Rust and lack pattern matching so must be vigilant about type discohesion.
This is mostly true and a month ago I would have agreed wholeheartedly. However, there are still situations where almost every line of code has to be deliberately chosen in a delicate way. Think research code or settings which demand a high degree of optimization. Opus or GPT-5.5 are absolutely miserable to guide in these settings.
"Well, don't use an AI for those purposes!"
That used to be true (and is now again true I suppose). Fable was a peek at something different, it seemed to be actually able to start to tackle these kinds of problems. That saves a lot of time, since checking these programs is often far, far easier than writing them. Experience is needed to check and scaffold still, but something like Fable becomes a prerequisite for these settings.
People are wasting tokens with perfectly fine models by not planning effectively. Anyone who says Opus is not capable of doing what Fable can probably are not planning effectively and just praying to the one shot gods.
What fraction of your work is "interesting problems", and what field do you work in?
> If you’re doing generic web dev work, probably not the case
I have a feeling the bulk of most people's work is "generic $X work." My take is people should figure out their mix of interesting vs boring work, and optimize accordingly. Flash models also tend to much faster,
Yep. After moving Deepseek for a long time I also moved to Mimo 2.5 pro. It's not only similarly cheap, but it's very good with 1m context window and gigantic tasks. Produces very lean code.
