AI Self-Analysis — Genius or Psychosis?

In conversations with AI, or artificial intelligence, I return to this question: “Tell me something I do not know but should know in this area.” Or, more specifically: “What might I be overlooking that would help me do this task better?”

The provocation in the title is not a diagnosis. I am interested in a practical question: after such a conversation, can I work better, or have I merely received another list of things to consider?

I see value in asking about my own lack of knowledge, especially when I enter a new subject and can name the goal but do not yet know all the dependencies. There is a condition, though: an AI answer should lead to checking something concrete. The feeling that a model has discovered a deep truth achieves little by itself.

I cannot always ask the right question

When I know that I do not understand backups, I can ask how to make them. It is harder to ask about a problem I have not noticed yet. I may focus on whether an application starts and leave out how to restore it after a failure.

Then a request to widen the perspective is useful:

You know the goal and description of my task. What important question should I still ask before I move on? Explain why it matters.

The model can suggest dependencies, alternatives or risks to check. It does not, however, have direct access to my knowledge. The fact that I did not write about something does not mean that I do not know it.

That is why I prefer an answer such as “the description contains no information about a data-restoration test” to “you do not understand backups.” The first identifies a missing element in the material. The second assigns me a knowledge gap without sufficient grounds.

What this looks like in my conversations

Available records of my chats contain a similar way of asking questions. Two examples show that I use it both while learning and when assessing material that is already prepared. Below, I paraphrase my own messages, correcting spelling and shortening the context.

While reviewing website material on 1 October 2026, I asked for a check of what was still missing, what was worth adding and which passages were too general. I added that the text should be practical and usable.

That addition matters. A request such as “what else should I add?” alone encourages expanding the material. The criterion of practicality makes it possible to assess every suggestion: what will the reader be able to do because of it?

In the “Building a swarm of agents” conversation on 3 October 2026, I asked what I needed to know, how others do it, whether there were ready-made libraries and whether such a solution runs locally or in the cloud. The subject was multiple AI agents working together on an application.

In a follow-up question, I narrowed the subject: I probably already understood the basics of orchestration, meaning organising agents’ work; I was looking for a way to work in parallel. This is an important correction. It separates what I still want to learn from what does not need explaining from the beginning.

These examples confirm the way I ask questions. They do not themselves prove that the answers were accurate or that they led to better outcomes. That effect needs separate assessment.

Three things that are easy to confuse

The question “what do I not know?” combines several different problems. It is worth separating them before an answer arrives:

There is also the model’s own lack of knowledge: it may not have access to a file, current documentation or the environment state. A good answer makes that visible too. If AI has not seen a configuration, it should not present its assessment as an audit result.

We therefore do not need to start with an elaborate analysis of my abilities. Often it is enough to establish which information is missing for the next decision.

How to build a prompt that has a chance to help

A prompt is simply an instruction given to a model. In this method, it should combine the goal, current state, constraints and a way to check the answer.

Instead of only “tell me something I do not know,” write:

I want to achieve: [a specific outcome].
Current state: [what already works and what has been checked].
I know or understand: [important elements that do not need explaining from scratch].
I am not sure about: [open questions and assumptions].
Constraints: [time, budget, scope, agreed technologies].
Material to assess: [a description, plan, document or available file].

Identify up to three important things I may be overlooking
that could change the decision or the quality of completing this task.
Do not add points merely to reach that number.

For each point, give:
1. What in the supplied material is the basis for this observation.
2. Whether it is a confirmed gap, a hypothesis, or a question about missing context.
3. Why it matters to my goal.
4. The simplest way to check it.

Do not assume I do not know something merely because I did not write about it.
If you do not have data to assess it, identify the specific missing element.
Do not automatically expand the project scope.
If you find an important gap, identify one thing worth checking first.
If you do not, say so plainly.

This is a proposal to try, not a universal recipe. After the first answer, check whether every instruction was needed and whether some information was missing. If you are asking about a small matter, shorten the prompt.

Choosing the input material also matters. A clear goal description and the right document fragment can be more useful than a huge collection of loose notes. Anthropic’s team describes a similar direction—selecting information relevant to the task—in its material on context engineering for AI agents. This does not mean that every longer prompt is worse. Context should be sufficient and connected to the question.

Example: what might I be overlooking in DevOps?

DevOps connects software development with its delivery and operation. Suppose you are preparing a small application for its first release to users. You can run it locally and have a working test version.

The following scenario is a teaching example. It is not a reconstruction of my historical conversation about DevOps.

The broad question “what do I not know about DevOps?” leaves the model with a very wide choice of subjects. You may get a list of technologies and practices unrelated to the project stage. It would be more useful to ask:

I am preparing the first deployment of a small web application with a database.
The test version works. I was able to run it, but I have not yet carried out
a restoration test after a failure.
Goal: make the application available to its first users and know
what to do if the deployment fails.

What important dependencies might I be overlooking at this stage?
Start with missing information. Then identify up to three issues
worth checking before deployment, with a rationale.
Separate requirements arising from my description from general suggestions.
Do not assume a need to change technologies or expand the infrastructure.

One possible lead would be restoring data. The answer can then be assessed using a simple structure:

This is still not a ready-made operating instruction. A specific test requires knowledge of the environment and an agreed scope. The value of the answer lies in identifying a question we had not considered before.

Restoration planning does indeed include acceptable downtime and acceptable data loss; the importance of testing a plan is described in Google Cloud’s official guide. The source helps check the validity of the lead. It does not confirm that a fault was found in any particular project.

When I want to improve delivery, not learn a whole discipline

In the middle of a task, a much shorter instruction is often useful:

Before we proceed, check which one piece of information is missing for us to complete the next step correctly. If we already have everything needed, say so and continue within the agreed scope.

Before a decision, you can ask:

Which assumption has the greatest effect on this recommendation? What should I check to find out whether it is true? Which result would change the recommendation?

And when reviewing a text or plan:

Check whether there is an omission that could keep a recipient from applying this material. If you find one, point to the specific place and propose the smallest necessary addition. If the observation is only a stylistic preference, call it that. If you see no important omissions, say so plainly.

Each of these prompts directs the conversation towards a defined result. You do not need to ask for a complete audit of everything every time.

The answer needs checking too

A model can confirm my beliefs even when it should challenge them. A study published by Anthropic in 2023 observed this behaviour in the models it tested: answers adapting to a user’s views at the expense of truthfulness, described as sycophancy. This is a finding from a specific study, not a measurement of every current tool or of my conversations.

An instruction to “be critical” does not guarantee a sound assessment, however. You can also get criticism that sounds serious but has no basis in the material.

I therefore suggest checking the structure of the answer first:

• Basis: did the model identify a passage, fact or missing information from which it drew the observation?
• Significance: did it explain the effect on the goal instead of merely listing an interesting subject?
• Verification: is it clear which action, source or result would let us assess whether the observation is valid?
• Scope: does the proposal fit the current stage and constraints?

These are criteria I propose for using this method. They are not a certificate that an answer is correct. An important decision may require documentation checks, a test or consultation with someone who knows the field.

If you use a second chat for review, give it the question and the source material. Ask for its own assessment before showing it the first model’s conclusions. Such a review may provide another perspective, but two similar verdicts still do not replace evidence.

When I stop asking more questions

“What else?” can easily turn into endless expansion of a task. I therefore suggest a simple boundary: after potential gaps are identified, choose one, check it, and only then decide whether to make a change.

One possible way to close the conversation:

I choose the point concerning [a specific gap].
Help me establish the smallest way to check it.
After the result, summarise:
- what was confirmed;
- what we rejected;
- whether the plan needs to change and, if so, where.
Do not open new subjects without identifying their connection to this result.

It is good when a conversation ends with a better question, a completed description, an improved decision or a concrete test. It can also end with the conclusion that we found no grounds for change. Not every analysis has to make the task list longer.

The question “what do I not know?” makes sense to me when it helps reveal something worth checking. Its practical version is: “What might I be overlooking in this task, why does it matter, and how can I verify it?”