It’s easy to believe: a big model usually writes more confidently, knows more patterns and explains the solution more nicely. It seems all that’s left is to pick “the smartest one”.
But model size doesn’t replace the context of the task.
If it wasn’t given the database schema, access rules, answer format and real examples, it will confidently fill in the gaps. Sometimes a small model with good documentation search and a clear answer template is more useful than a big one that was told “figure it out yourself”.
It’s like hiring a strong engineer and not showing them the blueprint, the budget constraints and the existing wiring. Qualifications matter. So does the brief.
In practice I look not only at the quality of the answer but at the whole system:
— where the model gets its facts;
— which actions it’s allowed to take;
— whether the result can be checked;
— how costly a mistake is.
A big model is worth using where there’s a lot of ambiguity: design, complex analysis, working with heterogeneous text. For repeatable operations a good process often matters more than maximum model intelligence.
Don’t choose a model instead of designing the system.