Earlier quoted context omitted.
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.
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.
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.