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.