Admitting I Don't Know in the Age of AI

I found the idea for this article while reorganizing my Kindle notes.

Highlights from four different books kept circling the same subject. Sapiens connected modern science with the willingness to admit ignorance. Geniale treated questions and curiosity as the beginning of discovery. The Black Swan described our habit of believing that we understand more than we do. 21 Lessons for the 21st Century returned to the ability to recognize failure and try a different path.

I had saved those passages at different times and for different reasons. Read together, they sounded less like notes about science or history and more like a description of my current work with AI.

For years, “I don’t know” felt like a temporary gap. It was something to move past quickly before getting to the useful part: the answer.

Now answers are abundant. I can ask an AI assistant for an explanation, a plan, a piece of code, a diagnosis, or ten possible directions and receive something convincing in seconds.

That changes the value of the answer. It also changes the value of admitting that we do not yet have one.

Answers became cheap

Before generative AI, producing a polished technical answer required effort. I had to remember it, research it, test it, or ask someone with more experience. The cost of producing the answer gave it a certain weight.

That weight was never proof that the answer was correct, but at least there was friction.

AI removed much of that friction. This is one of its best qualities. It helps me explore unfamiliar code, turn rough thoughts into plans, compare approaches, and get moving when an empty page would otherwise stay empty.

The same property creates a new problem. A model does not need to know that an answer is true to make it sound finished. OpenAI describes hallucinations as plausible but false statements, and its research argues that common evaluation methods often reward guessing instead of acknowledging uncertainty.

The problem is easy to understand because humans respond to similar incentives. If every question is treated as a test, silence feels like failure. A confident guess at least has a chance of being rewarded.

In software work, the polished wrong answer is often more dangerous than the unfinished one. It can enter a design document, become a task, turn into code, pass through review, and survive until reality finally disagrees.

The illusion of understanding

Nassim Nicholas Taleb calls attention to the stories we build after events have happened. Once we know the outcome, the path toward it looks cleaner and more predictable than it was for the people living through it.

Software has its own version of this illusion.

After a bug has been found, its cause can look obvious. After an architecture has succeeded, its design can look inevitable. After an incident, the missing alert or unsafe assumption is suddenly easy to name.

Before the outcome, we were moving through incomplete information, old decisions, hidden dependencies, and constraints that were not written down. The real system was messier than the story we later told about it.

AI can intensify this tendency because it is exceptionally good at producing a coherent story. Give it a stack trace and it can explain the failure. Give it a repository and it can describe the architecture. Give it a proposed change and it can justify the direction.

Any of those explanations may be useful. Coherence, however, is not evidence.

This is the point where “I don’t know” stops being an admission of defeat. It becomes a boundary marker between what the available evidence supports and what still needs to be inspected.

Questions are part of the work

One of the notes I kept from Massimo Polidoro’s Geniale was about the courage to ask questions even when doing so risks making us look foolish.

That risk is familiar in technical work. A meeting moves quickly. Everyone seems to understand the acronym, the constraint, or the reason behind an old decision. Asking for clarification can feel like slowing the group down.

AI creates a different version of the same temptation. The assistant has already produced a plan. The plan is detailed. The headings are tidy. It would be easy to approve it and start working.

The useful questions usually begin where the plan sounds most certain:

• Which parts came from the repository and which are assumptions?
• What did we inspect, and what did we infer from naming or convention?
• Which external facts may have changed since the model was trained?
• What evidence would show that this diagnosis is wrong?
• Which decision is difficult to reverse?
• What remains unknown because the necessary information is not available here?

These questions do not block progress. They decide where progress is safe.

Science as a willingness to be corrected

The idea that stayed with me from Sapiens was not that science possesses a larger collection of facts. It was that modern scientific practice made room for ignorance.

That distinction matters. A fact can become outdated. A theory can fail. A result can resist reproduction. A useful method of inquiry must survive those events without treating them as personal humiliation.

Harari returns to a similar theme in 21 Lessons for the 21st Century: progress depends on the willingness to recognize failure and try another route.

This is close to the best version of software development I know. We form an idea, make it concrete enough to test, observe the result, and update our understanding. The code is not proof that the original idea was right. It is one way to question the idea using a real system.

AI fits well into that loop when I treat its output as a proposal. It fits poorly when I treat the first complete response as the end of the investigation.

What changed in my work

I have already written about how AI agents are making me a better programmer. They force me to make goals, constraints, and acceptance criteria more explicit before implementation begins.

There is another side to that change: I also have to make uncertainty explicit.

When I delegate a task to an agent, I now care about several different kinds of statements:

• facts observed in the code or documentation;
• inferences that connect those facts;
• assumptions made because some context is missing;
• decisions based on my preferences or risk tolerance.

Mixing these categories produces false confidence. Keeping them visible gives me places to intervene.

For an unfamiliar task, a useful instruction can be as small as this:

Before proposing the change:

1. State what you verified in the repository.
2. Separate evidence from inference.
3. Name assumptions that could change the solution.
4. Explain how the result will be checked.

This does not guarantee a correct answer. It improves the shape of the conversation. A mistake attached to an explicit assumption is easier to find than a mistake hidden inside fluent prose.

The same discipline helps when the agent is correct. I can understand why the solution is justified instead of trusting it because the response looked professional.

Good delegation includes doubt

I once thought delegation meant giving someone a clear description of the work. That is part of it, but clarity can be misleading when it hides unresolved questions.

Good delegation also says:

• this is what we know;
• this is what we think;
• this is what matters if we are wrong;
• this is where you should stop and ask;
• this is the evidence we need before calling the work complete.

This applies to people as much as agents. The difference is that an AI system can produce an answer so quickly that there is little time for uncertainty to become visible on its own. We have to ask for it.

The NIST Generative AI Profile uses the term confabulation for confidently presented false or erroneous content. It treats the problem as something to manage across the lifecycle of an AI system, not as an embarrassing edge case that will disappear if we wait for a better model.

That framing feels practical. I do not need AI to be infallible before it can be useful. I need a workflow that assumes errors are possible and makes important claims cheap to challenge.

A better division of work

AI is very good at expanding a small input into many possible directions. It can summarize, compare, reorganize, translate, propose, and repeat without becoming tired of the process.

My responsibility is different. I decide which question deserves attention, which source can be trusted, which risk matters, and when a plausible answer has earned the right to influence the real system.

Admitting “I don’t know” belongs to that responsibility.

It keeps a question open long enough to inspect the evidence. It gives another person permission to disagree. It lets an agent ask for context instead of inventing it. It turns verification from an accusation into a normal part of the workflow.

The sentence does not end the work. Used well, it starts the honest part of it.

References and related reading

• Sapiens: A Brief History of Humankind by Yuval Noah Harari, particularly its discussion of ignorance and the Scientific Revolution.
• 21 Lessons for the 21st Century by Yuval Noah Harari.
• The Black Swan by Nassim Nicholas Taleb, on uncertainty, hindsight, and the limits of explanation.
• Geniale by Massimo Polidoro, on curiosity, questions, and creative inquiry.
• Why language models hallucinate by OpenAI, on evaluation incentives that reward guessing over uncertainty.
• Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile by NIST, including its treatment of confabulation as a generative AI risk.
• AI Agents Are Making Me a Better Programmer for the personal context behind this reflection.