What Is Discovery For? If the Machine Finds the Answer, Who Learns the Question?

Last week on LinkedIn, Mike Walsh asked a short but unsettling question: What is discovery for?

The backdrop is a debate in the world of mathematics. As Walsh tells it, OpenAI announced that it had solved the Millennium Prize Problem on the Navier-Stokes equations by running around 10,000 AI agents for more than fifty hours. Terence Tao and 25 Fields Medallists objected, calling it a “severe misalignment”. Their objection was not to the correctness of the answer but to what was left out: when people solve a problem, they produce not only an answer but also ideas that can be taught. When a machine hands over the answer and moves on, those ideas may never be born.

Walsh connects this to an old observation of Poincaré’s: even if a superior mind existed, we could not use it; we could only use our own. That sentence held true for a century. It no longer does. We can use the superior mind. So understanding is no longer something that simply happens; it has become a choice.

Reading the piece, I did not think of mathematics. I thought of ERP projects.

In the field, discovery is called “analysis”

I have been working on ERP and manufacturing projects since 1996. In that time I have seen one thing again and again: the mistake that costs an ERP project the most is not badly written code. It is solving the wrong problem correctly.

Whenever I list the reasons ERP projects fail, the most expensive one is always the same: needs and goals that were identified wrongly. That is why, in process consulting, we say you need to understand the process before you buy software. The analysis phase is a project’s discovery phase. Its output looks like a document, but its real output is the shared understanding that forms in the minds of the customer and the consultant.

In a good analysis meeting, nobody knows the answer. The planner does not know why stock is piling up, sales does not know why delivery dates are missed, finance does not know why costs are drifting. You get somewhere by asking question after question, filling in the bones of an Ishikawa diagram, working your way to the fifth of the “five whys”. By the end of that journey, everyone in the room understands their own work a little better. Only then does the project move.

Now we have a machine that shortens that journey.

The machine gives the answer; the question is still ours

I live this every day while developing Kai. A user types “which ten products sold best this month?”, Kai generates the SQL, and the result is on screen in seconds. For someone who used to wait weeks for a report, that is a genuine relief.

But the truly valuable question comes next: Why is last month’s product missing from this list? The machine does not ask that. The person who asks it knows the sales channel, or a customer’s ordering habits, or a stoppage on the shop floor last month. The answer can come from the machine. Knowing what to ask comes from the person who knows the work.

There is a detail in Walsh’s piece I did not want to miss. Even in that ten-thousand-agent effort, human researchers decided which paths got the resources. So even at the helm of the greatest computing power there is still judgment. And what feeds that judgment is problems that were once solved first-hand.

Scrum has a name for discovery: the spike

In my note on agile project management I wrote about the spike. A spike is a time-boxed piece of research set aside to reduce uncertainty. Its most important property: its output is not working software, it is learning. If at the end of the sprint the team can say “we tried this, it doesn’t work for this reason, that path is better”, the spike has succeeded.

AI can shorten a spike. It can show in minutes rather than hours how an integration might be built or how an API behaves. The danger starts here: if learning shrinks as the spike shrinks, the time we think we have gained is actually lost. The team starts from scratch on the next similar problem, because it learned nothing the first time. It just copied the answer.

DMAIC has the same discipline. Define comes before Measure; if you start collecting data before you have pinned down the CTQ, you end up precisely measuring the wrong thing. Machines measure better than we do. Deciding what is worth measuring is still our job.

Why we say “the engineer approves” in KaiDraw

KaiDraw analyses SOLIDWORKS parts and proposes descriptions and classes according to the company’s own standard. Technically, those proposals could be written straight into PDM. We deliberately do not do that. The proposal comes from the machine; the approval comes from the engineer.

The reason is not only the risk of error. With every approval and every correction, the engineer gets to know their own standard a little better. They see what counts as a “bolt” and what counts as a “stud”, which part is genuinely new and which is a copy of an old one. Remove the approval and the machine will still give the right answer, but the engineer will become a stranger to their own product structure. Five years later, nobody in that company will be able to defend the standard.

That is exactly the design question Walsh puts to leaders: arrange the collaboration between people and machines so that it develops judgment rather than erodes it.

Brought down to the shop floor: five habits

If I adapt Walsh’s framework to ERP projects and manufacturing companies, these are the habits I would recommend:

  1. Write down your hypothesis before you ask the AI. Even a single line like “I think the excess stock comes from these three products” is enough. When the answer arrives, compare it with your guess. The gap is what you have learned.
  2. When machine and person disagree, treat it as data, not as an error. Kai gave a figure, the planner said “that can’t be right”. Either the query is wrong or the model in the planner’s head is. One of them will be corrected, and both are valuable.
  3. Reward the person who spots the wrong problem. The one who says “actually, that’s not the problem” in a meeting is the person who saves the project the most money. Make that visible.
  4. Keep the reasoning, not just the answer. An organisation that does not write down why a decision was made will repeat the same discovery every five years. A machine can reproduce the answer; it cannot reproduce the context of that day.
  5. Teach junior consultants the “why”, not the “how”. Machines can now show how something is done. The consultant who knows why it is done that way is the only one who can judge the machine’s suggestion.

Those who missed the Renaissance

Some time ago I wrote “Those who missed the Renaissance are missing Human 2.0 too”. There, I saw the danger as failing to keep up with technology. Walsh’s piece reminded me that the danger has another face: keeping up with technology perfectly and handing our thinking over to it.

What made the Renaissance the Renaissance was not a multiplication of answers. It was a multiplication of the questions people were able to ask. AI brings us an unprecedented abundance of answers. Whether that abundance turns into the next Renaissance or into a comfortable forgetting depends on how we use those answers.

In my own work the test is simple: if, after a system goes live, the customer’s team understands its work better than before, the project has succeeded. If it only does the work faster, we are halfway there.

What is discovery for? I believe it is not for finding the answer, but for developing the people who can ask the next question.

How do you strike this balance in your team? Since AI arrived, does your team understand its work better, or does it just do it faster?

This post takes Mike Walsh’s What Is Discovery For? as its starting point.