Skip to content
Artificial Intelligence

Intelligence and Wisdom in AI: Choosing the Right Problem

How do you choose a worthwhile problem for AI and check whether the result helps? A manufacturing perspective, practical method and seven-question checklist.

P-01NeedOptionsVerificationUseful outcomeP-01NeedOptionsCheckOutcome
Topic-specific editorial illustration

We can ask AI for an interface draft, a calculation script or a long list of tasks. The question that interests me is which need the result actually meets.

In machinery manufacturing and mechanical assembly, a part has to be considered alongside how it will be made, how it fits with other parts and what people will need when using it. I bring that perspective to AI-assisted development. Does the result make the user's work easier?

The short answer: Value in AI-assisted problem solving comes from choosing a worthwhile need and checking the output against that need. A useful starting point is to state whose work should improve, the constraints and how you will verify success.

Where intelligence and wisdom come in

In this article, I use intelligence to discuss the ability to develop solutions, and wisdom to discuss how we weigh the goal, its costs and its consequences. The distinction makes two questions easier to see:

  • How could we do this?
  • Is this worth solving right now?

The second question sometimes takes more thought. A feasible feature may do little for the user's actual problem. We may speed up one task by shifting the checking work to someone else. Building a new tool may be less useful than removing an ambiguity in an existing document.

People can choose the wrong problem too. We can ask AI to challenge our goal, identify assumptions and suggest simpler options. Our working experience brings context to the discussion; a model can help us explore different approaches. We remain responsible for judging whether the result is suitable and deciding how to use it.

Put the problem into one sentence

“I want to add AI to my work” expresses an intention. For a problem statement that can guide the work, I suggest completing this sentence:

[Person] encounters [specific difficulty] while doing [task]. We will consider a solution useful if [observable outcome] improves.

For example: “The person assembling the product has to keep checking the drawing to identify similar-looking parts. We will consider a solution useful if it reduces the time needed to find a part without increasing incorrect matches.”

That definition leaves room for different solutions. A clearer parts list, a well-placed label or a small program might be enough. Start by understanding the current method: How often does the problem occur, who is affected and how do they handle it today?

AI can help prepare interview questions, organize notes and compare options. A problem we have not observed should remain an assumption to investigate.

A hypothetical manufacturing example: Reducing assembly confusion

Imagine a product assembled from sheet-metal panels. Some parts look similar, and it is difficult to see where each one belongs or which should be joined first. This is a hypothetical scenario to explain the method. It is not a report of an implemented project or a measured improvement.

The initial request might be “Build me an automated assembly application.” I would first describe a narrower need: use approved parts lists and drawings to prepare a marking system that helps people distinguish parts during assembly.

The constraints should be clear from the start:

  • Each part identifier must correspond to exactly one part in the approved list
  • A marking must be readable at the relevant assembly step; if it should be hidden on the finished product, a suitable inner surface must be selected
  • Bend angles and directions must come from verified technical data, with missing information flagged explicitly
  • The proposed assembly order must account for access and the conditions in which the work will be carried out

AI may help draft labels from the supplied information or write a script to check the list. Comparing identifiers and detecting missing records is one task. Establishing whether the physical parts can actually be bent and assembled requires its own checks.

I would start with a small assembly group. First, record how parts are found using the current method. Then try the proposed system under comparable conditions. Alongside search time, record incorrect matches, repeated checks and the time needed to prepare the labels. If preparation consumes the time saved during assembly, we need to see that.

Before use in production, the responsible person should also verify the marking method, material, drawing and equipment conditions. A promising small trial does not establish that the same result will hold for every part or assembly.

How to check a convincing answer

Generative AI can present incorrect information confidently, including faulty explanations or citations. NIST's generative AI risk profile discusses this under “confabulation.” NIST AI 600-1, section 2.2

Choose the checking method to match the output:

  • Information: Open the source. Does it support the claim, and are its date and scope appropriate?
  • Calculations: Check inputs and units, then independently reproduce the calculation
  • Code: Run a test. Include missing, invalid and unexpected inputs alongside valid ones
  • Drawings or manufacturing files: Compare dimensions, orientations and connections with the authoritative technical source, and plan any required physical validation
  • Workflows: Observe the person using the result. Count preparation and review time as part of the total effort

Asking the same model “Are you sure?” may help uncover an omission. For an independent check, return to a source, calculation, test or observation.

The NIST AI Risk Management Framework also emphasizes measurements suited to the conditions of use, documented testing and continued checks during operation. The following checklist is my practical starting point for this article, rather than a formal compliance checklist. NIST AI RMF, section 5.3

Seven questions to answer before starting

  1. Whose work will improve? Identify the person who will use the result and the task they perform
  2. What evidence supports the problem? Point to an observation, an example file or a recurring error
  3. What is the simplest option? Could the existing method, a checklist or a small change be sufficient?
  4. What are the constraints? Record budget, time, data privacy, safety and the tools already available
  5. What will we compare success against? Record the current situation and the quality that must be maintained
  6. Who will verify the output, and how? Identify the source, test and person responsible
  7. When will we continue, change direction or stop? Set a stopping condition in advance if verification costs outweigh the benefit or a critical error cannot be resolved

You do not need a definite answer to every question. An unanswered question can become the subject of the next small investigation or trial. That gives uncertainty a specific place in the work.

A starting request you can give AI

“I want to improve this task for this person: […]. The problem I have observed is: […]. The current method and examples I have are: […]. My constraints are: […]. My success criterion is: […]. First, identify assumptions and missing information in my problem statement. Compare no more than three approaches, including one that does not require AI. Suggest the smallest useful trial, a verification method and a stopping condition. Do not invent measurements or results I have not supplied.”

Start with examples you are authorized to share, without unnecessary personal or confidential business information. Read the response and correct something specific: Which condition is missing, which assumption is wrong or which result cannot be checked?

This is where the distinction between intelligence and wisdom becomes useful to me: connecting the ability to develop a solution with a worthwhile goal and an observable result. Thinking with AI can include the whole process: framing the question, considering an objection, trying an approach and changing direction when needed.

For an example of presenting source code alongside test records, you can explore my open-source work. Software tests, digital designs and physical applications each need to be assessed within their own scope.

Sources

Let’s discuss

If you have a similar requirement, let's define the scope together.

I review the request and come back with a proposed approach and scope.

Back to all articlesGet in Touch