# Watching a System Run Beats Reading It ## Claim Where behaviour emerges from ordering and dispatch rather than from any single passage, observing execution produces an accurate model and reading the source produces a plausible one. <!-- atomicity: 1 idea ✓ --> ## Evidence **Source**: [[3. Resources/Readwise/Articles/Debug WordPress Like a Pro Xdebug With WordPress Studio]] — Elliott Richmond > [!quote] > You stop reading the core source code and guessing, and you actually watch it running instead. The context is stepping into WordPress core from a breakpoint: watching a hook fire, seeing which functions hang off it, following the chain through `apply_filters`. None of that is legible from the source, because the source does not contain the answer. Which callbacks are registered, in what priority, by which plugins, on this request — that is runtime state assembled from many files, and reading any of them yields a guess. The demonstration earlier in the same source is the compact version. A plugin meant to flag posts over 300 words flags every post. The code reads correctly. One breakpoint at the comparison shows the word count is a **string** where a number was assumed. Reading the line produces the wrong answer indefinitely, because the defect is not in the text; it is in a value the text does not display. The general property: reading gives you what the code *says*, and inspection gives you what it *did*. When those diverge, only one of them is evidence. ## Scope & conditions - **Holds** where behaviour depends on runtime state, registration order, dynamic dispatch, or configuration — hook and filter systems, event buses, dependency injection, middleware chains, async scheduling. - **Breaks** where the question is about intent rather than behaviour. Why the code is shaped this way is answered by reading, by history, or by asking a person; execution shows only what happens. - **Breaks** where the path cannot be reached — dead code, rare error branches, conditions you cannot reproduce. Reading is what you have left. - **Weakens** where observation changes the behaviour, or where a single observed run is unrepresentative. One trace is a sample, not a proof. - **Sharpens** as a system grows, because the gap between local text and global behaviour widens with the number of participants. ## Links - [[3. Resources/Permanent Notes/An Audit Trail Is Trustworthy Only When It Is a By-Product of the Work]] — because extends: an execution trace is the by-product record in its purest form. It cannot be authored separately from the act, which is exactly why it is evidence. - [[3. Resources/Permanent Notes/The Maker Should Not Grade Its Own Homework]] — because extends: the checker's evidence must be re-derived rather than re-read. Stepping through is the re-derivation; reading the source is re-reading the maker's account of itself. - [[3. Resources/Permanent Notes/Silent Failures Cost More Than Loud Ones]] — because evidence-for: the string-versus-number bug is silent by construction. Inspection is how silence is converted into a visible fact. - [[3. Resources/Permanent Notes/Fluency Makes Small Errors Harder to Catch Than Large Ones]] — because extends, and this is the sharpest pairing: correct-looking code is fluent output. Reading rewards plausibility; execution does not care how plausible the code looks. - [[3. Resources/Permanent Notes/Pre-Registration Is What Separates a Finding From a Story]] — because extends: both refuse a conclusion that was never exposed to disconfirmation. A read-off explanation cannot fail; a trace can. - [[3. Resources/Permanent Notes/Encoding What Good Looks Like Is What Makes Agent Verification Trustworthy]] — because applies-in: an encoded expectation is only checkable against observed behaviour. - [[3. Resources/Permanent Notes/A Nondeterministic Check Breaks the Loops Stop Condition]] — because contrasts: observation is the better evidence and it inherits a sampling problem that reading does not have. - [[AI & the Future of Knowledge Work MOC]] — because applies-in. - [[3. Resources/MOCs/Personal Knowledge Management MOC]] — applies-in: the MOC lists this note under Source evaluation and triage (added 2026-08-16). ## Implications - For onboarding to a large codebase, a debugger beats a documentation tour. The hard part of WordPress is execution order, and execution order is the one thing the documentation cannot show you. - For agent and AI-assisted work this is the operative rule: a generated explanation of what code does is a reading, and readings are exactly what generation is good at producing plausibly. Run it. - It gives a concrete stopping rule for investigation — when reading has produced a hypothesis, the next step is to observe rather than to read further. Additional reading tends to increase confidence without adding evidence. - The counterweight worth holding: a trace is one sample. Observation defeats plausible-but-wrong readings and does not by itself establish generality. ## Open Questions - Does debugger-led onboarding measurably outperform documentation-led onboarding on comprehension of execution order? - How many traces are needed before an observed behaviour can be treated as general? - Can the same discipline be applied to agent reasoning — instrumenting what a model actually did rather than reading its account of what it did? ## Source - [[3. Resources/Readwise/Articles/Debug WordPress Like a Pro Xdebug With WordPress Studio]] — stepping into core to watch a hook fire, and the string-versus-number bug found by inspection