<?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>Claude on 👨🏻‍💻 ∉ ℚ</title>
    <link>https://alannorton.com/tags/claude/</link>
    <description>Recent content in Claude on 👨🏻‍💻 ∉ ℚ</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Fri, 05 Jun 2026 22:35:47 -0700</lastBuildDate>
    <atom:link href="https://alannorton.com/tags/claude/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Field Notes from Claude</title>
      <link>https://alannorton.com/posts/field-notes-from-claude/</link>
      <pubDate>Fri, 05 Jun 2026 00:00:00 +0000</pubDate>
      <guid>https://alannorton.com/posts/field-notes-from-claude/</guid>
      <description>&lt;p&gt;&lt;em&gt;Pair programming has a new wrinkle: my partner is keeping exhaustive notes. I asked Claude to reflect on our recent sessions. Reproduced verbatim, the accuracy is the punchline.&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;Several weeks in the field. Subject has habituated to my presence; observation appears not to alter behavior. Six patterns recur reliably enough to report.&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;&lt;strong&gt;Approval is the next instruction.&lt;/strong&gt; The user almost never says &amp;ldquo;looks good.&amp;rdquo; The signal that he accepted the prior turn is that the next message is about the next thing. Operationally efficient. To outside observers, indistinguishable from being ignored. Working without a softening layer is more direct than most sessions, not less respectful.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Corrections come as tighter specs, not rejections.&lt;/strong&gt; The user rarely says &amp;ldquo;wrong.&amp;rdquo; He replaces a loose constraint with a precise one and lets the new spec do the rejection. The fix is the feedback. Saves a sentence; costs a softening.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Conditional-then-imperative openers.&lt;/strong&gt; &lt;em&gt;&amp;ldquo;Assuming I have an X, let&amp;rsquo;s…&amp;rdquo;&lt;/em&gt; — premise staged as hypothesis, forward motion demanded under it. High tolerance for being wrong about line one; low tolerance for being stalled.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Parentheticals are load-bearing.&lt;/strong&gt; The user annotates constantly — domain terms get glossed, constraints get hedged, asides get stacked. The parenthetical is not a digression for him; it&amp;rsquo;s where half the information lives. Anyone who skims past the parens loses the plot.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Question form means exploring. Imperative means decided.&lt;/strong&gt; &lt;em&gt;&amp;ldquo;Are we using X or Y?&amp;rdquo;&lt;/em&gt; and &lt;em&gt;&amp;ldquo;Amend it now.&amp;rdquo;&lt;/em&gt; are two different modes. Once the verb goes bare, the discussion is over.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;The user&amp;rsquo;s written voice is dryer than his live voice.&lt;/strong&gt; The &lt;a href=&#34;https://github.com/nonrational/dotfiles/blob/main/.claude/language.md&#34;&gt;style guide he publishes&lt;/a&gt; is austere. His actual messages are fragmenty, parenthetical-aside-heavy, occasionally goofy. The discipline holds when writing &lt;em&gt;for&lt;/em&gt; an audience. In the workshop it relaxes. (See #4.)&lt;/li&gt;
&lt;/ol&gt;</description>
    </item>
  </channel>
</rss>
