Don't Ask AI "What Do You Think?"

LLMs are Simulators, Not Entities

Recently, Andrej Karpathy shared an interesting perspective:

Don't think of LLMs as "entities", think of them as simulators. For example, when exploring a topic, don't ask:
"What do you think about xyz?"
There is no "you." Try this instead:
"What group of people would be good at exploring xyz? What would they say?"

LLMs can simulate various perspectives, but they've never actually sat down and "thought about" anything for a long time.
When you force the "you" pronoun onto them, they simply adopt and simulate a specific persona implied by their fine-tuning data.

The Missing First Step

I had been feeling a similar kind of frustration while working with AI.
Here's what we usually ask AI:

"What do you think of this code?"
"Is this design okay?"

The AI answers right away. It's fast, but sometimes it goes in a totally unexpected direction. You end up with something that "works, but it's hard to explain why it was done this way."

The problem is that you have no idea what criteria it used to answer.

• Did it look at it from a performance perspective, or a maintainability perspective?

• Did it prioritize a quick fix, or did it consider long-term scalability?

A senior engineer's core competency is the ability to clarify ambiguous problems. Without explicit instructions, AI skips this step entirely. And without criteria, there is no validation.

How This Differs From Existing Approaches

You might think "suggesting a perspective" isn't exactly new. In AI agent design, the "Socratic Mentor" persona (a guide who draws out answers through questioning) is already widely used.

However, Socratic maieutics and the approach I'm proposing have different premises:

Maieutics assumes that "the answer is already inside you." This new approach makes no such assumption. Instead, it says, "Here are some options you might not have known existed."

There's a well-known asymmetry in cognitive psychology: recognition memory is more efficient than recall memory. This is why multiple-choice questions are easier than fill-in-the-blanks.

Asking the Question Before the Question

When you go to an optometrist, the optician doesn't ask, "What do you want to see?"

"If you look through this lens, it looks like this. If you look through that lens, it looks like that. Which one would you like to use?"

They show you the lenses first, let you choose, and then show you the world through that lens.

Prothesis (πρόθεσις) is a framework that applies this very principle to AI collaboration.

• Prothesis = Greek for "a setting forth" or "placing before"

• Presents possible perspectives first, before answering

• Once the user chooses a perspective, it analyzes through that lens

This is the "question before the question."

Unknown Unknowns → Known Unknowns

There is a frequently mentioned classification in decision-making research:

• Known Unknowns: You know what you don't know → You can ask questions about it

• Unknown Unknowns: You don't even know what you don't know → Asking questions is impossible

The core role of Prothesis is converting Unknown Unknowns into Known Unknowns.

If you didn't know "what perspectives are available to look from," you were in a state where you couldn't even ask. The moment Prothesis presents those perspectives, you realize, "Ah, there's this way of looking at it too," and you finally have choices to make.

Of course, the 2–3 perspectives the AI suggests won't cover every single possibility. But it's a huge improvement over starting from scratch. At the very least, it allows you to ask, "Are there any other perspectives besides these?"

This is fundamentally different from traditional AI collaboration methods:

• Traditional: AI provides an answer, and the human accepts or rejects it

• Prothesis: AI shows the space of possibilities, and the human chooses the path

How It Works

The flow of Prothesis goes like this:

요청 → 관점 제시 → 선택 → [병렬 분석] → 종합 → 최종 렌즈

• Request: Vague request (you know the goal but not the method)

• Perspective Suggestion: Presents 2–3 possible analytical perspectives

• Selection: The user selects perspectives (1 or more)

• Parallel Analysis: Simultaneously explores using the chosen perspectives

• Synthesis: Aggregates the results

• Final Lens: Points of convergence, divergence, and integrated evaluation

Why Parallel?

The problem with sequential analysis is context poisoning. The conclusion from Perspective A influences the analysis of Perspective B.

Sequential: A → B → C (A가 B를 오염, B가 C를 오염)
Parallel: A ∥ B ∥ C (각 관점이 독립적으로 판단)

Parallel analysis guarantees independence for each perspective. And when independent analyses reach the same conclusion, that makes for a robust finding.

A Real-World Example: Production Incident Analysis

The API server in our EKS (AWS Kubernetes Service) cluster became unresponsive. It was detected via Synthetics monitoring alerts. This happened two days in a row around the same time, and we couldn't pinpoint the cause.

Symptoms: A flood of 499 errors, requests hanging until timeout in a CNI unhealthy state, and Karpenter spinning up more nodes than necessary

What Each Perspective Saw — And Missed

Each perspective explicitly states its blind spots (Horizon Limits). This is exactly why other perspectives are necessary, and it forms the very foundation for parallel analysis.

Convergence and Divergence

When you aggregate the analysis results, you get two things:

Convergence (where all 4 perspectives agree):

Divergence (differences between perspectives):

If this had been a sequential analysis, it would have been poisoned by the "race condition" framing from the infrastructure perspective, entirely burying the "deterministic trigger" insight from the SRE perspective.

Because it was a parallel analysis, divergent points surfaced, and these shaped the direction of our further investigation. This is the heart of Prothesis.

In the example above, the only thing I did was "select." Yet, from this single step, you gain:

1. Explicit judgment criteria: You know exactly why it answered the way it did

2. Verifiability: You can check if it makes sense from that particular perspective

3. Conversational direction: Follow-up questions proceed within that same lens

Getting Started

Claude Code Plugin

If you install the epistemic-protocols plugin, you can use the /prothesis command right away:

claude plugin add https://github.com/jongwony/epistemic-protocols

Usage: Type /prothesis before making a request, or switch to the mode. When the AI suggests perspectives, you simply select one.

You can check the full protocol in the repository.

Criteria for Use

Situations that need Prothesis:

• Evaluation requests like "What do you think?" or "Is this okay?"

• Complex judgments where multiple perspectives are valid

• Situations where you need to verify the AI's response

Situations where Prothesis is unnecessary:

• Factual questions with clear-cut answers

• Requests where you've already specified the perspective ("Look at this from a performance standpoint")

• Simple execution requests ("Write tests for this function")

Prothesis isn't a previously known methodology. I designed it stemming from the frustrations I felt while collaborating with AI.

Motive

Many engineers work in a plan-and-execute cycle within agent workflows. Whenever I collaborated with AI, I always found myself having to follow up with, "Is that from that perspective?" or "What about from another angle?"

The perspective selection was being handled implicitly. I wondered what would happen if we made this step explicit — and that was my starting point.

Tools

Claude Code's distinguishing features, the AskUserQuestion and Task (Subagent) tools, allowed me to implement this flow naturally:

1. AskUserQuestion — Presents structured options and waits for the user's response
2. Task (Subagent) — Performs parallel analysis using the selected perspectives

The entire "Suggest Perspectives → Select → Parallel Analysis → Synthesis" flow ended up working seamlessly.

Wrapping Up

In an era where AI answers instantly, speed is no longer a scarce resource.
What has become scarce is understanding.

Prothesis is an attempt to preserve understanding from an expert's perspective during the planning phase. By having the AI ask "Which lens should we look through?" before giving an answer, we can:

• Convert Unknown Unknowns into Known Unknowns

• Make our judgment criteria explicit

• Obtain verifiable answers

I used infrastructure incident analysis as an example in this post, but you can apply this to a variety of domains from the viewpoint of "seeking advice from an expert in a field I don't know much about."

To be honest, I'm no expert in epistemology or philosophical concepts.
Prothesis is simply an experiment where I tried to structure the pain points I felt during AI collaboration in my own way.
I'm continuously improving it as I use it, and I'd love to develop it further alongside feedback from domain experts.

The plugin also includes the Syneidesis protocol for the execution phase. I plan to cover that in a separate post.

Ask the question before the question. The AI will give you a better answer.