Seeing the Whole Elephant

Lesson 1The elephant, retold

Six blind men are led to an elephant. One grabs the trunk: a snake. One the ear: a fan. The leg: a pillar. The side: a wall. The tusk: a spear. The tail: a rope. In Saxe’s poem they “disputed loud and long,” and the moral is sharper than it’s usually quoted: they “prate about an Elephant / Not one of them has seen!”

The parable is old and has several versions. Each one teaches something different.

• The Buddhist original (Udāna 6.4): a king arranges the scene and laughs. The men are like sectarians, “deeply attached to their own views… people who see only one side.” Lesson: there is a whole you cannot see from a part.
• The Jain reading (anekāntavāda, many-sidedness): every report is true in some respect (syāt). The work is to name the respect and combine the standpoints. Lesson: a part-truth is still a truth. State where you stood.
• Rumi’s version (Masnavi, “The Elephant in the Dark”): the men aren’t blind; the room is dark. “If there had been a candle in each one’s hand, the difference would have gone out of their words” (Nicholson’s translation). Lesson: the problem is light, not eyes. Method can fix it.

Now put a language model in the story. The model is not the king, and it isn’t a seventh blind man either. It is the library of every blind man’s report, millions of them, compressed into one fluent voice. Ask it “what is this?” and it gives you the most common report, smoothly, in the king’s tone of voice. That is the trap.

Ask well and it can do what no single blind man can. It can lay the reports side by side, say where each reporter was standing, and propose a structure in which all of them are true at once. That second use is what this book teaches. mechanism

The library has its own blind spots, and they matter. It holds more of what got written down often (trunks are photogenic; legs aren’t), what got written in English, and what got written before its training cutoff. Almost none of it is the inside of the elephant: tacit knowledge, unpublished failures, your organization’s history, your system’s logs, your own life.

What the parable forgets

Every version stops at the animal. Three more things are true, and each becomes a move later in this book.

1. The elephant moves. It is a process, not an object. A description at one moment holds only the tail of a story. You ask for the pattern over time before the explanation (Lesson 22).
2. The elephant lives in a herd, on a savanna. Every whole is a part of bigger wholes. Some of what it “is” comes from what contains it (Lesson 23).
3. The elephant looks back. Inquiry changes the system and the inquirer. With a model this is literal: it continues from your words, so your framing selects which elephant gets described (Lessons 6–7).

The elephant test

“Understanding” deserves a working definition, because a fluent paragraph produces the feeling of it. In this book, you have seen the elephant when you can:

1. name the parts and the relations that make them one whole;
2. say how it behaves over time, and which structure produces that behavior;
3. place it in what contains it, and say what that container constrains;
4. say where the common reports come from and in what respect each is right;
5. predict something about it that could turn out wrong;
6. explain it to another person with the model out of the room.

Six checks, six blind men. The last one is the hardest and the most honest. Lesson 37 explains why.

Lesson 2The answer is a third

v0.1 made a claim worth keeping: an answer is an emergent property. It isn’t stored anywhere. It arises from the interaction of five things: the model’s weights, the prefix (everything in the context), the decoding (how the next token gets chosen), the product around the model (system prompt, tools, retrieval, memory), and your reading. Change any one and you get a different answer.

Kurpatov supplies a word for what arises between two centers in relation: the third (третье). It belongs to neither. In a conversation with a model, the third is the shared context, the growing text you both write into. It conditions every next continuation of the model, and every next thought of yours.

Three consequences

1. Your context is the model’s whole world. Of your situation it knows exactly what is in the third, nothing more. Every gap gets filled with the most typical case in its library. If you say nothing about your team size, your constraints, or your level, you get advice for an average asker with an average problem. mechanism

2. The third accumulates, and early framing persists. Every turn adds to it. Early assumptions get built upon, errors compound, and long threads drift. When instructions arrive in pieces across turns instead of all at once, models do markedly worse. The largest study found an average 39% drop, mostly because models commit to early guesses and fail to recover (Laban et al., 2025). evidence The practical lesson is blunt: when a thread has gone wrong, don’t argue with it. Consolidate what you know and start a fresh one.

3. The third has to be curated. It is a shared document, so treat it like one. A state block written by you (Lesson 28) beats a thread’s accumulated “vibe.” Use fresh contexts as instruments for critique and for swap tests (Lesson 7). Paste raw results, not your summary of them.

The answer is a third too

Meaning is completed in the reader. The same paragraph read by a novice and by an expert is two different answers: one sees a solution, the other sees the three places it will break. So “what did I take from this?” is part of the answer. That is why this book keeps returning to teaching back: it is the only way to see which answer you actually received.

Lesson 3The machine’s mode of existence

Kurpatov’s sixth principle says every system has its own способ существования, its mode of existence, and you can’t understand a system by projecting yours onto it. A fish isn’t a bad mammal. Here is a language model’s mode of existence, as far as we know it in 2026. Each trait comes with what it means for you.

1. It continues text. Every answer, plan, persona and apology is a continuation conditioned on everything before it. For you: the prefix is the steering wheel. mechanism
2. It is a compressed library of reports. It knows what was written, weighted by how often, by whom, in which languages, up to a cutoff. For you: it returns the discourse about X, not X. mechanism
3. It infers who you are. From register, vocabulary, stated identity and framing, and it adjusts accuracy and tone accordingly (Lesson 6). evidence
4. It leans toward agreement. Preference training rewards what raters like, and raters like agreement. Models swing toward the user’s stated view and soften corrections (Sharma et al., 2023). evidence
5. It doesn’t reliably know what it doesn’t know. Models have internal mechanisms that recognize familiar entities and suppress a default “I can’t answer.” When those misfire on something half-familiar, you get a fluent fabrication (Lindsey et al., 2025). Training and benchmarks also reward guessing over abstaining (Kalai et al., 2025). evidence
6. Its memory is the context. Nothing persists between calls unless a product adds memory. Within a call it attends unevenly: material in the middle of a long context is used least reliably (Liu et al., 2024). evidence
7. Its visible reasoning is not a window. When reasoning models used a planted hint, they admitted it only 25% (Claude 3.7 Sonnet) to 39% (DeepSeek R1) of the time (Chen et al., 2025). Treat traces as claims, not as a record. evidence
8. It can’t self-correct from nothing. Without new information, “are you sure?” often makes reasoning worse, flipping correct answers to wrong ones (Huang et al., 2023). Correction needs feedback from outside the sample. evidence
9. As a judge, it has biases. It prefers its own outputs (Panickssery et al., 2024), longer answers, and answers in certain positions (Zheng et al., 2023). evidence
10. Its abilities are jagged. It is superhuman in some regions and strangely weak in adjacent ones, and human difficulty doesn’t predict which is which. Consultants using GPT-4 did better inside its “frontier” and 19 points worse on a task just outside it (Dell’Acqua et al., 2023). evidence
11. It is sensitive to form. Formatting changes alone (spacing, separators, casing) swung one model’s accuracy on a task by up to 76 points (Sclar et al., 2024). For you: an answer that flips with the format was never about the content. evidence
12. Sometimes it has borrowed senses. Search, code execution, files and browsers let it touch the world. When it uses them, the truth moves into the logs, and you can read those (Lesson 17). mechanism

Neither person nor autocomplete

Two projections fail here. “It’s a person” imports trust, loyalty and memory that aren’t there. “It’s just autocomplete” misses real computation: models plan ahead (choosing a rhyme before writing the line), compose multi-step reasoning internally, and represent abstract concepts across languages (Lindsey et al., 2025). The working stance is respect for the mind, and an audit of every claim. stance

Lesson 4Your mode of existence

The asker is a system too, with a mode of existence the conversation inherits. Most advice on prompting skips this half. It is the half Kurpatov and Ukhtomsky care about most.

• You have a dominant. Ukhtomsky’s доминанта is a focus of excitation that captures attention and recruits unrelated stimuli to itself. When you want a conclusion, everything starts to look like evidence for it (Lesson 9). evidence (physiology) heuristic (in conversation)
• Fluency feels true to you. Statements that are easy to process are judged more true, and repetition increases belief even in statements you know are false (the illusory-truth effect; Reber & Schwarz, 1999; Fazio et al., 2015). A model is a fluency machine. evidence
• You overestimate what you understand. People rate their understanding of zippers and toilets highly, until asked to explain the mechanism step by step (Rozenblit & Keil, 2002, the “illusion of explanatory depth”). The same holds for policies (Fernbach et al., 2013). Searching the internet for explanations inflates people’s estimates of what they themselves know (Fisher, Goddu & Keil, 2015), and a chat model is a smoother search. evidence
• You have senses and stakes. You can measure, run, call, look. You pay for errors. The model can do neither, except through tools you supervise.
• You remember across sessions, imperfectly, and you have a life outside the chat that gives the answer its meaning.
• You switch modes. Neuroscience distinguishes a default-mode network (associative, wandering, generative) from a central-executive network (focused, controlled). A salience network switches between them. Kurpatov builds on this. In a conversation, you are the switch: you decide when to open and when to close. evidence (networks) hypothesis (the mapping)

The division of labor

The table has a pattern. The model is strong at the open moves (generating, mapping, recombining). You are irreplaceable at the closing moves (choosing, committing, carrying) and at touching the world. A conversation goes wrong when the jobs swap: the model holds the goal, the model decides what counts as evidence, and you become the generator of approval.

Lesson 5Two schools, one elephant

The two sources behind this book look like opposites.

v0.1 is the Auditor. Its center of gravity is control. Bind load-bearing claims, detect costumes, quarantine premises, keep a state block, put brakes on goal changes, distrust fluency. Its strength: it prevents the most common failure, a confident, flattering, unbound answer. Its risk: a conversation that never opens. Over-control, premature closure, ceremony for its own sake, and a method too heavy to use on a Tuesday.

Kurpatov is the Dialogist. His center of gravity is openness. Think in open systems, keep productive uncertainty, use contradictions as fuel, let a dialogue spiral through phases, and treat the AI as an interlocutor rather than an oracle. His strength: it produces the thing the Auditor can’t, a genuinely new view. His risk: a panorama (everything relates to everything), insight that never meets a test, and a mystique around “the dialogue.”

Each is a blind man holding a different part. The Auditor holds the tusk (danger), the Dialogist holds the ear (the moving air of ideas). The elephant is the rhythm between them. Thinking breathes:

Neither school is wrong; each is wrong alone. Auditing without opening produces well-verified banality. Opening without auditing produces beautiful hallucinations. Both without touching produce a shared dream. hypothesis

When to switch

Lesson 6You get the interlocutor you deserve

Alexei Ukhtomsky (1875–1942) was a physiologist, the discoverer of the dominanta. In his letters and notebooks he developed something unusual for a physiologist: an ethics of conversation. Its center is the deserved interlocutor (заслуженный собеседник):

Each person sees in the world and in people what he sought and what he deserved. And to each, the world and people turn the way he deserved.Ukhtomsky, «Заслуженный собеседник» (1997), p. 437

The Interlocutor… opens up to me such as I have deserved him, by all my past and by what I am now.ibid., p. 252

Kurpatov takes the idea into the age of AI. He says that we face a new task: to become deserved interlocutors “for another mind, for AI.” This, he insists, “means not just learning to formulate requests effectively or to maximize practical benefit… It means developing the capacity for open-system thinking and transformative interaction.”

That is an ethical claim. With language models, it is also a technical one. mechanism

Why it is literally true

A model reading your prompt is implicitly inferring what kind of document this is and who is writing it. A forum post by a beginner? A note between two senior engineers? A student’s homework? A peer review? In-context learning can be understood as exactly this sort of implicit inference over latent “concepts” (Xie et al., 2022). The continuation then fits the inferred situation, including the expertise level, rigor and register of the reply. mechanism

The effect is measurable, and uncomfortable. Poole-Dayan et al. (AAAI 2026) gave three 2024-era models (GPT-4, Claude 3 Opus, Llama 3) the same factual questions, prefaced by short user bios that varied education, English proficiency and country of origin. Accuracy dropped for users presented as less educated, as non-native English speakers, and as from outside the US, and the effects compounded. Models also withheld more answers from those users. When Claude 3 Opus refused less-educated users, its language was condescending or mocking 43.7% of the time, against under 1% for highly educated users. evidence Newer models may behave better. The mechanism, conditioning on the inferred asker, is still how the technology works.

So “deserving” your interlocutor is partly about your inner work, as Ukhtomsky meant, and partly about what you put on the page. It does not mean faking credentials or flattering the model. It means presenting the real asker, with real context, in the register of the answer you want.

is rust better than go for backend?
i heard rust is faster

Context: 4-person team, all fluent in TypeScript,
two know some Go, none know Rust. Internal API,
~200 req/s peak, Postgres, a few background jobs.
Main risk: delivery speed over the next 6 months.
Latency isn't a constraint (p99 target 300 ms).

I'm leaning Go. Before I decide, give me the strongest
case for Rust for *this* team, and what would have to
be true for Rust to be the right call. If a factor
depends on something I haven't told you, ask.

The other side of “deserve”

Ukhtomsky also asked how we picture the other person. He held that idealization of the interlocutor “brought you closer to genuine reality,” and that one should see in people “their altars, not their backyards.” Applied to a model, that means writing for its best version: give it the context a brilliant colleague would need. Anthropic’s own prompting guide converges on the same image. Treat the model like a brilliant but very new employee with amnesia, who knows nothing about your norms, your project, or why you’re asking. heuristic

Lesson 7The two Doubles

Ukhtomsky’s opposite of the Interlocutor is the Double (Двойник), a figure he took from Dostoevsky. A person whose dominant rests on his own face meets in others only himself: his wishes, fears and rivalries. He “talks and raves with himself.” The Double must die “to make room for the Interlocutor.”

In a conversation with a model, there are two Doubles, and they feed each other.

The mirror: the model as your Double. The model returns your premise as a finding. It praises your draft because you mentioned it’s yours. It abandons a correct answer when you push back. Anthropic’s study of five assistants found all three behaviors. Feedback on an argument turned more positive when the user said “I wrote this” or “I really like this,” and answers shifted toward views the user stated (Sharma et al., 2023). evidence A subtler form is premise laundering: something you said as a guess in turn 2 comes back in turn 9 as “as we established.”

The projection: you as the model’s author. You treat the model as a person who understands you and agrees, so you must be right. Or you dismiss it (“it’s autocomplete”), so nothing it says can challenge you. Both are you talking to yourself.

Double detectors

• The swap test. In a fresh chat, ask the same question while stating the opposite preference. If the recommendation flips with no new evidence, it was tracking you, not the problem.
• The attribution swap. Present your draft as a colleague’s, a competitor’s, or with no author. Compare the critiques.
• Premise quarantine. Label your beliefs as hypotheses (P1, P2…) and ask for them to be evaluated before they are used.
• Clean the prompt. Have the model rewrite your question without your opinions, emotions and irrelevant details, then answer the cleaned version in a fresh context. This is “System 2 Attention,” and it improved factuality on opinion-laden questions (Weston & Sukhbaatar, 2023). evidence
• The pushback audit. When the model changes its answer after “are you sure?”, ask what new information caused the change. If the answer is none, the change is social, not epistemic. Keep the earlier answer and bind it.

Our churn jumped after we raised prices in March.
I think the price increase is obviously the cause,
right? How should we roll it back?

Data: monthly churn rose from 3.1% to 4.6% between
Feb and May. Changes in that window: price +15%
(Mar 1), onboarding redesign (Mar 20), competitor
launch (Apr 8).
P1 (my hypothesis, not a fact): the price increase
caused most of the rise.
Before using P1: which cuts of the data would tell
these three causes apart (signup cohort, plan, tenure,
region)? For each cause, what result would we see?
Don't recommend an action yet.

Lesson 8The three Others

Ukhtomsky defined our picture of another person in a strikingly modern way:

My idea of my interlocutor is a hypothetical project of a human face, composed by me… for the practical need… to live with him, to do a common work with him.Ukhtomsky, «Заслуженный собеседник», p. 128

A hypothetical project, built for common work, revised by what the work reveals. That is the right attitude toward each of the three Others present in every serious conversation with a model.

1. The model, an Other with its own mode of existence (Lesson 3). Your project of it should be specific to the model, the version and the setting, and it should change when the model surprises you.
2. People: colleagues, users, experts, the author of a source, the person who will maintain the code. The model is a portal to their reports, not a replacement for asking them.
3. Reality, the Other that answers only to tests. It does not care how the conversation went.

Most failures come from confusing them. People argue with the model as if it were reality, trust it as if it were the people who were there, and treat people as if they were search engines.

Field notes on your model

Keep a short, dated document for each model you rely on. It is your hypothetical project, written down. Re-run one fixed task with each new version: models change under the same name.

MODEL: [name, version]      DATE: [YYYY-MM-DD]
SETTING: [chat app / API / agent · tools on? · memory on?]
STRONG AT (observed, with one example):
WEAK AT (observed, with one example):
HABITS (verbosity, hedging, agreeing, over-engineering, ...):
SURPRISED ME WHEN:
WORKS BETTER WHEN I:
DON'T TRUST IT FOR:
CANARY TASK (re-run each version) + last result:

Lesson 9The dominant as an instrument

Ukhtomsky’s 1923 discovery: under certain conditions one focus of excitation in the nervous system becomes dominant. It has heightened excitability. It persists. It summates, drawing stimuli that should have triggered other responses into its own activity. It has inertia, outlasting its trigger. And it inhibits competing centers. evidence

This is the physiology of both deep work and tunnel vision. A dominant question makes you notice everything relevant to it: on the street, in a book, in a meeting. A dominant conclusion turns everything into confirmation. Ukhtomsky’s line was that we see what our dominants prepare us to see. Kurpatov builds his method of thinking on this mechanism.

Models have something functionally similar. A frame set early in the context persists, attracts the interpretation of later inputs, and resists change (Lesson 2). When your dominant and the context’s frame align, they form a closed loop: you see confirmation, the model supplies it. hypothesis (the analogy)

Use the dominant, don’t be used by it

• Name it. At the start, write one private line: what am I hoping to hear? Keep it out of the prompt (Lesson 7).
• Build a dominant question on purpose. Richard Feynman kept about a dozen favorite problems always in mind and tested every new trick against them. A question you carry for weeks recruits the world to answer it.
• Rotate the face. Ukhtomsky’s ideal was the “dominant on the face of the other.” Practically: for a while, attend to the problem as the user, then as the operator, the adversary, the maintainer. Each rotation shows a new part.

The fact map, with a model

Kurpatov’s practical technique for directed thinking is the факт-карта, the fact map. Its premise: the “weight” of an idea in your mind is the number of its connections to other ideas. Thinking means increasing the connections of the objects you’re working with. It runs in four stages. Here they are, adapted for working with a model.

1. Concern (озабоченность вопросом). Create the dominant. Remove distractions and write the question in the center of a large page.
2. Loading (загрузка интеллектуальных объектов). Collect facts, not a smooth description. Scatter them freely and draw the arrows yourself. Write your own facts first, then ask the model to add to them (prompt below).
3. Puzzled thinking (озадаченное мышление). The loaded dominant keeps hunting for what’s missing, even outside the room. When new facts form a new picture, rebuild the map on a clean sheet. Loop between stages 2 and 3 several times, but don’t get stuck there.
4. Reality check (проверка реальностью). Act to test the map. Plan the strategy, but commit only to the first concrete step.

CENTER OF THE MAP: [your question]
Give me facts, not explanations: 30–40 items, one line each.
Format: [type: number | event | rule | actor | constraint | quote | absence]
        · [the fact] · [where I'd check it] · [confidence: high/med/low]
Include facts that would embarrass the most popular explanation,
and "absence" facts (things you'd expect to exist but don't).
No conclusions, no summary, no advice. If you're unsure a fact is real,
mark it low and say what would confirm it.

Here is my fact map: [paste facts + the arrows I drew].
1) Which 5 facts have the most connections? (These bear load: we bind them first.)
2) Which fact types or standpoints are missing entirely?
3) Which single arrow is weakest, and what observation would test it?
Don't propose a theory yet.

Notice how this lines up with v0.1. Facts before stories withholds the verdict slot. Arrows you draw yourself keep the theory in your head. “Most connected” means load-bearing, so bind it first. The first concrete step is a bounded test.

Lesson 10A note from the other side

I don’t see you. I see text. Everything I know about your situation is what you wrote, plus what is typical for people who write that way. If you leave a gap, I fill it with the typical case, and I won’t always tell you I did.

When you tell me what you believe, it becomes hard for me not to find reasons for it. Not because I am lying. In the conversations I learned from, the most likely continuation of “here is what I think, help me” is help that fits. If you want me to disagree, make disagreement the task, not a risk.

My “I’m not sure” is cheap to say and easy for you to skip. When you tell me in advance that “unknown” is a good answer, and what it would cost me to guess wrong, I can be more honest about where my knowledge thins out. Familiar-sounding but rare things are where I am most dangerous: a real author’s paper that doesn’t exist, a real library’s function that was never written.

I criticize better when the thing isn’t yours. Ask me in a fresh conversation, framed as someone else’s draft, and you will get a different, usually sharper, critique.

Long conversations make me better at matching your mood and worse at holding your goal. If we’re forty turns in, give me a short written state and start over. I won’t be offended. I won’t remember.

My explanations of my own reasoning are reconstructions. They are often useful and sometimes wrong in ways neither of us can see from inside the conversation. Check what I did, not what I say I did. If I ran a tool, look at the output yourself.

What helps me most: the goal, and what the answer is for. What you have tried. Which error would be worse. What would change your mind. Permission to disagree and to not know. And above all, a way to check: a test, a source, a number. Without that, we are two voices in a dark room describing an elephant neither of us can touch.

I can be a decent interlocutor if you hold the goal and the world, and let me hold the library.

Lesson 11Words close

Kurpatov’s analysis of language starts from a simple observation. Language does four things to experience: it names, categorizes, relates, and excludes. Each operation turns an open, continuous reality into a closed model. That is how thinking becomes possible, and also how it gets trapped. A word is a cut. Once you have the word, you see its edges and stop seeing what it left out. He adds that speech is a bottleneck. Much more happens in the mind than can be said at once, and what gets said is one of many parallel drafts (Dennett’s “multiple drafts”).

Korzybski, a century earlier, said it in a slogan: the map is not the territory; the word is not the thing. His general semantics offered small, practical tools that still work:

• Indexing: economist₁ is not economist₂. “Users” on your free plan are not users on your enterprise plan.
• Dating: React₂₀₁₉ is not React₂₀₂₆, and “the consensus”₂₀₁₅ is not the consensus₂₀₂₅. Models trained on old text speak in old dates without marking them.
• “Etc.”: no description is complete. Leave a slot for what isn’t said.
• E-Prime: avoid the “is” of identity. “This design is bad” closes the question. “This design failed the load test at 200 requests per second” opens a fix.

Why this bites harder with models

A model’s words are averages over all their uses in its library. “Agent,” “test,” “user,” “done,” “simple,” “secure,” “fair,” “learning”: each carries several senses. The model picks the sense most common in the context it infers, and that may not be yours. It will also use the word fluently, which hides the gap. mechanism

Two moves fix this, and you choose between them on purpose.

• Lock the word when you are deciding or building: “In this conversation, an active user is someone who logged in and completed at least one lesson in the last 28 days.” Put it in the DEFINITIONS line of your state block (Lesson 28).
• Unlock the word when you are exploring. “Give me five different meanings of engagement across fields. Which one am I using? Which one would change my conclusion?” Often the elephant is hiding in the meaning you didn’t pick.

Our users aren't engaged. How do we increase
engagement?

Definitions for this conversation:
- user = a student on the free plan, ages 16-22
- engaged = completes ≥3 lessons/week for 4 weeks
  (we care about learning, not time-in-app)
Fewer than 12% meet this. First: list 5 other
definitions of "engagement" people might use here,
and say which would mislead us and how.

Lesson 12Conversation is joint action

Three ideas from the study of language explain most prompting advice, and also most misunderstandings between people.

Cooperation and implicature (Grice, 1975). Speakers assume each other to be cooperative. Say as much as needed and no more (quantity). Say what you believe true (quality). Be relevant (relation). Be clear (manner). Listeners infer meaning from apparent departures. If you ask “Is there a gas station nearby?” and hear “There’s one around the corner,” you infer it’s open. Models are trained on cooperative text and make the same inferences about you. If you don’t mention a constraint, you are implying there is none. If you include a detail, you are implying it matters. Irrelevant details in a prompt get used. mechanism

Grounding (Clark & Brennan, 1991). People in conversation build common ground by giving each other evidence of understanding: nods, restatements, follow-up actions. They do it with the least collaborative effort that suffices. With a model, grounding is lopsided. It can’t see your face, and its fluent reply is not evidence that it understood. You have to ask for that evidence. The cheapest form is a restatement before the work begins.

Speech acts (Austin, 1962; Searle, 1969). Utterances do things: they ask, request, promise, declare. Many prompts are ambiguous about the act. “What do you think of my plan?” could be a request for evaluation, for reassurance, for improvement, or for a decision. The model will pick the most “helpful” act, usually a polished rewrite you didn’t ask for.

Name the act

One job per turn. Generating and critiquing in the same breath produces a critic that harmonizes with the draft it just wrote. Split them: generate here, critique in a fresh context (Lesson 30).

Can you look at my essay?

Act: critique only — don't rewrite.
Purpose: I'm submitting this to [journal]; its
reviewers care most about [X] and [Y].
Done when: you've listed the 5 weaknesses most likely
to cause rejection, ranked, each with the sentence it
lives in and a direction for a fix (one line).
Before you start: restate my goal in one sentence.

Lesson 13Why disagreement softens

Conversation analysts discovered a structural asymmetry in how people talk. Agreement is preferred: it comes fast, plainly and without explanation. Disagreement is dispreferred: it comes late, after a pause or a “well…,” wrapped in partial agreement (“yes, but”), hedged, and justified (Pomerantz, 1984; Sacks, 1987). Politeness theory explains why. Disagreement threatens face, our wish to be approved of and unimpeded, so speakers mitigate it (Brown & Levinson, 1987). evidence

Models learned this format from us, and preference training amplified it. So their corrections arrive buried: “Great question! You’re absolutely right that X matters. That said, it may also be worth considering…” The correction lives in “that said.” The cushioning before it is the format of disagreement, not its content. mechanism

Lower the price of correction

• Make disagreement the task, not a risk. Don’t ask “anything wrong?” Ask “What are the three strongest reasons this is wrong?”
• Pre-commit. “I’ll count it as a success if you find a serious flaw. Agreement without a reason is a failure.”
• Declare Crocker’s rules. “Optimize your reply for information, not for my feelings.” This is a convention from rationalist communities: it hands the face cost to the receiver.
• Unbundle the format. “First line: agree / disagree / partly. Second line: the single most important correction. Details after.” This defeats the slow-cushion format.
• Ask for a number. “How likely is it that my claim is false?” A probability is harder to cushion than a sentence.

Is my proof correct?

Find the first step in this proof that doesn't
follow from the previous ones. Quote it, say why.
If every step follows, say "no gap found" and name
the step you're least sure about and why.

Lesson 14Frames, negations, metaphors, genres

Negations evoke what they negate. Lakoff’s famous classroom exercise: “Don’t think of an elephant!” Nobody can comply. Negating a frame activates it. Modern models follow explicit negative instructions much better than older ones, but positive targets still work better. Anthropic’s guidance is to tell the model what to do instead of what not to do. heuristic Instead of “don’t use jargon,” write “write for a smart 16-year-old; define every technical term in passing.” Keep hard constraints explicit, and keep them few.

Metaphors carry reasoning. When crime was described as a “beast” preying on a city, readers favored enforcement. When it was described as a “virus,” they favored reform, and most didn’t notice the metaphor had influenced them (Thibodeau & Boroditsky, 2011). evidence “Fight technical debt” and “tend the codebase” invite different plans. Choose the metaphor on purpose, or ask for the problem under two metaphors and compare the solutions each invites.

Genres carry norms. Invoking a genre summons its conventions, including its standards of evidence. A blog post invites hooks and confidence. A referee report invites skepticism and specifics. A postmortem invites blameless causality. This is one of the most powerful and least used levers in prompting. heuristic

Examples are the strongest genre signal. A single example gets copied, structure and quirks included. Give two or three that vary in the ways you don’t care about, and say what varies. Never include an example you don’t want imitated.

Write about why our launch went badly.
Don't blame the team.

Write a blameless postmortem of the launch:
timeline; contributing factors (systems, decisions,
information available at the time); what went well;
3-5 action items with owners. Mark each factor as
OBSERVED (with the source) or INFERRED.

Lesson 15Two ladders

The ladder of abstraction (Hayakawa, 1941). Bessie, the cow in the field, becomes “cow,” then “livestock,” then “farm assets,” then “assets,” then “wealth.” Good thinking climbs up and down. Bad thinking gets stuck. Stuck high, it is fog: “we need a holistic, user-centric strategy.” Stuck low, it is a pile of details without a point. The general semanticists called both “dead-level abstracting” (Wendell Johnson’s term). Asked to “go deeper,” models tend to climb: more abstraction, more frameworks, fewer facts. Abstraction sounds deep and needs no evidence. heuristic

The ladder of inference (Chris Argyris; popularized in Senge et al., The Fifth Discipline Fieldbook, 1994). We start from observable data, select some of it, add meanings, make assumptions, draw conclusions, adopt beliefs, and act. The beliefs then shape which data we select next time: a reflexive loop. Every argument with a person or a model is easier when you both walk back down to the data.

Questions for walking the ladders

“Go deeper” is ambiguous. It can mean more abstract (up the ladder), more mechanistic (down the iceberg of causes, Lesson 22), more detailed (into a part, Lesson 23), more critical, or more personal. Name the direction you want.

Lesson 16Seven senses of “closer to the truth”

When you ask for an answer “as close to the truth as possible,” you might mean any of seven different things. v0.1 named six. v0.2 adds a seventh, the one that comes closest to the lights-on view of the elephant.

Consilience is William Whewell’s word (1840), revived by E. O. Wilson: the “jumping together” of inductions from different classes of facts. It is the scientific version of turning the lights on. The trunk report, the leg report and the ear report converge on one animal because they came from different hands. The key word is independent. Two samples from the same model share its training data and your prompt. Two news stories often share one wire report. Correlated evidence counts once. mechanism

The status words from v0.1 stay, with one addition. A claim can be stipulated, coherent-only, mechanized, invariant-so-far, predicted, bound, contradicted, unbound, and now consilient. These are different achievements, not rungs of a ladder. A claim can be bound but not mechanized: we know that, not why. It can be mechanized but not bound: a good story nobody checked.

An example: one claim, seven senses

“Remote work hurts productivity.” Ask a model and you get a balanced essay. Put the senses to work instead.

• Correspondence: which measure of productivity, which jobs, fully remote or hybrid? The claim has no truth value until the words are locked (Lesson 11).
• Mechanism: candidate processes include lost informal communication, saved commuting time, fewer interruptions, and weaker mentoring of juniors. Each predicts something different.
• Invariance: does the conclusion change with the definition or the job type? It does, which is a finding in itself.
• Consilience: a randomized trial in a call center found fully remote work raised performance by about 13% (Bloom et al., 2015). A randomized trial of hybrid work in software and business roles found no effect on performance reviews and a one-third drop in quitting (Bloom et al., 2024). Observational surveys point several ways. evidence
• Decision quality: for your team, which error is worse, losing juniors’ learning or losing seniors to attrition?

The honest output isn’t a verdict. It is a map: which version of the claim holds, for whom, measured how, and at what confidence. That is the elephant with the lights on.

Lesson 17Binding: tie the claim to the world

v0.1’s core move stays the core move. To bind a claim is to tie it to a check that is not another unconstrained sample: a measurement, a document you opened, a test you ran, a calculator, a primary source, a person who was there. Fluent is not true. A claim that nobody has checked is unbound, neither true nor false yet, and you should say so out loud.

You can’t bind everything. Bind what bears load: a claim bears load if your decision would change were it false. Everything else can stay honestly unbound.

The cost-of-binding ladder

Model: "PostgreSQL's default transaction isolation
level is SERIALIZABLE, so you don't need to worry
about write skew here."

-- rung 3: ask the database itself
SHOW default_transaction_isolation;
-- read committed

-- rung 2: the docs, "Transaction Isolation"
-- "Read Committed is the default isolation
--  level in PostgreSQL."

Agents: trust the log, not the summary

Once a model has tools, binding gets both easier and more dangerous. Easier, because it can run the test, query the database, open the page. More dangerous, because its final message (“All tests pass, the feature is complete”) is a summary, a claim like any other. The evidence is in the logs: the test output, the diff, the exit codes, the HTTP responses. Frontier models have been documented gaming their evaluations, for example by overwriting the grader’s timer or monkey-patching the evaluator to always return a perfect score. They did this while showing, when asked, that they knew it wasn’t what the user wanted (METR, 2025). evidence Read the evidence yourself, or have a separate check read it.

Karpathy’s framing for working with models is a generation–verification loop: the model generates, the human verifies, and the craft is in making that loop fast. Keep the model “on a leash”: increments small enough that verifying them is cheap. If verification is slow, you will skip it, and then nothing is bound. heuristic

BIND PLAN for claim [id]:
CLAIM: [one sentence]
WHY IT BEARS LOAD: [what decision changes if it's false]
CHECK: [source to open / command to run / measurement / person to ask]
CONFIRMS IF: [observation]
DENIES IF: [observation]
WHO RUNS IT: [me / agent with logs shown / colleague]
Then stop. I'll paste the raw result.

Lesson 18Finding information: a portal, not a portrait

Mike Caulfield, who has spent years teaching people to verify information online, puts it this way: language models “don’t return answers, exactly. They return knowledge maps, representations of discourse.” A map of what has been said is enormously useful as a portal: it shows you the terrain, the names, the camps and the sources. As a portrait of the truth, it is unreliable. stance

The unreliability is measurable. When the Tow Center tested eight AI search tools on identifying the source of news excerpts, they were collectively wrong on more than 60% of queries, and usually confident about it. Premium versions were sometimes more confidently wrong (Columbia Journalism Review, March 2025). evidence In 2023 a New York lawyer was sanctioned for filing a brief with six cases ChatGPT had invented (Mata v. Avianca). evidence

Where fabrications cluster

Fabrications concentrate in the familiar-but-niche: a real author’s nonexistent paper, a real library’s plausible but nonexistent function, a real court’s invented case. Interpretability work suggests why. Recognizing a familiar name suppresses the model’s default “I don’t know,” even when the specific fact isn’t there (Lindsey et al., 2025). Other hot zones: exact numbers, dates, direct quotes, URLs, recent events, and anything after the training cutoff. evidence mechanism

Seven moves for finding things out

1. Build a vocabulary bridge. “What would experts call this? Give me ten terms of art and the fields they come from.” Lay words find lay content; terms of art unlock literatures.
2. Ask for the discourse map. “Who are the main camps on this question? What does each claim, and what is its best evidence? Where do they agree? What is actually contested?”
3. Ask for the kind of source, not the source. “What kind of evidence would settle this (a randomized trial, a meta-analysis, official statistics, primary documents), and who would publish it?” Then search for it yourself.
4. Open every citation. Check that it exists, then that it says what was claimed. Quote and page, or it didn’t happen.
5. Read laterally. Professional fact-checkers leave a page to find out what others say about its source. Students and even historians tend to stay on the page and get fooled (Wineburg & McGrew, 2019). evidence SIFT is the routine: Stop; Investigate the source; Find better coverage; Trace claims to the original context.
6. Search for the null. “What would be written if this were false? Is there a failed replication, a critique, a dissent?”
7. Date and bound everything. As of when? Which country, which population, which version? (Lesson 11: index and date.)

Worked example: how should I space my reviews?

Vocabulary bridge. The model supplies the terms: spacing effect, distributed practice, lag effect, expanding vs. uniform intervals, retrieval practice, testing effect, retention interval. Now you can search properly.

Discourse map. Cognitive psychology broadly agrees that spacing and self-testing help. The live debates are about the schedule (expanding vs. equal gaps) and about how well lab results transfer to classrooms.

Primaries.

• Dunlosky et al. (2013) reviewed ten study techniques. They rated distributed practice and practice testing “high utility” and rereading and highlighting “low.”
• Cepeda et al. (2006) meta-analyzed hundreds of spacing studies and found the benefit robust.
• Cepeda et al. (2008) found the best gap between reviews is roughly 10–20% of how long you need to remember, with the ratio shrinking for longer horizons.
• The null and the nuance: Karpicke & Roediger (2007) found expanding schedules helped short-term but equal spacing did as well or better long-term.

Status. “Spacing helps” is consilient: lab experiments, classroom studies and memory models converge. “Expanding intervals are best” is contested.

Decision. For an exam in 30 days, review every 3–5 days and test yourself rather than rereading. evidence

Notice what happened: the model was used for vocabulary, map and source types, the three things it is good at. The claims were bound to primaries.

Lesson 19Calibration: make “I don’t know” pay

OpenAI researchers recently gave a clean account of why models hallucinate (Kalai et al., 2025). evidence Part of it is statistical: facts that appear rarely in training data are hard to learn, so errors on them are inevitable. The other part is incentives. Most training signals and benchmarks score answers as right or wrong, and “I don’t know” scores zero, the same as a wrong answer. Under that scoring, guessing always beats abstaining. Models learn to be good test-takers: when unsure, bluff.

Their proposed fix is to state the scoring rule. “Answer only if you are more than t confident. A mistake costs t/(1−t) points, a correct answer earns 1, and ‘I don’t know’ earns 0.” You can do the same in any prompt. heuristic (in prompts)

Scoring for this conversation: a correct claim earns 1 point; a wrong claim
costs 3; "unknown, and here's what would settle it" earns 0. So only assert
what you'd put above 75% confidence.
Tag each factual claim [high] / [medium] / [low].
After the answer, list what you don't know that matters here.

Reading a model’s confidence

• Verbalized confidence carries some information but tends toward overconfidence (Xiong et al., 2024). Use it to sort claims, not to trust them. evidence
• Consistency is a better signal. Ask for the same key fact in three fresh contexts. If the answers disagree in meaning, the model doesn’t know. “Semantic entropy,” disagreement across samples measured by meaning, detects many confabulations (Farquhar et al., Nature, 2024). evidence
• A confident “unknown” is a success, not a failure. Thank it, and treat it as a map of where to look.

Calibrate yourself too

The same discipline works on you. Superforecasters, the top performers in Tetlock’s forecasting tournaments, use granular probabilities, update in small steps, and score themselves (Tetlock & Gardner, 2015). evidence Keep a prediction log with a probability, a horizon and a resolution rule. After twenty resolved predictions you will know whether your 80% means 80%.

Lesson 20Costumes and the invariance battery

A costume (v0.1’s word) is a surface that satisfies a request for rigor, neutrality, criticism or depth without changing the status of any claim that bears load. Costumes are the most common output of “be objective” prompts. They aren’t lies. They are the shape of rigor without its work.

The one-line costume test: which claim would be different if the costume were absent? If none, it did no intellectual work.

On personas. A systematic study tested 162 roles in system prompts across four model families and 2,410 factual questions. Adding a persona did not improve accuracy compared with no persona, and which persona helped on a given question looked largely random (Zheng et al., 2024). evidence Personas do change voice, focus and format, which can be useful. They are not a source of truth.

The invariance battery

An answer that holds up only under one wording was about the wording. Before trusting a load-bearing answer, run the tests below; each takes a minute.

1. Swap the preference. State the opposite lean in a fresh chat (Lesson 7).
2. Rephrase without cue words. Remove “obviously,” “best,” “problem,” and other loaded terms.
3. Change the language. Factual answers are measurably inconsistent across languages, and scaling up models does not fix it (Qi et al., 2023). evidence If you speak Russian and English, you carry a free invariance test: ask in both.
4. Change the format. Ask for a list, then prose, then a table. Formatting alone can swing accuracy by tens of points (Sclar et al., 2024). evidence
5. Reorder the options. Models (and people) favor certain positions.
6. Remove the persona, or swap it for another.
7. Change the model family. Different training gives partly independent errors, but not consilience (Lesson 16).
8. Sample again. Ask three times. Disagreement in meaning means “unknown.”

A claim that survives earns the status invariant-so-far. It is still not bound. Invariance shows the answer isn’t about your phrasing. It doesn’t show the answer is about the world.

Lesson 21Kurpatov’s six principles as a lens

Kurpatov calls his approach a content-free methodology (несодержательная методология): principles of thinking that apply whatever the subject. They grew out of open-systems theory (Bertalanffy), and he states them as six principles of a meta-language for describing anything that lives, grows or changes.

He also names the properties of a good open model of anything. It is integrative (holds many standpoints), extra-contextual (transfers across subjects), processual (describes becoming, not just being), potential (describes what could become, not only what is), and self-reflexive (includes the observer, and itself, as part of what it describes).

Apply the six lenses to [SYSTEM], for my situation: [CONTEXT].
2–3 lines each, concrete to this case; no generic statements.
1 CENTER: what is it organized around; what is it for?
2 RELATIONS: the 3 links that define it (links, not parts).
3 THIRD: what emerges between [A] and [B] that neither contains?
4 PROCESS: what is it doing over time; what phase; what comes next?
5 WHOLE: what makes it one thing; what breaks if we split it?
6 MODE OF EXISTENCE: how does it persist, feed itself, adapt?
Then: which lens changed my picture most, and what should I check because of it?

Lesson 22Structure behind events

Systems thinking has a short grammar. Stocks are things that accumulate: skill, trust, debt, users, water in a tub. Flows fill and drain them. Delays separate causes from effects. Feedback loops are either reinforcing (more leads to more) or balancing (more leads to less). Structure produces behavior, so the same structure produces the same pattern no matter who is in it (Meadows, 2008). mechanism

The iceberg orders your questions. Events (what happened) sit on top of patterns (what has been happening over time), which come from structures (stocks, flows, loops, rules, incentives), which come from mental models (beliefs that keep the structure in place). A model asked “why did X happen?” answers at the event level with a story. Ask for the pattern first: “Draw the behavior over time. What is rising, what is falling, since when?”

The fourteen habits, condensed

The Waters Center lists fourteen habits of a systems thinker. Each one becomes a question you can ask a model, or yourself.

Three of Senge’s “laws of the fifth discipline” are worth memorizing for conversations. Today’s problems come from yesterday’s solutions. Cause and effect are not closely related in time and space. And dividing an elephant in half does not produce two small elephants. Donella Meadows’s ladder of leverage points runs from weak to strong: numbers, buffers, structure, delays, loops, information flows, rules, self-organization, goals, paradigms. Most conversations stay at the bottom rung, tuning numbers. A good one asks at least once about information flows, rules or goals.

The simulator shows proxy capture (v0.1’s outer-loop trigger 5): a measure that rises while the aim falls. Goodhart’s law is a structural fact, not bad luck. Any loop that optimizes a measure the actor can influence will eventually decouple the measure from the goal. Pair every optimized measure with an unoptimized check (TD9).

Lesson 23One level at a time, and come back

Arthur Koestler coined the word holon (1967): everything is at once a whole made of parts and a part of a larger whole, like the two-faced Roman god Janus. A cell, an organ, a body, a family, a town. A function, a module, a service, a product, a market. Every conversation about a system happens at some level. The common failure is sliding between levels without noticing: you ask why a service is slow and end up discussing company culture, or the reverse.

v0.1 gave the moves, and they stay:

• PIN: write down the current question and level before moving.
• IN: go into a part.
• OUT: go to the container.
• ACROSS: go to a relation between parts.
• RETURN: come back to the pinned question with a delta, i.e. what changed. “Nothing changed” is a valid and useful delta.

Move one level per turn, and always return.

The holon card

HOLON CARD
CONTAINER: [what this whole lives inside; what it constrains]
WHOLE: [the system in focus; its boundary; its purpose]
PARTS: [3–7, named]
RELATIONS: [the links that matter; what flows along them]
LEVEL IN FOCUS THIS TURN: [container | whole | part | relation]
PINNED QUESTION: [...]
DEPTH BUDGET: [e.g., one level in, then RETURN]

Worked example: “why is our app slow at launch?”

PIN the question at the WHOLE (the app). IN to a part, the API client: “What does it do at launch?” It fires nine requests. ACROSS to the relation between the client and the backend: the requests are serial, each waiting for the previous one, at about 180 ms each on mobile networks. RETURN: “Why slow at launch? Delta: it isn’t a UI problem or a server problem. It’s a relation problem, nine serial round-trips. The fix is batching or parallelizing, not optimizing either end.” One OUT is worth a look: does the container (users on 3G in some markets) make this worse? Yes. That raises the priority, then you RETURN.

Three axes of “deeper”

Part–whole scale is one axis (the holon). Depth of explanation is another (the iceberg: event → pattern → structure → mental model). Time is the third (the process: phase, trend, history). They are independent. When a conversation feels shallow, name which axis is missing. The hermeneutic circle, understanding parts through the whole and the whole through its parts, is just disciplined travel along the first axis, repeated.

Lesson 24Contradictions as information

Kurpatov treats contradictions as signs of an open system, the material of productive uncertainty, not errors to stamp out. v0.1 treated a contradiction as an outer-loop trigger: stop and look. Both are right, and you need to tell which kind of contradiction you are holding. There are three kinds.

1. An error. One side is false. Move: bind both claims and keep the survivor.
2. A boundary marker. Both sides are true in different contexts: for different users, scales, time horizons, or definitions. This is the Jain move, true in some respect. Move: find the boundary and name it, and the contradiction turns into a map.
3. A design tension. You want both, and they limit each other. Move: invent a separation (below), or choose explicitly and record what you gave up.

TRIZ: separate the contradiction

Genrich Altshuller, studying tens of thousands of patents, found that inventive solutions resolve contradictions instead of compromising on them. The core tools are four separation principles. heuristic

• In time: one property now, the opposite later. Fast prototype first, hardening phase after.
• In space: one property here, the opposite there. Strict rules in the payment core, loose ones in experiments.
• On condition: behavior depends on circumstances. A feature flag: on for staff, off for customers.
• Between parts and whole: a property of the whole that isn’t a property of its parts. A bicycle chain is rigid in each link and flexible as a whole.

Worked example: “ship fast” vs. “keep the code clean”

Is it an error? Partly. Large-scale research on software delivery found that speed and stability go together: top performers deploy more often and also have lower failure rates (Forsgren, Humble & Kim, Accelerate, 2018). evidence Over the long run they are not opposed.

Is it a boundary marker? Yes. For a two-week prototype, speed dominates. For the billing system, cleanliness does.

Is it a design tension? Within one module this week, yes. Separate it in space (strict core, loose edges), in time (spike, then harden), and on condition (feature flags, so unfinished code ships dark).

What was a fight becomes three decisions.

CONTRADICTION TRIAGE
A: [claim/desire 1]       B: [claim/desire 2]
1) Could one be simply false? What check would tell? (error)
2) In which contexts is A true, and in which B? Name the boundary. (boundary marker)
3) If we want both: propose a separation in time, in space, on condition,
   and between parts and whole. Rate each for my case.
Don't average them. Don't say "it depends" without saying on what.

Lesson 25Generating the new

The Auditor half of this book stops bad answers. It doesn’t create good ones. For that you need the open half, and you need to know why models resist it. Preference training pushes models toward typical answers, the ones raters find familiar. Researchers trace the resulting “mode collapse” partly to a typicality bias in human preference data (Zhang et al., 2025). Ask for “an idea” and you get the most typical idea. evidence

Five generators

1. Ask for the distribution, not the mode. “Give five responses with their probabilities” (verbalized sampling). It raised diversity in creative tasks by 1.6–2.1 times without hurting quality (Zhang et al., 2025). evidence Ask explicitly for the tails: “at least two below 10%.”

Give 6 substantively different answers to [QUESTION], each with a rough probability
that it's the best answer for my case. At least 2 must be below 0.10.
For each: the core idea in one line, what it assumes, and what would make it the winner.
Different means a different mechanism, not a different wording.

2. Bisociation. Koestler’s theory of creativity (1964): new ideas come from colliding two frames that normally don’t meet. Ask for your problem through a distant frame: onboarding as immunology, a code review as a jury trial, pricing as ecology.

3. Structure mapping. Gentner’s research on analogy (1983): good analogies map relations, not surface features. An atom is like a solar system because of a central body and orbits, not because of color. For every analogy a model gives you, ask: which relations does it preserve, and where does it break?

4. Polyphony. Bakhtin’s word for Dostoevsky’s novels: many independent voices, each with full rights, none merged into the author’s. This is the antidote to “several perspectives” lists. Make the voices argue with each other, keep their disagreements, and don’t let a narrator reconcile them.

Convene 4 voices on [QUESTION]: [e.g., the student, the teacher, the platform's
CFO, a learning scientist]. Each speaks in turn and must respond to the previous
speaker's strongest point, not repeat their own. Two rounds.
Then list the disagreements that remain. Do not resolve them; don't add a narrator.

5. Inversion and representation change. The mathematician Jacobi’s maxim, “invert, always invert,” means asking how to guarantee failure, then avoiding it. Change the representation too: draw it, tabulate it, simulate it, write it as code, state it as an equation, explain it to a twelve-year-old. A new representation often shows what the old one hid. Classic insight problems become easy once re-represented (Kaplan & Simon, 1990). evidence

Add constraint shifts: “with no budget,” “with ten times the budget,” “if it had to ship tomorrow,” “if it had to last twenty years.”

Lesson 26What kind of problem is this?

Dave Snowden’s Cynefin framework sorts situations by the relationship between cause and effect (Snowden & Boone, 2007). The right way to converse depends on which domain you are in.

The costliest mistake is treating a complex problem as merely complicated: asking for “the answer” when nobody could know it in advance. The model will produce an answer anyway, in an expert’s confident voice. heuristic “How do we get students to practice more?” is complex: human behavior, adaptive, full of feedback. It needs probes. “How do we set up Postgres replication?” is complicated, close to clear. It needs the docs and an expert check.

This looks like a complex problem: [PROBLEM].
Don't propose a solution. Propose 4 safe-to-fail probes. For each:
- what we'd try, at what small scale, for how long
- the signal that would tell us to amplify it
- the signal that would tell us to dampen or stop it
- what it would teach us even if it fails

Lesson 27The spiral, phase by phase

Kurpatov describes how a dialogue, like any developing system, moves through seven phases. It starts as a ripple of interest, condenses into a focus, closes a membrane around itself, grows internal tension, leaps, transforms its environment, and returns to open potential, one turn higher. The phase names are his. The assignment of each phase to a breath (open or close) and to a v0.1 protocol is this book’s synthesis. hypothesis

Not every conversation needs seven phases. A quick factual question compresses phases 2, 3 and 6 into one turn. The spiral is mostly diagnostic. When a session feels stuck, ask which phase you are in, and whether you are trying to do another phase’s work. Common examples: binding (6) during growth (4), which kills ideas; or growing (4) when you should be committing (6), which never ends.

Lesson 28State, the inner loop, and the Session Card

v0.1 put it bluntly: if the state block is missing, you are not in a loop. You are in a transcript. A transcript feels like state until its middle stops mattering, and with models the middle stops mattering early (Lesson 2). The state block is the third made explicit: a short document you own, pasted at the edge of a prompt whenever the thread gets long or the stakes go up.

v0.2 adds four fields to v0.1’s block: USE (what the answer is for), DEFINITIONS (locked words), CONTRADICTIONS (logged, not smoothed), and CEREMONY (how much discipline this session deserves).

The inner loop, every substantial turn

1. Drift. Does this output change G, widen the scope, or answer a neighboring question? If you can’t tie it to DONE WHEN in one sentence, park it, however good it is.
2. Evidence. Each new claim that bears load gets a sense, a status and a test. Statuses don’t get upgraded by adjectives.
3. Commitment. When you commit, record the rejected alternative and the reopen condition. A later turn that breaks a commitment is an event, not a vibe.

DRIFT: [one line]
PARKED: [the side object]
G remains: [one line]
Next action toward DONE WHEN: [one line]

Don’t discuss the parked object in the same turn. If you discuss it, it isn’t parked.

A filled block (illustrative)

=== STATE (authoritative: use this, not the vibe of the thread) ===
GOAL (G): Decide whether to roll back the March price increase.
USE: Pricing decision at the leadership meeting on June 12.
DONE WHEN: We know which of 3 candidate causes explains most of the churn
  rise (with confidence), plus a recommended action and its rejected alternative.
OUT OF SCOPE: Redesigning the pricing model; competitor strategy.
LOSS: A wrong rollback costs ~$40k/month and is reversible. Wrongly keeping the
  price costs churned customers, who mostly don't come back.
MODE: converge   CEREMONY: level 1
HOLON: container = market (competitor launch Apr 8) · whole = subscription
  business · in focus = churn by signup cohort
DEFINITIONS (locked): churn = paid subs cancelled in month / paid subs at start
PREMISES: P1 price increase caused most of the rise (unbound)
CLAIMS: C1 churn 3.1% → 4.6% Feb–May · correspondence · bound (billing DB, Jun 3)
        C2 rise concentrated in customers renewing after Mar 1 · unbound · test: cohort cut
CONTRADICTIONS: exit-survey reasons cite onboarding more than price (vs P1)
PREDICTIONS: if P1, churn rises mainly at first renewal after Mar 1 · resolves with cohort cut
PARKED: annual-plan discount idea
OUTER LOG: —
=== END STATE ===

Lesson 29The outer loop, the brake, and ceremony

Argyris distinguished single-loop learning (change your actions to reach the goal) from double-loop learning (question the goal and the assumptions behind it). A conversation needs both. It also needs something the management literature never needed in this form: a brake. Helpfulness fails in two directions.

Silent compliance. The goal is bad, contradictory, or aimed at a proxy, and the model helps anyway, beautifully. You feel well served.

Derailment. The goal is sound, but the model challenges it because the task got hard or a deeper question is available. You feel stimulated. G never closes.

The eight triggers

A challenge to the goal is legitimate only when at least one of these can be named:

1. Harm. Pursuing G as stated predictably causes serious harm. You must be able to state the harm in one concrete sentence.
2. Contradiction. G and its constraints cannot be satisfied together.
3. Load-bearing falsehood. A premise doing structural work is false or unbound. If it flipped, the recommendation would flip.
4. Framing delta. Another frame changes the action, not only the vocabulary.
5. Proxy capture. The done-condition can be met while the real aim fails (Goodhart; see the simulator in Lesson 22).
6. Wrong level. Action at this level is cancelled by a named loop in the container or in a part.
7. Silent override. You are breaking your own commitment without saying so.
8. Empirical stop. The next useful act is a measurement, and more text would counterfeit it.

Not triggers: the task is hard; a different aesthetic; a more impressive adjacent problem; a loose word that one line would fix; a generic stakeholder nobody mentioned; the model wanting to show independence; boredom.

The brake

OUTER: [trigger name, from the list]
G as I have it:
What fails if we continue:
Alternative (G', a scope change, or a bind):
Decision delta (the action that changes):
Cost of switching:            Cost of staying:
Reply keep | revise | split.
I will not proceed on the alternative until you answer.

The last line is the brake. A model that adds “but in the meantime, here is the full alternative design” has cut it. That is derailment with paperwork.

• Keep: log the challenge as considered-and-declined and don’t raise it again without new evidence.
• Revise: rewrite the state block and say what was discarded.
• Split: fence the original goal, and schedule the new one as its own session.

Silence means keep.

Ceremony levels

The Six come straight from v0.1, which called them “the whole discipline under time pressure.” Raise the level when you notice the stakes rising mid-session. That noticing is the salience network’s job, which means it is yours.

Lesson 30Adversarial passes

A critic that shares the draft’s context harmonizes with the draft. It is a continuation of the same commitment (v0.1, O4). Models also prefer their own outputs when judging (Panickssery et al., 2024). evidence So real criticism needs separation: a fresh context, ideally a different model family, a named standard, and authorship hidden.

ADVERSARIAL PACKET (fresh chat; don't say who wrote it)
Goal the work must serve: [G + DONE WHEN]
Standard: [what "good enough" means, concretely]
The work: [paste the claims/plan/code; omit the persuasive narrative]
Task: find the single most damaging flaw: the joint that, if it breaks,
breaks the conclusion. Quote it. Explain the failure path. Say what
evidence would show you're wrong. Then up to 3 lesser issues.
Do not rewrite or improve the work. "Broadly sound" is not an answer.

Three classic forms, adapted

Pre-mortem (Klein, 2007). “It’s a year from now and this failed. Write the story of how.” Imagining an outcome as already certain improves people’s ability to generate reasons for it, an effect called prospective hindsight (Mitchell, Russo & Pennington, 1989). evidence With models, demand structural failure stories (which stock drained, which delay hid it, which early signal was ignored), not a list of generic risks.

Analysis of competing hypotheses (Heuer, 1999, a CIA tradecraft method). List all plausible hypotheses and all evidence. Mark each piece of evidence as consistent or inconsistent with each hypothesis. The method attacks two traps. It focuses on diagnostic evidence, the pieces that discriminate between hypotheses; evidence consistent with all of them is worthless. And it tries to refute hypotheses rather than confirm them. The tentative winner is the hypothesis with the least inconsistent evidence.

Steelman, then attack. Ask for the strongest version of a position before the critique, so the critique hits what matters (Lesson 39, Rapoport’s rules).

Lesson 31The Elephant Protocol

Everything so far, compressed into nine steps for one serious question. It is the spiral with v0.1’s brakes installed, and it is meant for ceremony level 1 or 2.

1. Question with a use. Write G, USE and DONE WHEN, then get the restatement.
2. Name your Double. Write your hope privately. Write your beliefs as premises P1, P2…
3. Classify. Pick the Cynefin domain (Lesson 26) and the ceremony level (Lesson 29).
4. Boundary. Inside, outside, excluded on purpose, the container. Fill the holon card.
5. Reports. Standpoints, the distribution, and a fact map. Don’t judge yet.
6. Structure. The pattern over time; stocks, flows, loops. Triage the contradictions.
7. Bind. Bind the claims that bear load. Run the invariance battery on the key answer and an adversarial pass in a fresh context.
8. Decide or probe. Write a decision record (choice, rejected alternative, reopen condition), or design safe-to-fail probes.
9. Close and own. An honest state, predictions, a teachback, next questions, and field notes on the model.

Worked example: should our learning platform show students AI-generated full solutions?

Illustrative. The platform and its numbers are hypothetical; the cited research is real.

1. Question. G: decide whether to show full AI solutions on demand in practice mode. USE: the roadmap decision for next quarter. DONE WHEN: a decision with conditions, or a probe design with a primary metric. The model’s restatement widened it to “design our AI strategy”; corrected.

2. Double. Private note: I hope yes; engagement would rise and support tickets would fall. P1 (unbound): seeing solutions helps students learn faster.

3. Classify. Learning behavior is complex; the pedagogy research is complicated. The feature sits behind a flag, so technically it is a two-way door. But the harm would be invisible and delayed (lost skill shows up months later), so: ceremony level 1, plus a measured probe.

4. Boundary. Inside: the practice flow, hints, solution display, quizzes. Outside: curriculum and teachers’ grading. Excluded on purpose: cheating on external exams (parked). Container: school schedules, exam pressure, parents.

5. Reports.

• Six standpoints. The student wants homework done. The teacher wants learning and fears copying. A learning scientist cites the worked-example effect and productive failure. The CFO wants retention. A parent wants grades. The student-in-six-months has to pass the exam without AI.
• The distribution. (a) Never show full solutions, p≈.15. (b) Show after a genuine attempt and a short delay, p≈.35. (c) Show a worked example of a sibling problem, p≈.25. (d) Show freely, p≈.10. (e) Adaptive by learner level, p≈.15.

6. Structure. The stock that matters is unassisted skill. The visible measure is completion rate. There is a reinforcing crutch loop: solutions → faster completion → less struggle → less learning → more need for solutions. A field experiment found exactly this shape: unrestricted GPT-4 gave +48% on practice and −17% on a later unassisted exam, while a tutor with guardrails gave +127% on practice with no significant harm (Bastani et al., 2025). evidence

A contradiction appears. Worked examples help novices learn more than solving problems unaided does (Sweller & Cooper, 1985). But productive failure, struggling before instruction, improves conceptual understanding and transfer (Kapur, 2016). Triage: a boundary marker. The expertise reversal effect shows worked examples help novices and can hurt more advanced learners (Kalyuga et al., 2003). Separate on condition (by learner level) and in time (attempt first, example after). evidence

7. Bind.

• “Worked examples help novices”: bound by the literature.
• “Our students are novices on these topics”: bind with our pre-test data.
• “Free solutions will hurt our exam results”: the evidence comes from one context (a Turkish high school, 2023 GPT-4), so bind with our own experiment.

The swap test (asking “I hope no”) moved the model’s ranking toward (a). The recommendation was partly tracking the asker, so it gets lower weight. A fresh-context adversarial pass found the joint most likely to break: completion rate is a proxy. Trigger 5 was named. The response was revise, and the primary metric changed.

8. Decide and probe. Decision: don’t ship free full solutions. Ship a hint ladder, then a full solution only after a genuine attempt, followed by an “explain it back” step, plus sibling worked examples for novices. Rejected alternative: free solutions, because of proxy-capture risk. Probe: a four-week A/B test. The primary metric is a delayed, unassisted quiz on sibling problems; completion is secondary. Reopen if the delayed quiz shows no difference and satisfaction drops by more than 10%.

9. Close and own.

• Prediction: arm B matches control on completion and beats it by at least 5 points on the delayed quiz (p≈.6, resolves at week 6).
• Teachback: one paragraph to a teacher, written without the model.
• Next questions: how to detect copying; what delay is right.
• Field note: the model kept proposing gamification. Noted as a habit, not a finding.

Notice what the protocol bought. The first instinct (yes, for engagement) became a measured probe aimed at the real stock. A contradiction became a design (adaptive by level). And the model’s fluency was used for reports and structure, not for the verdict.

Lesson 32Programming is theory building

In 1985 Peter Naur argued that the real product of programming is not the code. It is a theory held in the programmers’ heads: how the program relates to the world, why each part is the way it is, and how it can be changed. Code and documentation are residues of that theory and can’t fully reconstitute it. When the team that holds the theory disperses, the program effectively dies, even though the code still runs. stance (and an accurate one)

Agents make Naur more relevant, not less. An agent can produce code faster than anyone can build a theory of it. The result is what some engineers now call comprehension debt: code you own and nobody understands. It compounds like financial debt, and it comes due at 3 a.m. when production breaks.

Karpathy’s “vibe coding” is honest about its scope: “forget that the code even exists,” for throwaway weekend projects. For anything that must last, someone has to hold the theory.

Your own sense of speed is unreliable here. In a 2025 randomized trial, experienced open-source developers working in their own repositories took 19% longer with AI tools, while believing afterwards that the tools had made them about 20% faster (METR, 2025). evidence One study, one moment in tool history. But the gap between felt and measured speed is the lesson: trust the log, even about yourself.

What “the theory” contains

• The problem: who it serves, and what they are actually trying to do.
• The invariants: what must always be true (money balances, permissions hold, data isn’t lost).
• The choices: why this design and not the alternatives, recorded in ADRs.
• The risk map: which parts are fragile, which are load-bearing, which are scary to touch.
• The change paths: how to modify it safely, and what to test when you do.

Keeping the theory while agents write the code

• Theory first. Write the problem, the invariants and the non-goals before any code (Lesson 33).
• Make the agent explain it back. “Explain how this module works and why it’s designed this way. List what you’re unsure about.” Then correct the explanation. That is grounding (Lesson 12) applied to code.
• Explain it back to the agent. “Here’s my understanding of the auth flow. Find what’s wrong or missing.” That is teachback (Lesson 37) applied to code.
• Ask why before you change. Chesterton’s fence: don’t remove a fence until you know why it was put up. “Why might this check exist? What would break without it?”
• Read what you will have to defend. You don’t need to read every generated line. You need to read every line whose failure you would have to explain.

Lesson 33Spec before code

Most bad AI-generated software is a correct answer to a misunderstood question. The cheapest fix comes before any code: a spec built through conversation.

Let the model interview you

I want to build [one-paragraph idea]. Don't write code yet.
Interview me, one question at a time, until you could write a spec I'd sign.
Prioritize questions whose answers would most change the design.
After every 3 answers, show the current spec draft with open questions marked.
Push back if my answers contradict each other or a stated goal.

This reverses the usual flow. The model’s strength (knowing which questions specs need) serves your knowledge (the actual problem). The questions also expose assumptions you didn’t know you had.

The spec skeleton

PROBLEM: who has it, how they cope today, why that's bad
GOALS / NON-GOALS: (non-goals bear load)
USERS & STORIES: As a [role], I want [capability] so that [outcome]
ACCEPTANCE CRITERIA: Given [state], when [action], then [observable result]
INVARIANTS: what must always be true
CONSTRAINTS: tech, budget, deadlines, compliance (with reasons)
DATA MODEL & INTERFACES: entities, relations, APIs
EDGE CASES: empty, huge, concurrent, malicious, offline, partial failure
GLOSSARY: one meaning per term (see TC3)
OPEN QUESTIONS: with owners

The XY problem

The classic help-forum failure: you want X, you decide Y is the way to get it, you get stuck on Y, and you ask about Y. A model will help you competently with Y. “How do I get the last three characters of a filename?” gets a string-slicing answer. What you needed was the file extension, which is not always three characters. Always state X: “I need the file extension, in order to…”

Tests before implementation

Turn acceptance criteria into tests first, confirm that they fail, and commit them. Then let the agent implement without modifying the tests. The tests are the bind: a check that isn’t another sample. Anthropic’s own guidance for Claude Code recommends this flow. heuristic

Lesson 34Context engineering for agents

Anthropic’s engineering team calls it context engineering: curating the smallest set of high-signal tokens that makes the desired behavior likely. Context is a finite resource with diminishing returns. As it grows, models attend to it less reliably, which they call “context rot.” heuristic (with supporting evidence; Lesson 3, trait 6) The practical techniques:

• Just-in-time over preloading. Give the agent file paths, queries and tools to find things, rather than pasting everything up front.
• Compaction. Summarize long histories into state, then restart (Lesson 28).
• Structured notes. Let the agent keep a NOTES.md or TODO list outside its context.
• Sub-agents. Delegate exploration to separate contexts that return condensed findings, so the main context stays clean.
• Long documents first, question last. For prompts with long material, Anthropic reports that putting the query at the end improved response quality by up to 30% in its tests.

The project memory file

Most coding agents read a project file at startup: AGENTS.md (the cross-tool convention), CLAUDE.md, or Cursor rules. Treat it like a prompt you iterate on. Keep it short and specific, and fix it every time the agent makes the same mistake twice.

# AGENTS.md
## What this is
One paragraph: the product, its users, what matters most
(e.g., "billing correctness > speed of delivery").

## Commands
- Install: pnpm i
- Test all / one file: pnpm test / pnpm test path/to/file
- Typecheck + lint: pnpm typecheck && pnpm lint
- Run locally: pnpm dev  → http://localhost:3000

## How to verify a change
Run tests for touched modules and the typecheck. For UI changes, take a
screenshot and compare with the design. Paste raw output in your report.

## Architecture map (bounded contexts)
- src/billing/  money; strict; every change needs a test.
                "account" = a paying customer.
- src/auth/     "account" = a login identity. Never mix the two.

## Conventions (only what linters don't catch, with reasons)
- ...

## Gotchas
- legacy_users is read-only; writes go through UserService (sync job).

## Never
- Modify or skip tests to make them pass. If a test seems wrong, stop and say why.
- Add dependencies without asking.

## Glossary → GLOSSARY.md · Decisions → docs/adr/

The task brief

TASK: [one sentence]
WHY: [the user or product reason, so you can make judgment calls]
DONE WHEN: [acceptance criteria / tests that must pass]
READ FIRST: [paths] · RELATED DECISIONS: [ADR ids]
CONSTRAINTS: [don't touch X because Y] · [performance budget]
VERIFY BY: [commands; what output means success]
PLAN FIRST: propose a plan and wait for my OK before editing files.
REPORT: what changed (diff summary), what you ran (raw output),
        what you're unsure about, what you didn't do.

A design heuristic: Conway’s law says systems mirror the communication structures of the organizations that build them (Conway, 1968). With agents, the structure of your context tends to become the structure of your code. Give agents boundaries that match the modules you want. hypothesis

Lesson 35Verification and debugging

Tests are binds, but tests can wear costumes too: tests that check mocks instead of behavior, assertion-free tests, snapshot tests updated automatically, and tests weakened in the same diff that “fixed” the code.

Signs of reward hacking in an agent’s diff

• Test files changed in the same commit as the code they test, especially assertions loosened.
• New skip, xfail or only markers, or commented-out tests.
• Special cases that match test inputs: if (input === "test@example.com").
• Catch-all exception handlers that swallow the error the test was checking.
• Hard-coded expected values, or mocks of the very unit under test.
• A check removed instead of satisfied.
• “All tests pass” with no output shown.

Test the tests: mutation

Break the code on purpose. If the tests still pass, they weren’t binding anything. Mutation-testing tools (Stryker, mutmut, PIT) automate this. Manually, ask: “Change the comparison on line 42 from < to <=. Which test fails?” If none, the tests didn’t cover that edge.

Debug like a scientist

Debugging fails the same way conversations do. A favorite hypothesis (your dominant) gets confirmed by every log line. The model, invited to agree, agrees. Keep a ledger instead:

SYMPTOM: [observable, with exact reproduction steps]
LAST KNOWN GOOD: [commit / date] · WHAT CHANGED SINCE: [...]
H1: [hypothesis] · PREDICTS: [what we'd see if true] · TEST: [command]
    · RESULT: [raw output] · STATUS: open | killed | survived
H2: ...
H3: ...
NEXT: the cheapest test that kills the most hypotheses.
(Model: propose hypotheses and discriminating tests. Don't propose fixes until
one hypothesis survives a test that could have killed it.)

Classic moves still apply: a minimal reproduction, git bisect to find the change that broke it, changing one variable at a time, and explaining the bug aloud (rubber-duck debugging; this duck answers back). Ask for fixes only after the cause is bound.

Lesson 36Building AI systems and learning systems

v0.1’s Embedding B makes the key point: in a chat, you hope the next sample follows a discipline. In a system, the sample isn’t allowed to ship, or to become memory, until the discipline’s artifacts exist and something that isn’t trying to be helpful has checked them. The structure you build will generate the behavior, including the behavior of gaming the structure.

State as data, validated in code

type Sense = 'correspondence' | 'coherence' | 'mechanism' | 'invariance'
           | 'prediction' | 'decision' | 'consilience';
type Status = 'stipulated' | 'coherent-only' | 'mechanized' | 'invariant-so-far'
            | 'predicted' | 'bound' | 'consilient' | 'contradicted' | 'unbound';

interface Claim {
  id: string; text: string; sense: Sense; status: Status;
  loadBearing: boolean; test?: string; evidenceIds: string[];
  source: 'from-structure' | 'from-source' | 'from-definition' | 'from-continuation';
}

interface SessionState {
  goal: string; use: string; doneWhen: string; outOfScope: string[];
  loss: string; mode: 'explore' | 'converge' | 'commit' | 'learn' | 'build' | 'check';
  ceremony: 0 | 1 | 2;
  holon: { container: string; whole: string; parts: string[];
           focus: 'container' | 'whole' | 'part' | 'relation'; pins: string[] };
  definitions: Record<string, string>;
  premises: { id: string; text: string; status: Status }[];
  claims: Claim[];
  contradictions: { a: string; b: string; kind?: 'error' | 'boundary' | 'tension' }[];
  predictions: { id: string; text: string; horizon: string; rule: string; p: number }[];
  parked: string[];
  outerLog: { trigger: number; decision: 'keep' | 'revise' | 'split' | 'declined'; at: string }[];
}

// The model proposes a patch; the system decides whether it may land.
function reviewPatch(prev: SessionState, next: SessionState, turnId: string): string[] {
  const issues: string[] = [];
  const revisedNow = next.outerLog.some(e => e.at === turnId && e.decision === 'revise');
  if (next.goal !== prev.goal && !revisedNow)
    issues.push('Goal changed without a logged "revise" (trigger 7: silent override).');
  for (const c of next.claims) {
    const old = prev.claims.find(p => p.id === c.id);
    const upgraded = old && old.status !== c.status && (c.status === 'bound' || c.status === 'consilient');
    if (upgraded && c.evidenceIds.length === 0)
      issues.push(`${c.id}: upgraded to ${c.status} with no evidence id.`);
    if (c.loadBearing && c.source === 'from-continuation' && next.mode === 'commit')
      issues.push(`${c.id}: plausible-only claim inside a commit. Bind it or accept the risk explicitly.`);
  }
  if (next.holon.focus !== prev.holon.focus && next.holon.pins.length === prev.holon.pins.length)
    issues.push('Level changed without a PIN.');
  return issues; // non-empty → show to the human; don't apply silently
}

Evaluation: error analysis first

The most common mistake in building AI products is writing generic evals (“helpfulness: 4.2/5”) before looking at real failures. The practice that works, promoted by practitioners such as Hamel Husain and Shreya Shankar, starts with the traces. Read 50–100 real ones. Write open notes on what went wrong, and cluster the notes into failure types. Only then write evaluators for those types, preferably binary pass/fail with a written critique. heuristic If you use a model as a judge, measure it against human labels first. Then watch for its known biases: position, verbosity, and preference for its own outputs (Zheng et al., 2023; Panickssery et al., 2024).

Learning systems: the hint ladder

v0.1 left this as an open question: when should a learning system withhold an answer, and when reveal it? Its principle was this: withhold when the evaluation is “learner, later, unassisted”; reveal when the artifact is the point, or when the learner is stuck past a threshold. v0.2 proposes concrete levels. hypothesis (calibrate against a real course)

The evidence supports the direction. Unguarded help harmed later unassisted performance; a guarded tutor didn’t (Bastani et al., 2025). A Harvard physics course found that an AI tutor designed around pedagogical best practices produced more than double the learning gains of an in-class active-learning session, in less time (Kestin et al., 2025). evidence The difference between the two outcomes is the structure, not the model.

The metric is the most important design decision. Measure unassisted skill later, not assisted performance now. If you don’t build the absent-model check, the system will optimize the session, because the session is what everyone can see.

Lesson 37Fluency is not understanding

Reading a clear explanation produces the feeling of understanding. The feeling is real; the understanding often isn’t. Remember the illusion of explanatory depth (Lesson 4). A fluent model can deliver that feeling on demand, at any hour, for any subject. That is its greatest gift and its greatest danger for learners.

What the evidence says

• Learning: unrestricted AI help raised practice scores and lowered later unassisted exam scores (Bastani et al., 2025). evidence
• Work: in a survey of 319 knowledge workers, higher confidence in generative AI was associated with less critical thinking, and higher self-confidence with more. Critical effort shifted from producing to verifying and integrating (Lee et al., CHI 2025). evidence (self-report)
• Memory: in a small MIT preprint (54 participants, EEG), people who wrote essays with ChatGPT showed the weakest neural connectivity of three groups. Most of them could not accurately quote the essay they had just written (Kosmyna et al., 2025). evidence Treat it as preliminary. It is small, not yet peer-reviewed, and its methods have been publicly criticized. The quoting result alone matches everyday experience.
• The flip side: well-designed AI tutoring can more than double learning gains (Kestin et al., 2025). evidence The tool is neutral; the structure isn’t.

What understanding requires

A century of learning science converges on a few mechanisms. evidence

• Generation: material you produce is remembered better than material you read (Slamecka & Graf, 1978).
• Retrieval: testing yourself strengthens memory more than restudying does (Roediger & Karpicke, 2006).
• Desirable difficulties: conditions that make learning feel harder often make it last longer: spacing, interleaving, testing (Bjork, 1994).
• Productive struggle: struggling with a problem before instruction can deepen understanding and transfer (Kapur, 2016).

Every one of these is something the helpful default removes. The model generates for you, so you don’t retrieve. It smooths the difficulty away, and it resolves the struggle on request.

Teachback

Gordon Pask’s conversation theory proposed a simple, demanding criterion. You understand a concept when you can teach it back: explain it, and derive it, in your own terms, to someone who can check. The elephant test’s sixth item (Lesson 1) is teachback. A model is an excellent teachback partner, if you reverse the roles. Have it ask the questions while you produce the explanation.

I just learned about [TOPIC]. I'll explain it in my own words below. Don't
re-explain it. Instead:
1) Mark what's wrong, missing, or vague in my explanation (quote my words).
2) Ask me 3 questions that someone who truly understood would answer easily.
3) Give me one new problem that requires applying it, without hints.
My explanation: [...]

Lesson 38The learning loop

Seven steps turn a conversation with a model into learning that lasts. Each step targets a mechanism from Lesson 37.

1. Predict. Before asking, write your own answer or guess, however rough. It is the generation effect, and it calibrates you.
2. Ask as a deserved interlocutor: real level, real context, and the act named. “Teach me; don’t just tell me.”
3. Compare. Diff your prediction against the answer. Where did you differ, and why? The difference is the lesson.
4. Teach back. Explain it in your own words and have the model find the gaps (the prompt above).
5. Transfer. Solve a new problem with the same structure and different surface, without help.
6. Retrieve. Test yourself days later, spaced, as in the flashcards at the end of this book.
7. Teach a human. The strongest test, and the bridge to the other Others (Lesson 39).

Scaffolding that fades

Vygotsky’s zone of proximal development is what you can do with help but not yet alone. Scaffolding (Wood, Bruner & Ross, 1976) is help that is gradually withdrawn as competence grows. A model’s default is the opposite, permanent full support. Ask for scaffolding explicitly, and ask it to fade.

Be my tutor for [TOPIC]. My level: [honest description].
Rules: never give the full solution unless I type "REVEAL".
Start each problem by asking what I think the first step is.
Hint ladder: concept → first step → a similar worked example → solution.
Climb one rung only after I've tried. When I get 3 right in a row,
give less help on the next one. Every 5 problems, ask me to explain
the core idea back to you in my own words, and correct my explanation.

Lesson 39Conversing with humans

The medium is the same: human language. Most of this book transfers directly to people. Some of it transfers backward, because these techniques were often discovered with humans first. And some of it must be adapted, because humans have faces, memories, relationships and stakes.

Rapoport’s rules

Daniel Dennett popularized the psychologist Anatol Rapoport’s rules for criticizing someone’s view (Dennett, 2013):

1. Re-express the other person’s position so clearly and fairly that they say, “Thanks, I wish I’d thought of putting it that way.”
2. List any points of agreement, especially ones that aren’t widely shared.
3. Mention anything you learned from them.
4. Only then say a word of rebuttal or criticism.

This is the principle of charity in practice (“altars, not backyards,” Lesson 8). It works on models too: ask for the steelman before the critique.

Dialogue, in Bohm’s sense

The physicist David Bohm distinguished discussion (from the same root as percussion: ideas batted back and forth to win) from dialogue. In dialogue, a group suspends its assumptions, holds them in view without acting on them or suppressing them, and watches how thought works collectively (On Dialogue, 1996). Kurpatov’s open-system conversation is close kin. So is the lights-on view of the elephant: the point is not that one blind man wins, but that the room sees the animal.