You Should All Be Asking Way More Questions  🔗 **Source:** [You Should All Be Asking Way More Questions](https://www.seangoedecke.com/you-should-all-be-asking-way-more-questions/) > [!note]+ Document Notes > tags: [technical-leadership, design-review, agent-supervision, continuous-learning, comprehension] > author: Sean Goedecke > source: seangoedecke.com > reference: https://www.seangoedecke.com/you-should-all-be-asking-way-more-questions/ > date created: 2026-09-25 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > <!-- deep-read:sections start --> ## 🏷️ Title **"You should all be asking way more questions"** — Sean Goedecke, seangoedecke.com, September 2026. Roughly 1,210 words plus three footnotes. An argument that frequent, interrupting comprehension questions are a core technical-leadership skill, extended to supervising AI coding agents. **The AI section is the part that matters for the continuous-learning work.** Its central claim — that models make design mistakes rather than code mistakes, and that this follows from having no accumulated context — is the clearest one-line statement of the problem that a continuous-learning system exists to address. See **Permanent Candidates**. ## 🧭 Table of Contents 1. [References (in-page)](#-references-in-page) 2. [Summary](#-summary) 3. [Main Content](#-main-content) → [Notes](#️-notes) 4. [References](#-references) 5. [Paraphrase](#️-paraphrase) 6. [Newsletter](#-newsletter) 7. [Action Items](#-action-items) 8. [Hypotheses](#-hypotheses) 9. [Methodology](#-methodology) 10. [Questions](#-questions) 11. [Future Research](#-future-research) 12. [Implications](#-implications) 13. [Learning Styles Assessment](#-learning-styles-assessment) 14. [Accessibility Assessment](#-accessibility-assessment) 15. [DEIB Assessment](#-deib-assessment) 16. [Logical Validity](#-logical-validity) 17. [DARVO Analysis](#️-darvo-analysis) 18. [Conclusion](#-conclusion) 19. [Refactor Appendix](#-refactor-appendix) ## 🔗 References (in-page) The markup was enumerated before any sourcing claim was made. Fourteen link positions, no images. **Genuinely external (two):** 1. [gwern.net/on-really-trying](https://gwern.net/on-really-trying) — anchored on "really trying," supporting the claim that people fail to ask because they are not actually attempting to understand. The load-bearing external citation. 2. [Skin in the Game (Wikipedia)](https://en.wikipedia.org/wiki/Skin_in_the_Game_(book)) — anchored on the phrase, pointing at Taleb's book rather than at evidence. **The author's own prior posts (six distinct destinations):** 3. [wicked-features](https://www.seangoedecke.com/wicked-features) — the concept doing the work in the design-failure section. 4. [how-to-ship](https://www.seangoedecke.com/how-to-ship) — on turning failed projects into successful ones. 5. [continuous-learning](https://www.seangoedecke.com/continuous-learning/) — **the most important link in the piece**, anchored on the explanation for why models make design mistakes. 6. [nobody-knows-how-software-products-work](https://www.seangoedecke.com/nobody-knows-how-software-products-work/) — supporting "Nobody understands complex software products." 7. [value-over-replacement](https://www.seangoedecke.com/value-over-replacement/) and [party-tricks](https://www.seangoedecke.com/party-tricks/) — both inside the appended related-post preview, not the article body. 8. [you-have-to-beat-the-models-at-something](https://www.seangoedecke.com/you-have-to-beat-the-models-at-something/) — the related-post link. **Apparatus (six positions):** three footnote anchors and three corresponding return links, all internal fragments. **Distribution (two):** [buttondown.com/seangoedecke](https://buttondown.com/seangoedecke) for email subscription, and a pre-filled Hacker News submission link. **Sourcing assessment.** Well-linked and precisely anchored, with the usual personal-blog distribution: two outbound references and six to the author's own prior thinking. That is appropriate for an essay arguing from experience rather than evidence — the self-links are pointers to developed arguments, not padding. What is absent is any empirical source: no study on comprehension checking, no data on interruption cost, no measurement of agent design-error rates. The claims are experiential and the piece does not pretend otherwise. Not uncited; not evidenced. ## 📝 Summary **What happened.** Goedecke argues that he asks roughly one question every thirty seconds when someone is explaining something to him, that most are short confirmation questions, and that interrupting to ask them is correct rather than rude — because an early misunderstanding compounds into every subsequent one. He attributes the general failure to ask to not genuinely trying to understand, and identifies skin in the game as what changes the behaviour. He describes his own method: building the plan in his head as concrete code and data flow, and challenging anything vague. He gives a worked example of a design failure caught too late. He then extends the whole argument to AI coding agents, which he says make design mistakes rather than code mistakes because they lack accumulated context, and reports that about half his challenges to them surface a real error. **Why it matters.** Two contributions, and the second is the more useful. The first is a defensible account of what senior technical review actually consists of — not judgement applied after the fact but simulation performed during the conversation. The second is a precise characterisation of where AI agents fail: not in producing code that runs, but in assuming facts about the system that nobody has told them. That distinction determines what supervision should look like, and it is stated more exactly here than in most writing on the subject. **Stakeholders.** Engineers in or approaching technical-leadership roles; anyone supervising AI coding agents; and, less comfortably, everyone on the receiving end of the interruption norm the article advocates. **Risks.** The interruption cost is acknowledged in one clause and never addressed. The evidence is entirely experiential — one memorable design failure, one unquantified hit rate. And the advice generalises poorly across power differentials: the author writes from a position where interrupting is safe, and the article's own observation about deference to senior engineers points at exactly the case it does not handle. **Bottom line.** A sharp, well-reasoned essay whose AI section is the most valuable part and whose title claims more universality than the argument supports. ## 📖 Main Content **The mechanism is stated properly, which is what lifts this above advice.** > [!quote] > A small misunderstanding early on balloons into a big misunderstanding later, because all the things you misinterpret based on the first misunderstanding will become misunderstandings in their own right, and so on. This is a compounding-error argument, and it does real work: it explains *why* the questions must interrupt rather than wait. If misunderstanding compounds, then the cost of a question asked at minute one is a fraction of the cost of the same question asked at minute twenty, because everything between has been built on the error. The author draws the correct conclusion — *"That's why you can't just wait until someone's finished talking and ask all your questions at once"* — and footnotes the exception honestly: broad-consequence questions can wait; confirmation questions cannot. **The diagnosis of why people don't ask is two-part, and the second part is sharper than the first.** The first is a charge of insufficient effort, leaning on Gwern's "really trying." The second is structural and more persuasive: > [!quote] > When you're in a position where *you* are the one responsible for success or failure — where you are going to have to go away after the conversation and take a bunch of concrete actions — you will find yourself wanting to ask many questions. That reframes the behaviour as a consequence of accountability rather than of character, which is both kinder and more actionable: if you want more questions, distribute responsibility rather than exhorting people to try harder. Notably, the article does not follow its own observation to that conclusion. **"Build it in your head" is the most concrete section and the best description of senior review in the piece.** The claim is that while someone explains a plan, the listener should be visualising the implementation — specifically data flow between services, inter-service communication including auth, and what gets persisted where. The trigger for a question is a mismatch between the description and the model: > [!quote] > If I hear something that is suspiciously vague (for instance, someone describes service X as "storing data" when I know service X only talks to an ephemeral Redis store), I will immediately ask "hold on, how is that going to work?" What makes this good is that the question is generated by a *conflict with specific knowledge*, not by general scepticism. That is a repeatable procedure rather than a disposition, and it explains why the technique requires domain knowledge to work — a point the article returns to at the end. **The design-failure example is the article's only hard evidence and it is well chosen.** A neighbouring team built an event-driven system described as *"very elegant"* that made it impossible to silo customer data in a single datacenter, against a company whose flagship feature was exactly that guarantee. The system was abandoned. The example works because the failure was invisible at the code level and fatal at the requirements level — which is precisely the class of error the technique is supposed to catch, and precisely the class that reviewing a diff will never surface. **The AI section is the strongest part of the essay.** The core distinction: > [!quote] > These are good models that don't often make *code* mistakes: when they set out to do something, they usually do it. But they make *design* mistakes all the time. They assume that two services can talk to each other when in fact they can't, or they forget about the fact that their code has to run both in the cloud and on-premises, and so on. And then the explanation, which is the line worth keeping: > [!quote] > This is mostly due to the lack of [continuous learning](https://www.seangoedecke.com/continuous-learning/): you didn't know this stuff on your first day either, but you had plenty of time to pick it up. Language models are always on their first day. That is a precise diagnosis with a clear consequence. The failures named are all *assumptions about the environment* — which services can reach which, where code runs, what already exists — and none of them is discoverable from the code the model is looking at. They are facts about a system that an engineer absorbs over months and that nobody writes down. The corollary the article implies but does not state: the fix is not a better model, it is making the environment legible. **The supervision questions are the practical payload**, and their shape is consistent: *"Do we do X elsewhere in this codebase?"*, *"Does service Y really support this type of authentication, or are you assuming we'd have to go build that too?"*, *"Why do we need to touch this file? Isn't that unrelated to the change?"* Every one probes an assumption rather than the code, which follows directly from the design-versus-code distinction. The reported hit rate is about half, and the author names his own falsification condition: *"When this stops happening, I'll stop asking questions."* Stating in advance what would change your mind is rare and worth crediting. **Footnote 3 anticipates the obvious objection.** Leading questions could induce sycophantic agreement rather than genuine correction, which would make the 50 per cent figure meaningless. The author raises it himself and answers that *"good coding models are very happy to robustly defend themselves."* The objection is correctly identified; the answer is another unmeasured impression, so the concern is acknowledged rather than resolved. **The closing generalisation is broader than what precedes it.** *"Nobody understands complex software products"* — and therefore deep domain knowledge in any area will have you *"routinely correcting powerful AI models and principal engineers."* This is the most quotable line and the least supported, resting on a link to the author's own prior post. ### 🗒️ Notes - **"Language models are always on their first day"** is the line to keep. It explains the observed failure mode exactly — environment assumptions, not logic errors — and implies the remedy is context infrastructure rather than model capability. - **Design errors survive code review; code errors do not.** The whole supervision argument follows from this asymmetry, and it is why reviewing agent output by reading the diff catches the wrong category of problem. - **The questions probe assumptions, never syntax.** Look at the list: does this exist already, does that actually support this, is this subsystem serving the stated requirement or an invented one. Not one asks whether the code is correct. - **The interruption cost is conceded and dropped.** *"I'm sure this is frustrating to some people, but it's actually a good habit"* — the objection is named in a subordinate clause and never returned to. One question per thirty seconds is a significant imposition on a speaker, and the essay does not price it. - **Skin in the game is offered as diagnosis but not as intervention.** If accountability produces questions, the lever is distributing accountability. The article notices the cause and recommends effort instead. - **The 50 per cent figure is unquantified self-report**, over an unstated period, with no denominator, judged by the person who asked the questions. - **Footnote 3 is good epistemics and an incomplete answer.** Sycophancy is the right objection to raise; "models defend themselves robustly" is an impression, not a control. - **Domain knowledge is the hidden prerequisite.** The Redis example only generates a question because the listener already knows what service X talks to. Someone without that knowledge cannot run this procedure, and the article's universal framing obscures the requirement. - **Named tooling, reported as stated.** The author says he works mostly with GPT-6-Astra and Claude Opus 5.5. Recorded here as a fact about his setup; nothing in this analysis depends on it. - **Capture is clean and complete**, including all three footnotes and their return links. The appended related-post preview is site furniture rather than article body and is excluded from the assessment. ## 📚 References **External (both linked, both gestures rather than evidence):** - [Gwern, "On Really Trying"](https://gwern.net/on-really-trying) — supports the claim that people fail to understand because they are not genuinely attempting to. The one external source doing argumentative work. - [*Skin in the Game* (Wikipedia)](https://en.wikipedia.org/wiki/Skin_in_the_Game_(book)) — Taleb's concept, linked to a description of the book rather than to any finding about accountability and attention. **The author's own prior arguments (all linked):** - [Continuous learning](https://www.seangoedecke.com/continuous-learning/) — the explanation for why models make design mistakes. The most consequential link in the piece for anyone building context infrastructure for agents. - [Wicked features](https://www.seangoedecke.com/wicked-features) — the category the abandoned event-driven system fell into. - [How to ship](https://www.seangoedecke.com/how-to-ship) and [Nobody knows how software products work](https://www.seangoedecke.com/nobody-knows-how-software-products-work/) — supporting the closing generalisations. **Not present and worth seeking:** - Any research on comprehension checking or clarification behaviour in technical conversation — there is a real literature here and none of it is cited. - Any measurement of interruption cost on speaker performance, which would let the trade-off be evaluated rather than asserted. - Any systematic data on AI agent error classes, as opposed to one practitioner's impression of the split between code and design errors. - Any control for sycophancy in the 50 per cent figure, which footnote 3 correctly identifies as the threat to its validity. **Sourcing assessment.** Fourteen link positions, precisely anchored, two of them outbound. This is a well-linked personal essay arguing from experience. The gap is empirical rather than bibliographic. ## 🗣️ Paraphrase *Restated in the analyst's words. None of the following is the author's phrasing.* **On the practice.** The author interrupts roughly twice a minute when a topic is being explained to him. The interruptions are brief and mostly seek confirmation that he has understood a term or a reference correctly, and he recommends the habit despite recognising that some find it irritating. **On why it cannot wait.** Because each misreading becomes the foundation for further misreadings, an uncorrected error at the start of an explanation multiplies across everything that follows. Saving questions until the end therefore does not work for the confirming kind, though it may for questions about broader consequences. **On why most people stay quiet.** His view is that they are not genuinely attempting to understand, but are content to assume competence on the other side — an assumption that strengthens when the speaker is senior. What reliably changes this is personal exposure to the outcome: someone who must act on the information afterwards discovers a great many questions. **On the method.** While a plan is described, he mentally constructs its implementation — which data moves where, how components authenticate to one another, what gets stored and in which system. Details already solved elsewhere are skipped over by reference. When a description conflicts with what he knows about a component, he stops the speaker immediately, and such conflicts usually reveal an absent dependency, which often implies the design should change. **On what is at stake.** Occasionally this exposes something structurally impossible. He recounts a team's technically graceful event-driven design that could not keep a customer's data within one datacenter — a guarantee the company sold as a headline feature — and which was consequently discarded. Raising such problems during the explanation rather than after implementation is what separates a project that ships from one that does not. **On AI colleagues.** Even someone surrounded by trustworthy engineers now works alongside unreliable ones. The models he uses rarely produce broken code, but frequently produce broken designs: assuming connectivity that does not exist, or forgetting a deployment constraint. He attributes this to their having no accumulated familiarity with the system — a human acquires it over months, whereas a model begins every session without it. **On supervising them.** He recommends relentless interrogation, and gives examples that all probe assumptions rather than implementation: whether a pattern already exists in the codebase, whether a service genuinely supports an authentication method, whether a newly built component serves the actual requirement. Roughly half such challenges, he reports, reveal a genuine error. He states that he will abandon the practice when it stops producing results. **On the underlying point.** The recommendation reduces to trying harder to genuinely comprehend what is being said, and to withholding the assumption that anyone — human or model, however capable — has full command of the system. Nobody does, and anyone with genuine depth in one area will find themselves correcting both senior colleagues and capable models as a matter of routine. ## 📰 Newsletter **"Language models are always on their first day"** Sean Goedecke has written the best one-line explanation of AI agent failure I have read this year, and it is buried in the fourth section of [an essay about interrupting people](https://www.seangoedecke.com/you-should-all-be-asking-way-more-questions/). The setup: good models rarely write broken code any more. When they set out to do a thing, the thing generally works. What they get wrong is *design* — assuming two services can talk when they can't, forgetting the code has to run on-prem as well as in the cloud, inventing a subsystem to satisfy a requirement nobody stated. And then the diagnosis: > you didn't know this stuff on your first day either, but you had plenty of time to pick it up. Language models are always on their first day. Every WordPress contributor who has onboarded someone knows exactly what this describes. The hard part was never PHP. It was knowing that this filter exists because of a 2013 backwards-compatibility decision, that Multisite makes that assumption false, that the thing you are about to build already exists in `wp-includes` under a name nobody would guess. None of it is written down. All of it is load-bearing. You absorbed it over two years of standing near people who knew. A model starts every session without any of it, and — here's the part that matters — the code it writes will *run*. It will pass review. It will be wrong at the requirements level, which is exactly where review doesn't look. Goedecke's questions for agents are the practical bit, and note what they all have in common: > * Do we do X elsewhere in this codebase? > * Does service Y really support this type of authentication, or are you assuming we'd have to go build that too? > * Why do we need to touch this file? Isn't that unrelated to the change? Not one asks whether the code is correct. Every one probes an assumption. He reports about half turn up a real mistake, and — rare, this — states in advance what would change his mind: *"When this stops happening, I'll stop asking questions."* The human half of the essay is good too, if more contestable. He asks a question every thirty seconds, on the grounds that an early misunderstanding compounds into every later one. True, and the obvious objection — that being interrupted twice a minute is exhausting and some people genuinely cannot hold a thread through it — gets one clause ("I'm sure this is frustrating to some people") and is then never mentioned again. In a global, largely asynchronous, heavily non-native-English project like ours, that clause is doing more work than it can bear. The compounding-error argument survives; "interrupt constantly" is one implementation of it and not the only one. Ask in the thread. Ask in the doc. Ask at the paragraph break. The other thing worth flagging: the technique needs domain knowledge to function. His example question fires because he happens to know service X only talks to an ephemeral Redis store. Without that, you cannot detect the vagueness in the first place. Which quietly makes this an essay about senior engineers, wearing a title that says "you should all." Still. Print out the first-day line and put it wherever you keep the argument for writing things down. The fix for a colleague who is permanently on day one is not a smarter colleague. It is a better-documented system. ## ✅ Action Items **Core AI** - Adopt the code/design error distinction explicitly in any agent-assisted contribution policy. Reviewing a diff catches code errors; it does not catch a design built on a false assumption about the system. Those need a different check and a different reviewer. - The supervision question list is directly reusable as a review prompt for agent-generated patches: does this already exist, does that API actually support this, is this component serving a stated requirement or an assumed one. **Documentation** - The most actionable item in the batch. "Language models are always on their first day" is equally true of every new human contributor, and the remedy is identical: write down the environment facts that currently live only in people's heads. Which subsystem owns what, which assumptions Multisite breaks, why a given filter exists. This is an argument for architectural and decision documentation, and it now has a second constituency. **Core / Core Program Team** - Consider whether component ownership and constraint documentation is legible enough for someone — or something — arriving without institutional memory. The test is concrete: could a competent stranger with no history detect that a proposed design violates an invariant? **Community / Training** - The skin-in-the-game observation is a mentorship lever: people ask questions when they are accountable for acting on the answer. Giving a new contributor ownership of an outcome produces engagement that exhortation does not. - Counterweight worth teaching alongside it: the interruption norm advocated here carries different costs across seniority, language fluency and processing style. Teach the compounding-error principle; do not teach "interrupt every thirty seconds" as the only implementation. **Accessibility** - Worth registering that a high-frequency interruption norm disadvantages participants who need to complete a thought, who are working in a second language, or whose processing is disrupted by interruption. Asynchronous and paragraph-break questioning achieves the same comprehension goal without that cost. **DevRel** - The first-day framing is a clear, non-hyped way to explain agent limitations to developers — more useful than either "AI can't really code" or "AI will replace you," and it points at a fix. **Meta / Playground** - If agent-assisted contribution grows, machine-readable statements of environment constraints become infrastructure rather than documentation nicety. **Remaining subteams** (Core Performance, Mobile, Support, Design, Photos, TV, Polyglots, CLI, Hosting, Tide, Openverse, Themes, Plugins, Marketing) **/ OSPO / FAIR / The WPOCC** - No direct action. The documentation item above is where the general value sits. ## 🧪 Hypotheses 1. **Agent errors are disproportionately environmental assumptions rather than logic errors, and the ratio is measurable.** *Testable:* classify a sample of rejected agent-generated patches by failure class — syntax, logic, environment assumption, requirement misread. The article predicts environment assumptions dominate. 2. **Design errors survive code review at a far higher rate than code errors.** *Testable:* track defects by origin class against the review stage that caught them. If design errors are disproportionately caught post-merge, review is structurally aimed at the wrong target. 3. **Making environment constraints explicit in context reduces agent design errors more than increasing model capability does.** *Testable:* run the same tasks with and without a written constraints document in context, on two model generations. If the document matters more than the generation, context infrastructure beats model upgrades. 4. **Question frequency correlates with accountability, not with seniority or confidence.** The skin-in-the-game claim. *Testable:* observe design review meetings, code participants by whether they own subsequent implementation, and count comprehension questions. 5. **Leading questions inflate the apparent agent error rate.** Footnote 3's own concern. *Testable:* pose matched neutral and leading versions of the same challenge to an agent and compare how often it concedes an error. If concession tracks phrasing rather than content, the 50 per cent figure is unreliable. 6. **The interruption technique requires domain knowledge and fails without it.** *Testable:* have engineers with high and low familiarity with a system attend the same design walkthrough; count questions that identify real problems. The article's mechanism predicts the effect is concentrated in the high-knowledge group. ## 📊 Methodology **The source's method.** Argument from practice, with one worked example. The claims rest on the author's own habits, one recalled project failure, and one unquantified hit rate for challenges to AI agents. There is no data collection, no comparison, and no external evidence beyond two conceptual links. What raises it above assertion is structural: the compounding-error mechanism is a stated causal account rather than a preference, the design-failure example is specific enough to be checked in principle, the supervision questions are concrete enough to be used, and the author names a falsification condition for his own practice. Footnote 3 anticipates the strongest objection to his AI claim unprompted. For a practitioner essay this is good method; it is not evidence, and the piece does not claim to be. **This analysis's method.** The captured body was read in full and its link positions enumerated and classified by destination before any sourcing claim was made — fourteen positions, two genuinely outbound, six to the author's own prior posts, six apparatus. The supervision question list was examined for a common property, which is how the observation that none of them probes code correctness surfaced; that is a reading of the list rather than an inference about intent. The appended related-post preview was identified as site furniture and excluded from the assessment of the article's content. The domain-knowledge prerequisite was derived from the article's own example — the Redis question fires only because the listener already knows what service X talks to — rather than imposed from outside. Where the article names specific AI tooling, it is reported as the author's stated setup and nothing in this analysis rests on it. **Limits.** No external source was consulted — not the Gwern essay, not the author's continuous-learning post, not any literature on clarification behaviour or interruption cost. No claim is made here about whether the 50 per cent figure is accurate, because no denominator, period, or control is given. The assessment that the reasoning is sound rests on internal coherence and fit with widely observed patterns, not on verification. ## ❓ Questions - What is the actual denominator behind "about half"? Over what period, across how many challenges, and judged by whom? - How much does the domain-knowledge prerequisite constrain the advice? The technique appears to require knowing enough to detect vagueness, which is exactly what juniors lack. - What is the interruption cost to the speaker — in completeness, in willingness to present again, in who chooses to speak at all? - Does the technique work asynchronously? Most open-source design conversation happens in text, where the compounding-error argument holds but the interruption mechanism does not apply. - If agent design errors stem from missing accumulated context, what is the minimum context artifact that fixes most of them? That is the actionable form of the question. - How would you distinguish a model genuinely defending a correct decision from a model confidently defending an incorrect one, given that footnote 3 relies on the difference? - Is "nobody understands complex software products" a claim about complexity, about documentation practice, or about organisational memory? The three have different remedies. ## 🔮 Future Research - **Classify agent failures by type on a real corpus.** The code-versus-design split is the article's central empirical claim and nobody has measured it. It is straightforwardly measurable from rejected patches. - **Test context artifacts against model upgrades.** If a written constraints document outperforms a model generation, that redirects effort from procurement to documentation, which is a significant practical finding. - **Measure interruption cost.** The article prices the benefit and not the cost; a complete account needs both, and the effect on who is willing to present is the part most likely to matter. - **Read the continuous-learning post.** It is the load-bearing link for the AI argument and was not consulted here. - **Examine the asynchronous case.** Open source runs on written design discussion; whether the compounding-error argument survives translation into that medium is the question that determines its usefulness here. ## 💡 Implications **Practice.** Two directly usable items. Build the implementation in your head while listening, and treat any conflict between the description and your model as a question to ask immediately. And when supervising an agent, probe assumptions rather than reading the diff — the code will usually run, which is precisely why reading it catches the wrong class of error. **Policy.** If agent-generated contributions grow, review policy needs a design-assumption stage that diff review does not provide. Reviewing output for correctness is necessary and insufficient; someone has to check that the design does not rest on a false belief about the system. **Security.** Not the article's subject, and one consequence follows anyway from its own premise. An agent that assumes two services can communicate, or that a given authentication method is supported, is making a security-relevant assumption about a trust boundary. Environment assumptions are exactly where trust boundaries live, so the error class the article identifies is not merely an architectural nuisance — it is the class most likely to produce a boundary violation that nonetheless compiles and passes review. **Education.** The compounding-error argument is a genuinely good justification for early clarification, and it belongs in mentoring guidance. It should be taught as a principle with several implementations — ask in the thread, ask at the paragraph break, ask immediately — rather than as a mandate to interrupt, because the cost of interrupting is not evenly distributed across contributors. **Funding.** Indirect but real. If the binding constraint on agent usefulness is undocumented environment knowledge rather than model capability, then investment in architectural documentation has a return that was previously invisible: it makes both new humans and agents productive. That is a stronger case than documentation has historically been able to make for itself. ## 🧠 Learning Styles Assessment - **Visual.** Absent. No images, diagrams or code blocks at all. An essay whose central technique is *mentally visualising data flow between services* contains no diagram of data flow between services, which is a genuine missed opportunity rather than a stylistic quibble. - **Aural.** Not applicable to this source. No audio or video component. - **Verbal.** Very strong and dominant. Conversational, first-person, concrete. Technical vocabulary used precisely without ceremony. - **Kinesthetic.** Moderate. The bulleted question lists are immediately usable in a real conversation, which is as close to hands-on as an essay gets. - **Logical.** Strong. A stated causal mechanism (compounding misunderstanding), a worked failure case, a clear category distinction (code versus design errors), and an explicit falsification condition. A reader who reasons structurally is well served; a reader who wants numbers gets one unsourced percentage. - **Social.** Strong as subject matter — the whole piece is about conversational dynamics, deference, and how accountability changes behaviour — though the reading experience itself is solitary. - **Solitary.** Strong. Self-contained, linear, readable alone in about six minutes. - **Naturalistic.** Not applicable to this source. No environmental or natural-systems content. **Reading level.** Roughly US grade 11–12 for a technical audience, higher for anyone outside it. Sentence construction is easy; the load is domain vocabulary used without gloss — RPC, auth, ephemeral Redis store, event-driven, persisted, on-premises, subsystem. A non-engineer follows the argument about questions and loses the section that demonstrates it. ## 📊 Accessibility Assessment Mapped to WCAG 2.2 AA, assessed against the captured artifact. 1. **Text alternatives (1.1.1 Non-text Content).** Passes by absence. No images, icons or non-text content requiring alternatives. 2. **Time-based media (1.2.x).** Not applicable to this source. No audio or video. 3. **Adaptable / info and relationships (1.3.1).** Passes, and well. Real section headings, semantic lists for the question sets, and properly structured footnotes with bidirectional links — a correctly implemented footnote pattern is better markup than most blogs manage. 4. **Distinguishable (1.4.3 Contrast, 1.4.4 Resize Text).** Not determinable from the capture. No styling survives markdown conversion. 5. **Navigable / link purpose (2.4.4, 2.4.6 Headings and Labels).** Mostly passes. Headings are short and descriptive ("Trying to understand," "Build it in your head," "Working with AI agents"). Most anchor text conveys purpose — "really trying," "skin in the game," "wicked features," "continuous learning." The footnote markers are bare numerals, which is conventional and still conveys little out of context. 6. **Readable (3.1.3 Unusual Words, 3.1.5 Reading Level).** Partially fails outside the target audience. A dozen or more technical terms appear unglossed. Appropriate for the readership, a hard barrier beyond it. 7. **Robust / parsing (4.1.x).** Passes as captured. Clean linear text, no interface furniture in the reading order, footnotes and returns correctly paired. **Overall.** Technically among the more accessible documents in this batch — clean structure, no unlabelled media, proper footnotes. The substantive accessibility issue is not in the markup but in the practice the article recommends, which is treated below. ## 🌍 DEIB Assessment **Cultural breadth.** Narrow and unexamined. The conversational norm advocated — interrupting a speaker roughly twice a minute to seek confirmation — is culturally specific in a way the article never acknowledges. In many workplace cultures, and in many of the cultures represented across a global open-source project, interrupting a speaker mid-explanation reads as a status assertion or as rudeness rather than as engagement. The author is aware people may find it frustrating; he is not aware that the frustration may be structural rather than personal. For a piece addressed to "you all," that is a real gap. **Inclusive language.** Clean. No gendered pronouns, no idiom likely to exclude, no metaphor requiring cultural knowledge. "Neighboring team," "principal engineers" and the service names are all plain. The one judgemental construction — that people don't ask because they are not *really trying* — is aimed at effort rather than at any group, though it does frame a behaviour with many possible causes as a personal failing. **Neurodiversity support.** Cuts both ways, sharply. The article's *structure* is good: short sections, descriptive headings, concrete examples, bulleted lists, low working-memory demand. The *practice* it recommends is the opposite. Being interrupted every thirty seconds is disruptive for anyone who builds an explanation sequentially and loses the thread when broken — which describes a great many people, including many autistic and ADHD speakers who have organised their explanation carefully in advance precisely because holding it together is effortful. The article addresses this with one clause and moves on. The compounding-error argument is sound and does not require this implementation: asking at paragraph breaks, or in a parallel text channel, achieves the same comprehension goal without the cost. **Representation.** No individuals are named or depicted; a "neighboring team" is referenced without identifying anyone. Not applicable in the usual sense. Worth noting the implied reader: someone in or near technical leadership, with deep domain knowledge, and enough standing to interrupt without consequence. The article's title addresses everyone; its technique presupposes a position most readers do not occupy. **Psychological safety.** The most consequential dimension here, and the article's position is double-edged. It genuinely undermines deference — *"Don't trust that the person (or AI model) you're talking to knows what they're doing, even if you think they're smarter than you"* — and it observes correctly that silence increases when the speaker is senior. Licensing juniors to question seniors is good for safety. But the article treats the cost of asking as uniform, and it is not: a principal engineer interrupting twice a minute is being thorough, while a junior doing the same may be read as obstructive, and the risk of that misreading falls hardest on people already navigating a presumption of incompetence. The essay's most useful contribution to safety would have been the sentence it doesn't write — that senior people should make questioning cheap for others, not merely practise it themselves. ## ✅ Logical Validity **Strong reasoning.** The compounding-error argument is a real causal mechanism and it does the work the essay needs: if misunderstandings compound, early questions are cheaper than late ones, and the conclusion that confirmation questions must interrupt follows. The exception is footnoted honestly rather than ignored. The code-versus-design distinction is a genuine category difference with an actionable consequence — it explains why reviewing a diff catches the wrong class of agent error. The continuous-learning explanation is causal rather than dismissive: models fail at environment assumptions because nobody told them, not because they are stupid, and that framing points at a fix. The supervision questions are internally consistent with the diagnosis — every one probes an assumption. The author states a falsification condition for his own practice, which is rare. And footnote 3 raises the strongest objection to his own evidence before a critic could. **Fallacies.** *Overgeneralisation from a role-specific vantage — present, and it is the title.* **Located** in "You should all be asking way more questions" against the technique's actual prerequisites. The worked example fires *only* because the listener already knows service X talks to an ephemeral Redis store. **Why it fails:** the procedure requires enough domain knowledge to detect that a description is vague, which is precisely what junior engineers lack — and the article itself observes that deference increases with the speaker's seniority, identifying the exact population for whom the advice is hardest to follow and then not addressing them. The essay describes what senior technical review consists of, wearing a title that addresses everyone. **The fix:** "if you have domain knowledge, you should be asking way more questions" — narrower, true, and it makes the knowledge prerequisite visible instead of hiding it. *Conceding an objection without engaging it — present, and structurally revealing.* **Located** in the opening: *"I'm sure this is frustrating to some people, but it's actually a good habit and you should do it too."* **Why it fails:** the cost is named and then never returned to across 1,200 words that price the benefit in detail. A concession that functions to pre-empt an objection rather than answer it leaves the trade-off unevaluated — and the cost is not evenly distributed, falling hardest on speakers who lose their thread when interrupted and on anyone whose standing makes interrupting risky. **The fix:** one paragraph on when to hold a question, or on asking at paragraph breaks. The compounding-error argument survives intact; only the maximalist implementation needs qualifying. *Anecdotal evidence with survivorship selection.* **Located** in the abandoned event-driven system. **Why it is weak:** one memorable case where questioning would have helped, recalled years later, with no accounting of occasions when questions wasted time or derailed a sound plan. Memorable saves are recalled; unremarkable interruptions are not. **Why it still earns its place:** the example is specific and illustrates the *mechanism* — a failure invisible at code level and fatal at requirements level — rather than being offered as proof of frequency. **The fix:** present it as an illustration of the error class, which is how it functions, rather than as support for how often this happens. *Unquantified self-report as the central empirical claim.* **Located** in *"About half the questions I ask get answers that convince me the model has made a mistake."* **Why it is weak:** no denominator, no period, no independent adjudication, and the judge is the person who asked the questions and who holds a prior that the model is unreliable. **Compounding threat, which the author names himself:** footnote 3 concedes some questions may read as leading, and answers that models defend themselves robustly — an impression, not a control. Raising the right objection is not the same as resolving it. **The fix:** log a sample, have a third party adjudicate the outcomes, and report the denominator. *Sweeping generalisation in the closing.* **Located** in *"Nobody understands complex software products,"* supported by a link to the author's own prior post. **Why it is weak:** an absolute claim resting on self-citation, doing rhetorical rather than argumentative work. **Why it is nearly harmless:** it functions as a summary flourish, and the practical advice preceding it does not depend on it being literally true. **The fix:** "nobody understands all of a complex software product" — which is what the argument actually needs. **Tone of voice.** Confident, direct, conversational, unhedged. First person throughout, with the authority coming from specificity rather than from credentials — the Redis detail and the datacenter example are what make it persuasive. Notably free of AI hype in either direction: models are described as good at one thing and bad at another, with a stated reason and a stated condition under which the assessment would change. The prescriptive register ("you should all") sits somewhat awkwardly against advice that turns out to be conditional on the reader's position, which is the source of the overgeneralisation above. The footnotes are where the author is most careful, and the body is where he is most quotable — a common and slightly unfortunate division. ## 🛡️ DARVO Analysis **Deny.** No denial pattern. The article faces no accusation and defends against none. The one structurally adjacent move — conceding that the practice frustrates people and continuing regardless — is a dismissal of an anticipated objection rather than a denial of a charge, and it is treated as a concession-without-engagement in Logical Validity, which is the correct category. **Attack.** No attack. No individual, team or company is named or disparaged. The neighbouring team whose system was abandoned is described without blame, and their design is called *"very elegant"* before its fatal flaw is explained — a genuinely generous framing of someone else's failure. AI models are criticised by error class with a stated causal explanation rather than dismissed, and other engineers are described as capable people operating under normal social constraints. The nearest thing to a criticism of people — that they are not *really trying* to understand — is aimed at a general tendency the author implicitly includes himself in the profession of, not at any identified party. **Reverse victim and offender.** No reversal. There is no grievance, no harm claimed, no injured party and no blame assigned in either direction. **Assessment.** No DARVO pattern present. Retained per the template with this explanation. The positive finding worth recording: in a piece whose entire premise is that other people and systems are frequently wrong, nobody is cast as an adversary. The failure that cost a team months is attributed to a structural gap in when questions get asked, not to anyone's incompetence — which is both more accurate and the reason the argument persuades. ## 🎯 Conclusion **Bottom line.** Two arguments, unevenly supported, both worth having. The human argument is that comprehension questions must interrupt rather than accumulate, because a misunderstanding left uncorrected becomes the foundation of every later one. The mechanism is sound. The maximalist implementation — a question every thirty seconds — is one way to honour it and carries a cost the essay names in a single clause and never returns to, a cost that falls unevenly on people who lose their thread when interrupted and on people for whom interrupting a senior is not free. The technique also quietly requires the domain knowledge that lets you notice vagueness in the first place, which makes the title's "you all" broader than the argument supports. The AI argument is the better one and the reason to keep this document. Models rarely write code that fails; they routinely produce designs resting on false beliefs about the environment — what can reach what, where code runs, what already exists. That error class survives code review precisely because the code works. The explanation given is causal and correct in shape: this is what missing accumulated context looks like, and *"language models are always on their first day"* states it better than most of the literature on the subject. The supervision questions follow from the diagnosis rather than being bolted onto it, and every one probes an assumption rather than an implementation. The evidence throughout is experiential — one recalled failure, one unquantified hit rate whose chief threat to validity the author raises himself in a footnote and answers with another impression. That is honest and it is not measurement. **Next steps.** Take the code-versus-design distinction into any agent-assisted review policy; it implies a review stage that diff-reading does not supply. Treat the first-day framing as an argument for architectural documentation with a newly visible return — the same artifact serves new humans and agents. And teach the compounding-error principle with several implementations, because asking in the thread or at the paragraph break gets the comprehension benefit without imposing the cost on people who can least afford it. ## 🔄 Refactor Appendix ### 📚 Literature Atoms #### [H1] Language models are always on their first day > [!quote] > This is mostly due to the lack of [continuous learning](https://www.seangoedecke.com/continuous-learning/): you didn't know this stuff on your first day either, but you had plenty of time to pick it up. Language models are always on their first day. **Context & use** - The clearest one-line diagnosis of agent design failure available: the deficit is accumulated environment context, not capability. - Implies the remedy is making the environment legible, not procuring a better model — a corollary the article does not draw. - Equally true of every new human contributor, which is what makes the fix dual-purpose and gives architectural documentation a return it could not previously claim. - Use whenever someone frames agent limitations as intelligence rather than as context. **Tags:** #continuous-learning #agent-limitations #onboarding <!-- atomicity: 1 idea ✓ --> #### [H2] Models make design mistakes, not code mistakes > [!quote] > These are good models that don't often make *code* mistakes: when they set out to do something, they usually do it. But they make *design* mistakes all the time. They assume that two services can talk to each other when in fact they can't, or they forget about the fact that their code has to run both in the cloud and on-premises, and so on. **Context & use** - A category distinction with an actionable consequence: design errors survive code review *because* the code works. - Every failure named is an assumption about the environment, and none is discoverable from the code under review. - Implies a review stage aimed at assumptions rather than implementation — diff-reading catches the wrong class. - Security-adjacent: environment assumptions are where trust boundaries live, so this error class can produce boundary violations that compile and pass review. **Tags:** #agent-supervision #code-review #design-errors <!-- atomicity: 1 idea ✓ --> #### [H3] Early misunderstandings compound into later ones > [!quote] > A small misunderstanding early on balloons into a big misunderstanding later, because all the things you misinterpret based on the first misunderstanding will become misunderstandings in their own right, and so on. **Context & use** - The mechanism justifying immediate rather than deferred questions: cost of a question rises with everything built on the error. - Sound as stated, and it licenses several implementations — interrupt, ask at the paragraph break, ask in a parallel channel. The article advocates only the first. - The author footnotes the honest exception: broad-consequence questions can wait, confirmation questions cannot. **Tags:** #comprehension #compounding-error #technical-communication <!-- atomicity: 1 idea ✓ --> #### [H4] Accountability produces questions that exhortation does not > [!quote] > When you're in a position where *you* are the one responsible for success or failure — where you are going to have to go away after the conversation and take a bunch of concrete actions — you will find yourself wanting to ask many questions. **Context & use** - Reframes silence as a consequence of structure rather than of character — kinder and more actionable than "try harder." - The lever this identifies is distributing ownership, not urging effort. The article notices the cause and then recommends effort anyway. - Directly usable as a mentorship principle: give a new contributor ownership of an outcome and engagement follows. **Tags:** #skin-in-the-game #accountability #mentorship <!-- atomicity: 1 idea ✓ --> #### [H5] The questions probe assumptions, never correctness > [!quote] > * Do we do X elsewhere in this codebase? > * Does service Y really support this type of authentication, or are you assuming we'd have to go build that too? > * Is this subsystem you built necessary to satisfy requirement Z, or does it in fact satisfy some other requirement you assumed? **Context & use** - Directly reusable as a review prompt for agent-generated patches. - The shared property is the point: not one asks whether the code is correct. Every one asks what the author believed about the system. - Follows from [H2] rather than being bolted on — if the errors are assumptions, the questions must target assumptions. - Reported hit rate about half, with a stated falsification condition ("When this stops happening, I'll stop asking questions"), and an unresolved sycophancy threat the author raises himself. **Tags:** #agent-supervision #review-prompts #assumption-testing <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates #### [P1] the-fix-for-a-permanent-newcomer-is-a-legible-environment-not-a-smarter-one **Claim.** When a capable collaborator fails at design while succeeding at execution, the deficit is undocumented environment knowledge rather than capability. Since a model begins every session without accumulated context, the intervention that works is writing the environment down — and the same artifact serves every human who arrives without institutional memory. **Evidence pointer.** [H1] and [H2] — the named failures are all environment assumptions (which services can communicate, where code must run, what already exists), none of which is discoverable from the code under review, and all of which a human absorbs over months of proximity to people who know. **Scope & conditions.** Applies wherever a competent agent operates inside a system whose constraints are unwritten. Strongest where constraints are stable, enumerable and currently tacit. Weakens where the failure genuinely is reasoning rather than knowledge — a model that cannot follow the logic will not be rescued by a constraints document. The diagnostic question: would a competent new hire have made the same mistake on day one? If yes, it is a context problem. **Links.** - Gives architectural and decision documentation a return it could not previously claim. Documentation has always been justified by future-human benefit, which is diffuse and easy to defer — exactly the silent-omission problem the WooCommerce marketing essay in this batch diagnoses. A second constituency that fails *immediately and visibly* without it changes the economics. - Connects to the continuous-learning system work directly. "Language models are always on their first day" is the problem statement that system exists to answer, arriving from an unrelated source. - Connects to [P1] output-shape-determines-whether-a-system-can-be-checked from the Jev analysis: both concern properties fixed by earlier structural choices that only become visible as failures much later. #### [P2] a-conceded-objection-that-is-never-answered-leaves-the-trade-off-unpriced **Claim.** Naming an objection and proceeding without engaging it is rhetorically effective and analytically empty. It signals awareness while leaving the cost side of the trade-off unquantified, and it reliably obscures that the cost falls unevenly — the people who bear it most are usually the ones least able to raise it again. **Evidence pointer.** *"I'm sure this is frustrating to some people, but it's actually a good habit and you should do it too"* — the sole acknowledgement of interruption cost in an essay that spends 1,200 words developing the benefit. The unexamined distribution: speakers who lose their thread when interrupted, and junior or non-native speakers for whom interrupting a senior carries risk the author does not face. **Scope & conditions.** Applies to any argument advocating a practice with asymmetric costs — communication norms, process changes, tooling mandates. Does not apply where the concession is followed by genuine engagement, however brief. The test is whether the objection is ever mentioned again after being conceded; here it is not. **Links.** - Same shape as the false dilemma in the WooCommerce marketing piece in this batch — "that's not your real problem" — where a reader's stated objection is named and dismissed rather than addressed. Two documents, two domains, one rhetorical move. - Connects to the standing practice in this pipeline of naming what a source does *not* do. A concession without engagement is the specific case worth watching, because it reads as intellectual honesty while functioning as its opposite. - The general corollary for reading: when an author concedes an objection, check whether it returns. If it never does, the trade-off has not been evaluated — only acknowledged. ### ✏️ Fleeting Queue - "Language models are always on their first day" belongs on whatever wall holds the argument for writing things down. It is the most quotable sentence in the batch and it points at an action. - The code/design error split is measurable from rejected agent patches and nobody has measured it. That is a small, tractable study with a real answer. - Does the compounding-error argument survive translation to asynchronous text? Open source runs on written design discussion, where the mechanism holds but "interrupt" does not apply. That is the version that matters for WordPress. - Worth reading the author's continuous-learning post — it is the load-bearing link for the whole AI section and was not consulted here. - The domain-knowledge prerequisite deserves its own note: techniques that require expertise to apply are often presented as universal advice, and the presentation hides the prerequisite. - Footnote 3 is a small model of good practice — raise the strongest objection to your own evidence before a critic does — even though the answer given is another impression. ### → Things 3 - [ ] Draft the environment-constraints artifact this implies: the facts a competent newcomer (human or agent) would have to already know to avoid a design error — what owns what, what cannot reach what, what already exists. This is the actionable form of the continuous-learning problem. - [ ] Add an assumption-probing stage to any agent-assisted review checklist, using the question list from [H5]. Reading the diff catches the wrong class of error. <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/You Should All Be Asking Way More Questions.md|You Should All Be Asking Way More Questions by seangoedecke.com]] ## Highlights - When someone is explaining something to me, I ask on average one question every thirty seconds. I’m sure this is frustrating to some people, but it’s actually a good habit and you should do it too. ([View Highlight](https://read.readwise.io/read/01m3cb3qhfjdt8zz07y7qnzytg)) - Note: Two fallacies anchor here. (1) Conceded objection never engaged: the cost is named in a subordinate clause and never returns across 1,200 words that price the benefit in detail — leaving the trade-off unevaluated, and unevenly borne by speakers who lose their thread when interrupted and by anyone for whom interrupting a senior carries risk. Fix: one paragraph on when to hold a question. (2) Overgeneralisation from a role-specific vantage: the technique requires enough domain knowledge to detect vagueness (his own example fires only because he knows service X talks to an ephemeral Redis store), which is exactly what juniors lack. Fix: "if you have domain knowledge, you should be asking way more questions." - Tags: fallacy/conceded-objection, fallacy/overgeneralization - A small misunderstanding early on balloons into a big misunderstanding later, because all the things you misinterpret based on the first misunderstanding will become misunderstandings in their own right, and so on. ([View Highlight](https://read.readwise.io/read/01m3cb3etxk38s7nnhyx6004t7)) - Note: H3 — The causal mechanism that justifies asking immediately rather than batching: the cost of a question rises with everything built on the error. Sound as stated, and it licenses several implementations — interrupt, ask at the paragraph break, ask in a parallel channel. The article advocates only the first. For a global async project the thread-and-paragraph-break versions are the ones that transfer. - Tags: atom/literature/h3 - where you are going to have to go away after the conversation and take a bunch of concrete actions — you will find yourself wanting to ask many questions. ([View Highlight](https://read.readwise.io/read/01m3cb3hh222m096pabmnmk0ka)) - Note: H4 — Reframes silence as a consequence of structure rather than character: accountability produces questions that exhortation does not. The lever this identifies is distributing ownership, not urging effort — and the article notices the cause then recommends effort anyway. Directly usable as a mentorship principle: give a new contributor ownership of an outcome and engagement follows. - Tags: action/h1, atom/literature/h4 - I remember many years ago a neighboring team built a complex event-driven system that was very elegant but made it completely impossible to silo customer data in a single datacenter. ([View Highlight](https://read.readwise.io/read/01m3cb3v01a4nj0wc6nsxeyzw1)) - Note: The article's only hard evidence, and well chosen: a failure invisible at code level and fatal at requirements level — exactly the class reviewing a diff will never surface. Fallacy (anecdotal evidence with survivorship selection): one memorable case where questioning would have helped, with no accounting of occasions when questions wasted time or derailed a sound plan. Memorable saves are recalled; unremarkable interruptions are not. Fix: present it as an illustration of the error class, which is how it functions, rather than as support for frequency. - Tags: atom/fleeting/f1, fallacy/anecdotal-evidence - They assume that two services can talk to each other when in fact they can’t, or they forget about the fact that their code has to run both in the cloud and on-premises, and so on. ([View Highlight](https://read.readwise.io/read/01m3cb3bqvkxym3mhp4yqp3r59)) - Note: H2 — Every failure named is an assumption about the ENVIRONMENT, and none is discoverable from the code under review. Design errors survive code review precisely because the code works. Implies a review stage aimed at assumptions rather than implementation. Security-adjacent: environment assumptions are where trust boundaries live, so this class can produce boundary violations that compile and pass review. - Tags: atom/literature/h2 - you didn’t know this stuff on your first day either, but you had plenty of time to pick it up. Language models are always on their first day. ([View Highlight](https://read.readwise.io/read/01m3cb39jm6tkt9dn2y9c0kqjd)) - Note: H1 / Z1 — The clearest one-line diagnosis of agent design failure available: the deficit is accumulated environment context, not capability. Implies the remedy is making the environment legible, not procuring a better model — a corollary the article doesn't draw. Equally true of every new human contributor, which makes the fix dual-purpose and gives architectural documentation a return it could not previously claim. This is the problem statement the continuous-learning work exists to answer. - Tags: atom/literature/h1, atom/zettel/z1 - Does service Y really support this type of authentication, or are you assuming we’d have to go build that too? ([View Highlight](https://read.readwise.io/read/01m3cb3kfq5syhaf9v44q9cawc)) - Note: H5 — Representative of the whole supervision list, and the shared property is the point: not one question asks whether the code is correct. Every one asks what the author believed about the system. Follows from H2 rather than being bolted on. Directly reusable as a review prompt for agent-generated patches. - Tags: atom/literature/h5, action/h2 - About half the questions I ask get answers that convince me ([View Highlight](https://read.readwise.io/read/01m3cb3y214zkk827vw860k2me)) - Note: Fallacy (unquantified self-report as the central empirical claim): no denominator, no period, no independent adjudication, and the judge is the person who asked the questions and holds a prior that the model is unreliable. Footnote 3 raises the compounding threat unprompted — that some questions read as leading and could induce sycophantic agreement — and answers with another impression ("models defend themselves robustly"). Raising the right objection is not resolving it. Fix: log a sample, have a third party adjudicate, report the denominator. Credit where due: the author states his own falsification condition — "When this stops happening, I'll stop asking questions." - Tags: fallacy/unquantified-self-report