The Value of Not Knowing

AI is making it easier to find answers. I'm increasingly interested in what happens to the process of finding them.

I recently read The Year Math Changed Forever, a fascinating article by Rivka Galchen in The New Yorker about Terence Tao and the growing role of AI in mathematical discovery.

AI systems are beginning to solve problems that mathematicians have worked on for decades. Some of these results are genuinely impressive. Others are less significant than they initially appear. But the broader trend seems clear: mathematical problem-solving is becoming increasingly accessible to machines.

What interested me most is a concern raised by Tao.

Mathematics has always involved more than finding correct answers. The process of working through a difficult problem, exploring unsuccessful approaches, developing intuition and eventually discovering a new connection is part of what makes mathematics valuable.

What happens when we can skip much of that process?

I've spent much of my career building software, working with AI and trying to make complicated things easier.

At Askdata, we wanted people to interact with data without needing to understand SQL or the technical details underneath. Today, with Cyberwave, we're working to make it easier for developers and agents to interact with the physical world.

A recurring motivation in both cases is to reduce the distance between an intention and its execution.

If someone wants to understand their business, they shouldn't need weeks of technical preparation to ask a question of their data. If a developer wants a robot to perform a task, they shouldn't need to rebuild the entire integration and control infrastructure.

I still believe deeply in that idea.

But there is a distinction I've been thinking about more recently.

Some complexity is accidental. It exists because our tools are poorly designed, our systems are fragmented, or we've made something unnecessarily difficult.

Other complexity is intrinsic to the problem we're trying to understand.

Eliminating the first is progress. Eliminating the second can sometimes mean eliminating an opportunity to learn.

Teaching AI at LUISS has made this distinction particularly visible to me.

One of the things I enjoy most about teaching is that preparing a lecture forces me to understand a subject differently.

I can read a paper and feel reasonably comfortable with its argument. But when I have to explain the same idea to students, I quickly discover the gaps in my understanding.

Why does this technique work? Under which assumptions? What would happen if we changed one of them?

Sometimes the simplest questions require the most thought.

Today, an LLM can generate a clear explanation of almost any topic in seconds. It can produce examples, simplify equations and adapt an explanation to different levels of knowledge.

That's extraordinary. I use these tools constantly, and I think they have enormous potential in education.

But understanding an explanation and developing the ability to arrive at one are different things.

A student can read a perfectly written explanation of gradient descent without developing much intuition.

The same is true in software engineering.

You can generate a working implementation without understanding the decisions that make it reliable. That might be completely fine if the goal is to solve an immediate problem.

It becomes more complicated when the goal is to develop the ability to solve the next problem.

This is where I find Tao's concerns particularly interesting.

Historically, becoming a mathematician required spending years working on problems that other people might already have solved, or struggling with questions that ultimately led nowhere.

That work wasn't wasted.

It developed intuition, taste and the ability to recognize promising directions.

AI changes the economics of that process.

If a difficult mathematical proof can be generated in minutes, asking a student to spend weeks working on it may start to feel inefficient.

But perhaps efficiency is the wrong measure.

I see a similar tension emerging in software development.

A young developer can now create applications that would previously have required substantial experience. I think that's wonderful. More people can build things, experiment with ideas and become entrepreneurs.

At the same time, I wonder how the next generation will develop the intuition that experienced engineers acquire through debugging, designing systems and dealing with unexpected failures.

Some of that intuition may simply become less necessary. We shouldn't romanticize every difficult task just because previous generations had to perform it manually.

But some knowledge is difficult to separate from the experience of acquiring it.

You learn something by building a system that breaks in production. You learn something different by reading an explanation of why that system might break.

Both are useful. They are not interchangeable.

There is another consequence that interests me even more.

When answers become inexpensive, deciding which questions are worth pursuing becomes increasingly important.

Scientific research has always involved selecting problems under uncertainty.

Researchers have limited time and resources. Choosing a promising question is itself an intellectual achievement.

AI could change this dramatically.

Imagine a mathematician who can explore hundreds of conjectures in the time previously required to investigate one.

That creates extraordinary opportunities. Ideas that once seemed too speculative or expensive to pursue become accessible.

But it also creates a new problem: how do we decide what matters?

Producing a thousand valid proofs doesn't necessarily produce a thousand meaningful discoveries.

A result might be mathematically correct without opening a useful direction for further research. Another might seem modest but introduce a technique that changes an entire field.

This distinction reminds me of building companies.

Writing software has become progressively easier throughout my career. AI is accelerating that trend enormously.

Yet I don't think deciding what to build has become correspondingly easier.

If anything, the expanding range of possibilities makes judgment more important.

When almost anything can be prototyped quickly, the challenge is no longer simply whether you can build something.

It's understanding why it should exist.

I don't think the right response is to deliberately make learning, research or software development more difficult.

Artificial constraints rarely produce better thinking.

And I don't subscribe to the idea that using AI somehow makes an intellectual achievement less meaningful.

Throughout history, we've developed tools that extend our cognitive abilities. Calculators, programming languages, search engines and scientific instruments have all changed which activities require human effort.

AI is part of that history, even if its scope is much broader.

What concerns me is something slightly different.

We may become so accustomed to obtaining answers that we lose interest in the experience of not knowing.

Yet uncertainty is often where curiosity begins.

I still remember the early days of building Askdata, when an idea that seemed straightforward would turn into weeks of experimentation. Some approaches failed. Others revealed problems we hadn't anticipated.

Looking back, those moments were not merely obstacles between us and a finished product.

They shaped how we understood the problem and, eventually, what we decided to build.

I wouldn't want to repeat every frustrating technical challenge. But I also wouldn't want to have missed everything those challenges taught me.

Perhaps that's the distinction we need to preserve as AI becomes more capable.

There are problems we want machines to solve for us.

And there are problems we should continue working through ourselves, not because machines cannot solve them, but because the experience changes how we think.

I suspect the difficult part will be knowing the difference.