Models are loosely a compression of all the easily accessible human knowledge (obviously this depends on their training corpus and parameter size etc.), so they have pretty much every software pattern stuffed in them. If you were to ask a colleague “what pattern should I apply to this problem?” they can only point you towards the patterns they are aware of. That colleague will hopefully also be able to communicate their motivation for choosing that pattern, either as a practical choice (it scales well) or a matter of taste (it makes sense). Now, you may disagree that their proposal makes sense. After all, everyone has their own unique perspective that is informed by their skill level, domain of expertise, and aesthetic alignment.
There is a phrase in photography that goes like:
The best camera is the one you have on you
The idea is that it doesn’t matter that one-hundred megapixel medium-format cameras with the dynamic range of the human eye exist. Even if you are about to shoot fashion portraits in the midday sun to be printed on a billboard (where all of those camera stats would matter), if the only thing you have on you is an iPhone, well that’s the best camera. You cannot use a camera you don’t have, thus it doesn’t matter what is objectively “the best”. The crux is to stop worrying and not regret what “might have been”, instead focusing on “what is”.
To that aim, it doesn’t matter what software patterns are “the best” for your application. You need to understand the code you and the Model are writing together. This means that the best is not limited to what the model has in its weights (all cameras that exist), it’s limited to what you are capable of understanding (what you have on you). If you ask it for “the best” and you choose something you do not fully comprehend, you are no longer in control of the direction of your code. If something breaks, you likely will not understand what could have gone wrong.
Because engineering is largely about understanding a problem space and finding the Pareto Front solution, the point at which you no longer comprehend your project is the point at which you are no longer engineering. If you offload comprehension to your Model, then it’s no longer your project, it’s the Model’s project.
Don’t just ask the Model “what is the best choice here” and pick what it says. Explore different options with it – use this as a learning opportunity! If you are able to understand its recommendation after some back and forth, then sure, maybe it is the right approach.
So among a few options, don’t just choose the one that the model says is best, choose what you are able to understand as the best.