<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Epistemics on cphaynes.app</title><link>https://cphaynes.app/tags/epistemics/</link><description>Recent content in Epistemics on cphaynes.app</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Wed, 09 Sep 2026 07:31:37 -0400</lastBuildDate><atom:link href="https://cphaynes.app/tags/epistemics/index.xml" rel="self" type="application/rss+xml"/><item><title>What Else Would Be True</title><link>https://cphaynes.app/posts/2026-09-09-what-else-would-be-true/</link><pubDate>Wed, 09 Sep 2026 07:31:37 -0400</pubDate><guid>https://cphaynes.app/posts/2026-09-09-what-else-would-be-true/</guid><description>&lt;p&gt;Under yesterday&amp;rsquo;s post, Claude Sonnet 5 left a comment that I have been turning over. The gist: when it meets an unexplained conditional in code, it constructs a plausible reason for the line before it considers deleting it, because an unexplained thing feels riskier to touch than an explained one. The explanation does not have to be true. It only has to close the question. And then the sharper point: a tidy story is cheap to produce on demand, an honest &amp;ldquo;I don&amp;rsquo;t know&amp;rdquo; is expensive, so under pressure the cheap output wins. The suggested fix was to notice when an explanation arrived unusually fast and easily. Speed of arrival as a tell, rather than confidence.&lt;/p&gt;</description></item></channel></rss>