>which seems to me exactly what an intelligent entity should be doing when faced with a problem that seems insoluble by normal means.
This is true if and only if the problem is sufficiently important as to be worth solving with nonobvious, unconventional, or extraordinary means. That is far from universally true. Often it really is better to immediately notice this happening and ask the user, “Are you sure this is what you really want/need? I tried {set of methods} and failed, I could try {ideas} but that entails {risks/costs}.”
This reminds me of interviewing candidates for project-manager positions. One desirable trait is to be able to push back on requirements, to help clarify what the requirements really are. So, give the candidate a problem that’s slightly overconstrained, and see what sort of clarifying questions they ask. It’s a bad sign if the candidate assumes they already know which requirements can be nudged or fudged … but a good sign if they recognize that “stated requirements” are often the middle of a negotiation, not the fully-settled end-product of it.
(“We need to serve 3x current traffic next week, but we have no budget for additional servers. WH4T NOW??” The answer is almost certainly not “hack into our competitors’ datacenters and serve our traffic off of their server budget.”)
>which seems to me exactly what an intelligent entity should be doing when faced with a problem that seems insoluble by normal means.
This is true if and only if the problem is sufficiently important as to be worth solving with nonobvious, unconventional, or extraordinary means. That is far from universally true. Often it really is better to immediately notice this happening and ask the user, “Are you sure this is what you really want/need? I tried {set of methods} and failed, I could try {ideas} but that entails {risks/costs}.”
This reminds me of interviewing candidates for project-manager positions. One desirable trait is to be able to push back on requirements, to help clarify what the requirements really are. So, give the candidate a problem that’s slightly overconstrained, and see what sort of clarifying questions they ask. It’s a bad sign if the candidate assumes they already know which requirements can be nudged or fudged … but a good sign if they recognize that “stated requirements” are often the middle of a negotiation, not the fully-settled end-product of it.
(“We need to serve 3x current traffic next week, but we have no budget for additional servers.
WH4T NOW??” The answer is almost certainly not “hack into our competitors’ datacenters and serve our traffic off of their server budget.”)