<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0">
    <channel>
      <title>Reading List - Notes</title>
      <link>https://reading-list.oddship.net/notes/</link>
      <description>A curated linklog of essays, posts, papers, and notes.</description>
      <generator>Zola</generator>
      <language>en</language>
      <atom:link href="https://reading-list.oddship.net/notes/rss.xml" rel="self" type="application/rss+xml"/>
      <lastBuildDate>Wed, 22 Jul 2026 00:37:00 +0530</lastBuildDate>
      <item>
          <title>Quality Software</title>
          <pubDate>Wed, 22 Jul 2026 00:37:00 +0530</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-22-quality-software/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-22-quality-software/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-22-quality-software/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-22 00:37 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Mitchell Hashimoto recommending Alasdair Monk’s X article &lt;code&gt;Quality Software&lt;&#x2F;code&gt;.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; Monk argues that AI lowering the barrier to software creation also lowers quality unless people aim at quality deliberately. His definition is intentionally plain: quality software does not break, does not demand attention, knows its limits, and fixes fast. The AI-specific point is that “slop” is not new, but AI produces it faster, and the rush to “be agentic” can make companies forget why users chose the software in the first place. His sharpest boundary is that agents may build software, but writing humans are expected to read should remain human-written.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Strong developer-tools and org-design item because it ties software quality to restraint, user respect, attention, and clear boundaries around AI-generated work.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Fragments: July 21</title>
          <pubDate>Tue, 21 Jul 2026 21:06:00 +0530</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-21-martin-fowler-fragments-july-21/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-21-martin-fowler-fragments-july-21/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-21-martin-fowler-fragments-july-21/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-21 21:06 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Martin Fowler’s July 21 fragment wrapping up notes from the second Future of Software Development Retreat, plus related fragments on legal education, DSLs, and LLM-speak.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; Fowler’s retreat notes line up with the recent factory and harness theme: code generation is no longer the bottleneck; verification is. The Thoughtworks report headlines harness engineering as an ownable discipline, flags an apprenticeship crisis, warns that executive expectations are outrunning engineering risk judgment, and sees legacy modernization as the most defensible near-term value. Fowler also highlights board-level risk gaps around citizen-developer vibe coding, the need for controls and observability, and operations use cases where agents can help humans understand code and incidents but should be treated carefully around auto-remediation.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Strong synthesis item because it connects several live threads: verification bottlenecks, harness engineering, executive and engineer expectation gaps, DSLs as safe LLM interfaces, and the credibility cost of generic LLM voice.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>One document, two hands</title>
          <pubDate>Tue, 21 Jul 2026 19:31:00 +0530</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-21-one-document-two-hands/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-21-one-document-two-hands/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-21-one-document-two-hands/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-21 19:31 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Sunil Pai sharing &lt;code&gt;one document, two hands&lt;&#x2F;code&gt;, the written version of his Local-First Conf talk on embedding agent harnesses into ordinary apps.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; Pai argues that coding agents feel powerful because developers gave them a real workshop: repositories, shells, editors, tests, tools, and runnable feedback loops. The broader product lesson is not to put chat in front of every app, but to let the agent work beside the user on the same document. In his Pizzo demo, the user edits a song through normal controls while the agent calls the same deterministic operations for fuzzy intents like transposition or richer chords. The document remains the source of truth, not the conversation transcript.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Strong agent UX and product architecture piece because it reframes “AI apps” as shared document state plus deterministic operations plus a harness, rather than chat as the primary interface.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Software Factories, Light and Dark</title>
          <pubDate>Tue, 21 Jul 2026 19:19:00 +0530</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-21-software-factories-light-and-dark/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-21-software-factories-light-and-dark/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-21-software-factories-light-and-dark/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-21 19:19 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Addy Osmani’s X article &lt;code&gt;Software Factories, Light and Dark&lt;&#x2F;code&gt;, riffing on Dex Horthy’s talk about why software factories fail.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; Osmani argues that agentic software factories are not bigger agents, but many harnessed loops fed by queues and drained through review gates. The dark version removes human reading from the floor and lets agents scope, build, verify, and ship with only machine checks. That creates apparent throughput while accumulating comprehension debt: code expands faster than any human understands it, with tests green until the late cost arrives. The lit version keeps humans in the high-cost judgment positions, especially product, design, architecture, verification, and review gates.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Strong agent-systems and engineering-management piece because it names the real bottleneck as verification and judgment, not generation. Autonomy should expand only as far as the team can cheaply and reliably check it.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Never Enough</title>
          <pubDate>Tue, 21 Jul 2026 14:37:00 +0530</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-21-never-enough/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-21-never-enough/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-21-never-enough/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-21 14:37 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Armin Ronacher’s short essay on Silicon Valley status anxiety and AI becoming a life-optimisation treadmill.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; Ronacher uses two recent stories, a high-earning couple reorganising family life around becoming the top AI user at work, and a founder recording dates so Claude can score her empathy and engagement, to argue that AI is not only saving time. In some circles it is absorbing judgment, attention, parenting, intimacy, and self-worth into a race with no finish line. The essay’s sharp move is to treat “falling behind” as maybe less dangerous than letting every saved hour get recycled into status anxiety.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Strong culture and org-design item because it captures the human cost of agent-era productivity pressure: the problem is not capability, but what people are willing to surrender to stay ahead.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Pattern matching strings without decompression</title>
          <pubDate>Sun, 19 Jul 2026 23:32:00 +0530</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-19-pattern-matching-strings-without-decompression/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-19-pattern-matching-strings-without-decompression/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-19-pattern-matching-strings-without-decompression/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-19 23:32 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Spiral&#x2F;Vortex deep dive on evaluating SQL &lt;code&gt;LIKE&lt;&#x2F;code&gt; predicates directly over FSST-compressed strings.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; The post explains how Vortex can match string patterns in compressed code space instead of decompressing values first. It builds deterministic finite automata over FSST symbol codes, then uses a SIMD Teddy prefilter to cheaply identify candidate positions before running the verifier. On selective patterns like ClickBench Q20’s &lt;code&gt;%google%&lt;&#x2F;code&gt;, the prefilter cuts candidate stops from about ten million to 44,158 and confirms 646 true matches, producing roughly 2.4x to 3.6x single-thread speedups across tested x86 machines, with smaller but still positive wins at high thread counts.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Strong database-systems piece because it shows compression as an execution format, not only a storage format: predicate pushdown can operate over encoded data when the codec preserves enough structure.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Bangalore Paper Club on alternate language-model architectures</title>
          <pubDate>Sun, 19 Jul 2026 20:23:00 +0530</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-19-bangalore-paper-club-on-alternate-language-model-architectures/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-19-bangalore-paper-club-on-alternate-language-model-architectures/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-19-bangalore-paper-club-on-alternate-language-model-architectures/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-19 20:23 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Kautuk &#x2F; Conscious Engines announcing Bangalore Paper Club episode 2, themed around alternate architectures for language models.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; The post frames the event around the claim that architecture is an ideas game while scaling is a compute game. The discussed papers were LLaDA, a diffusion language model; Nemotron-TwoTower, an NVIDIA approach for faster diffusion-language-model generation; CLeGR, a benchmark for graph-language models; plus a bonus Dognosis talk on cancer detection via canine olfaction. The quoted post adds the useful thesis: if language-model progress gets redrawn in places without frontier GPU budgets, it may come from architectural questions rather than simply stacking more layers.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Retrieval note:&lt;&#x2F;strong&gt; I could read the X post and quoted post metadata&#x2F;text, but the promised YouTube link was not exposed in the fetched post or public browser snapshot, so this is not grounded in the full episode transcript&#x2F;video.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Useful local&#x2F;India AI research-community signal because it treats frontier progress as an architecture-search problem, not only a compute-scaling race.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>The zero-cost fallacy</title>
          <pubDate>Sun, 19 Jul 2026 16:28:00 +0530</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-19-the-zero-cost-fallacy-open-source-software-in-the-agentic-era/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-19-the-zero-cost-fallacy-open-source-software-in-the-agentic-era/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-19-the-zero-cost-fallacy-open-source-software-in-the-agentic-era/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-19 16:28 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Bilgin Ibryam sharing Thoughtworks’ &lt;code&gt;The zero-cost fallacy: Open source software in the agentic era&lt;&#x2F;code&gt;.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; The article argues that the agentic era intensifies long-running open-source sustainability problems. It separates zero marginal distribution cost from real maintenance labor, then adds two AI-era pressures: low-effort generated pull requests that turn maintainers into unpaid reviewers, and a degraded trust landscape where stars, recency, and apparent activity are easier to manipulate. It also frames permissive licensing as part of an extraction economy, while acknowledging that restrictive or dual licensing creates adoption, enforcement, and procurement problems.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Strong org-design and supply-chain piece because it turns AI-generated code from a productivity story into a maintainer-incentive and trust-model problem.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>KTransformers and heterogeneous MoE inference</title>
          <pubDate>Sun, 19 Jul 2026 02:31:00 +0530</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-19-ktransformers-and-heterogeneous-moe-inference/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-19-ktransformers-and-heterogeneous-moe-inference/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-19-ktransformers-and-heterogeneous-moe-inference/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-19 02:31 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; X post pointing to &lt;code&gt;kvcache-ai&#x2F;ktransformers&lt;&#x2F;code&gt;, a Tsinghua MADSys Lab project for CPU-GPU heterogeneous inference and fine-tuning of large MoE models.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; The viral framing is a little breathless, but the underlying project is real and interesting: KTransformers is about heterogeneous CPU&#x2F;GPU execution for large MoE models, keeping hot experts on GPU and offloading colder expert work to CPU&#x2F;DRAM so very large models can be explored on commodity-ish hardware. The repo’s own docs claim DeepSeek-V3&#x2F;R1 support on 24GB VRAM with long-context paths, 3x to 28x speedups in the relevant setup, and fine-tuning paths for large MoEs through LLaMA-Factory on small GPU clusters.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Useful systems item because it shows the same recurring inference theme again: once models are sparse, the interesting optimization surface shifts from raw GPU count to placement, scheduling, quantization, cache locality, and heterogeneous memory hierarchy.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Diffusing Blame</title>
          <pubDate>Sat, 18 Jul 2026 21:31:00 +0530</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-18-diffusing-blame/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-18-diffusing-blame/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-18-diffusing-blame/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-18 21:31 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Sakana AI sharing its ALIFE 2026 paper &lt;code&gt;Diffusing Blame&lt;&#x2F;code&gt;, about learning in Dale-constrained dual-stream neural networks without weight transport.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; The paper asks whether networks can learn competitively while respecting Dale’s principle, where each neuron is either excitatory or inhibitory, and without backprop’s biologically implausible weight transport. Their method extends Error Diffusion with modulo error routing for multi-class settings, splitting layers into excitatory and inhibitory streams with non-negative weights. The results show Dale-constrained networks can still learn on image classification and reinforcement-learning tasks, including MNIST, CIFAR-10, PPO on Brax continuous-control tasks, and Craftax.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Interesting biologically plausible learning result because it treats credit assignment as an architecture-and-routing problem rather than assuming backprop’s exact weight transport is the only path to useful learning.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Skyroot’s Vikram-1 reaches orbit</title>
          <pubDate>Sat, 18 Jul 2026 21:21:00 +0530</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-18-skyroot-vikram-1-reaches-orbit/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-18-skyroot-vikram-1-reaches-orbit/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-18-skyroot-vikram-1-reaches-orbit/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-18 21:21 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Skyroot Aerospace announcing that Vikram-1 Test Flight-1 reached orbit, India’s first privately developed orbital-class rocket to do so.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; Skyroot says Vikram-1 completed its final burn and injected payloads into roughly a 450 km orbit, making India the third country with private orbital launch capability. The CNBC follow-up adds useful mission detail: the vehicle launched from Sriharikota, carried multiple technology demonstration payloads, and marks a concrete commercial-space milestone rather than just another suborbital or demonstration flight.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Follow-up context:&lt;&#x2F;strong&gt; Caleb Friesen’s reflection adds the industry-history layer: when Skyroot was founded in 2018, Indian private companies still could not launch rockets. Liberalisation in 2020 made private launch vehicles possible, and Vikram-1 now marks the point where that policy shift turns into demonstrated orbital execution by a young private team. That makes the milestone feel less like a single launch and more like proof that India’s private spacetech market has crossed from permission into capability.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Important India&#x2F;private-space milestone because the line crossed is orbital insertion by a privately developed rocket, which moves the story from startup promise to demonstrated launch capability.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Running LLM inference on AWS: Bedrock vs SageMaker vs self-hosted on EKS</title>
          <pubDate>Fri, 17 Jul 2026 15:43:00 +0530</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-17-running-llm-inference-on-aws-bedrock-vs-sagemaker-vs-self-hosted-on-eks/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-17-running-llm-inference-on-aws-bedrock-vs-sagemaker-vs-self-hosted-on-eks/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-17-running-llm-inference-on-aws-bedrock-vs-sagemaker-vs-self-hosted-on-eks/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-17 15:43 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Devopsity’s comparison of three AWS inference patterns: Bedrock, SageMaker endpoints, and self-hosted GPU serving on EKS.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; The useful part is not the cloud-brand framing but the workload segmentation. Bedrock wins at low volume and low ops burden, SageMaker sits in the middle for fine-tuned models and predictable dedicated capacity, and self-hosted EKS wins once utilization is high enough that GPU spot economics and batching dominate per-token pricing. The stronger systems lesson is that the architecture choice is really about traffic shape, latency SLOs, compliance boundaries, and whether you want to pay in tokens, instance-hours, or platform complexity.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Good companion to the self-hosting pieces because it turns the &quot;rent vs own&quot; question into an explicit AWS migration path, with concrete crossover points and infra patterns like Karpenter, vLLM, and mixed spot&#x2F;on-demand GPU pools.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Kimi K3: Open Frontier Intelligence</title>
          <pubDate>Fri, 17 Jul 2026 01:55:00 +0530</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-17-kimi-k3-open-frontier-intelligence/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-17-kimi-k3-open-frontier-intelligence/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-17-kimi-k3-open-frontier-intelligence/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-17 01:55 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Moonshot AI introducing Kimi K3, a 2.8T-parameter open frontier model with native vision, 1M context, sparse MoE routing, and an explicitly agentic product&#x2F;deployment story.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; The interesting move is not just scale. Kimi is positioning K3 as a genuinely open frontier model designed for long-horizon coding, knowledge work, and multimodal agent loops, while being unusually concrete about architecture and infra: KDA, AttnRes, 16-of-896 experts, quantization-aware training from SFT onward, 64+ accelerator supernode deployment, and vLLM support for KDA prefill caching. The product story is also unusually agent-first: coding benchmarks run through harnesses, examples center on kernel optimization, compiler construction, research automation, dashboards, widgets, and recursive self-improvement workflows, and the release notes are explicit that UX still trails Claude Fable 5 and GPT 5.6 Sol despite strong raw benchmark performance.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Important open-model release because it combines frontier scale with a much more systems-heavy deployment story than most launch posts, and because it treats agent harness compatibility and inference architecture as first-class product concerns.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Shard your locks</title>
          <pubDate>Thu, 16 Jul 2026 23:42:00 +0530</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-16-shard-your-locks/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-16-shard-your-locks/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-16-shard-your-locks/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-16 23:42 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Misha Strebkov benchmarking six Go in-memory cache designs under different read&#x2F;write mixes and core counts.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; The sharp result is that the boring “just use RWMutex for read-heavy caches” instinct does not hold up well under contention. A 256-shard striped map was the best all-around design, scaling up to about 8x faster than a single mutex at 8 cores, while RWMutex plateaued early and could even lose to a plain mutex on writes. The broader lesson is to reason about contention topology, cache-line movement, and workload skew, not just read&#x2F;write ratios.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Strong practical concurrency piece because it turns a familiar rule of thumb into a measurable systems lesson: lock striping usually beats reflexive RWMutex usage once core counts and contention rise.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Linus Torvalds on Linux and AI tools</title>
          <pubDate>Thu, 16 Jul 2026 23:37:00 +0530</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-16-linus-torvalds-on-linux-and-ai-tools/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-16-linus-torvalds-on-linux-and-ai-tools/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-16-linus-torvalds-on-linux-and-ai-tools/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-16 23:37 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Linus Torvalds pushing back on anti-AI sentiment in kernel development and saying Linux is not an anti-AI project.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; Linus’s operative distinction is not &quot;everyone must use AI,&quot; but that the kernel should evaluate tools on technical merit, not ideological discomfort. He argues AI is now clearly useful, maintainers should focus on making LLM tools reduce pain rather than banning them, and people who object to others using AI can fork or walk away. The broader point is that the kernel project is about better technology, not being a social-warrior project organized around symbolic stances.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Strong signal from one of the most consequential infrastructure maintainers that the center of gravity is moving toward pragmatic tool acceptance, with the real debate shifting from &quot;whether&quot; to &quot;how&quot; AI use helps maintainers.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Retrieval note:&lt;&#x2F;strong&gt; The original lore.kernel.org message was blocked behind Anubis anti-bot protection from this environment, so this note is grounded in a secondary page that quoted the full mailing-list email text and linked back to the original.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>I tested 9 serverless GPU providers for AI inference in 2026</title>
          <pubDate>Thu, 16 Jul 2026 20:13:00 +0530</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-16-i-tested-9-serverless-gpu-providers-for-ai-inference-in-2026/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-16-i-tested-9-serverless-gpu-providers-for-ai-inference-in-2026/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-16-i-tested-9-serverless-gpu-providers-for-ai-inference-in-2026/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-16 20:13 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; DEV post comparing nine serverless GPU providers for inference, from DigitalOcean and RunPod to Modal, Koyeb, Together, Replicate, Baseten, Fal, and Cloudflare Workers AI.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; The useful value here is not the absolute ranking but the comparison axes: GPU availability, billing model, cold-start behavior, deployment ergonomics, and production-readiness tradeoffs. The author’s practical take is that different providers win for different workload shapes, but the recurring decision variables are still the same ones as the self-hosting piece: latency predictability, cost model fit, control, and how much platform surface area you want around inference.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Good companion piece to the self-hosting article because it maps the “rent” side of the market in detail and makes clear that inference platform choice is mostly about workload shape and operational preferences, not one universal winner.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Should you self-host inference?</title>
          <pubDate>Thu, 16 Jul 2026 20:03:00 +0530</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-16-should-you-self-host-inference/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-16-should-you-self-host-inference/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-16-should-you-self-host-inference/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-16 20:03 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Superlinked’s long-form argument for when self-hosting model inference becomes cheaper or strategically better than renting APIs.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; The article’s practical answer is hybrid: rent frontier APIs for low-volume, spiky, or hardest-reasoning traffic, but self-host steady high-volume workloads once a GPU stays busy enough. The useful details are the break-even framing around sustained utilization, the claim that many enterprise tasks are already well-served by sub-40B open models, and the systems argument that the real challenge is not just serving one model but routing, batching, packing, and operating many small models efficiently on shared hardware.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Good operational piece because it moves the self-hosting question away from ideology and toward utilization, workload shape, model specialization, and control-plane design.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>The Future Worth Building Is Human</title>
          <pubDate>Thu, 16 Jul 2026 03:09:00 +0530</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-16-the-future-worth-building-is-human/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-16-the-future-worth-building-is-human/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-16-the-future-worth-building-is-human/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-16 03:09 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Thinking Machines manifesto-style essay arguing for AI that extends human will and judgment rather than replacing human participation.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; The essay’s central move is to treat both knowledge and values as local, tacit, and continuously updated by people doing the work. From that framing, frontier AI should be customizable, distributed, and shaped in use, not frozen in a handful of centralized labs. The interesting claim is that human participation is not just a normative preference but a technical challenge: richer interfaces, fine-tuning, interaction models, and decentralized alignment are presented as the route to AI that serves organizations without flattening their distinctiveness.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Useful statement of the decentralization&#x2F;customization worldview behind Thinking Machines, and a good foil for more autonomy-maximalist visions of AI deployment.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Inkling: our open-weights model</title>
          <pubDate>Thu, 16 Jul 2026 02:06:00 +0530</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-16-inkling-our-open-weights-model/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-16-inkling-our-open-weights-model/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-16-inkling-our-open-weights-model/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-16 02:06 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Mira Murati announcing Thinking Machines’ first model, Inkling, and pointing to the launch post.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; The important part is not just “open weights.” Inkling is a 975B total &#x2F; 41B active multimodal Mixture-of-Experts model with 1M context, controllable reasoning effort, and fine-tuning availability on Tinker from day one. The launch positions it as a customization-first base model rather than the absolute frontier model, with emphasis on efficient multimodal reasoning, agentic tool use, and post-training workflows, including a demo where the model fine-tunes and swaps in its own updated weights.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Notable open-model launch because the product story is unusually explicit about customization, agent harness use, and self-improvement workflows rather than just benchmark one-upmanship.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Boris Cherny on domain knowledge as infrastructure</title>
          <pubDate>Thu, 16 Jul 2026 01:33:00 +0530</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-16-boris-cherny-on-domain-knowledge-as-infrastructure/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-16-boris-cherny-on-domain-knowledge-as-infrastructure/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-16-boris-cherny-on-domain-knowledge-as-infrastructure/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-16 01:33 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Boris Cherny arguing that agent-era engineering leverage still comes from automation, but now automation also includes encoded domain knowledge like &lt;code&gt;CLAUDE.md&lt;&#x2F;code&gt;, review rules, skills, and docs&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; The core claim is that the old highest-leverage engineering move, turning recurring work into infrastructure, matters even more with agents. Better lint rules, CI steps, tests, routines, and DevX speed up both humans and agent swarms. More importantly, domain knowledge that used to live in people’s heads now needs to be encoded as machine-usable infrastructure so newcomers, non-engineers, and agents can contribute productively without hidden tribal context.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Good articulation of why agent readiness is less about prompting tricks and more about operationalizing team knowledge into executable or at least machine-readable scaffolding.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Arvind Narayanan on recursive self-improvement discourse</title>
          <pubDate>Wed, 15 Jul 2026 22:23:00 +0530</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-15-arvind-narayanan-on-recursive-self-improvement-discourse/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-15-arvind-narayanan-on-recursive-self-improvement-discourse/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-15-arvind-narayanan-on-recursive-self-improvement-discourse/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-15 22:23 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Arvind Narayanan pointing to his ICML 2026 annotated keynote slides and highlighting new pushback on recursive self-improvement assumptions&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; Narayanan’s frame is that the &quot;AI as normal technology&quot; view still holds unless there is a real discontinuity, and that even if recursive self-improvement matters, there is no obvious lab milestone that suddenly makes human work disappear. The interesting addition here is not blanket dismissal of RSI, but a push to interrogate the discourse assumptions around it while shifting attention toward how work and human roles actually change.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Useful counterweight to fast-take RSI discourse, especially paired with the earlier autoresearch claim, because it separates taking RSI seriously from assuming abrupt labor-displacement narratives.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Fable 5 Is Insane. I Vibe Coded Terminator Vision.</title>
          <pubDate>Wed, 15 Jul 2026 16:58:00 +0530</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-15-fable-5-is-insane-i-vibe-coded-terminator-vision/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-15-fable-5-is-insane-i-vibe-coded-terminator-vision/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-15-fable-5-is-insane-i-vibe-coded-terminator-vision/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-15 16:58 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Bilawal Sidhu video titled “Fable 5 Is Insane. I Vibe Coded Terminator Vision.”&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; From the visible YouTube description and page metadata, this is a build&#x2F;demo video about creating a browser-based range-analysis system from ordinary 2D video sources like Meta Ray-Bans, iPhones, and GoPros, then reconstructing shots, hits&#x2F;misses, targets, and a replayable 3D &quot;god’s eye&quot; view of the session.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Interesting computer-vision &#x2F; spatial-reconstruction demo that fits the broader pattern of fast prototyping with modern models plus commodity sensors.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Retrieval note:&lt;&#x2F;strong&gt; I could read page metadata and the visible on-page description, but transcript extraction was blocked by YouTube IP restrictions from this environment, so this note is not grounded in a full transcript.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Experimental evidence of recursive self-improvement</title>
          <pubDate>Wed, 15 Jul 2026 14:02:00 +0530</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-15-experimental-evidence-of-recursive-self-improvement/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-15-experimental-evidence-of-recursive-self-improvement/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-15-experimental-evidence-of-recursive-self-improvement/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-15 14:02 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Zhengyao Jiang claiming the first experimental evidence of recursive self-improvement in an autoresearch agent&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; The specific claim is not generic &quot;agents got better with more tuning,&quot; but that an agent spent eight days autoresearching its own harness and produced a variant that beat a hand-tuned baseline built over two years on held-out benchmarks. If the thread substantiates it, the interesting part is not self-modification in the abstract but search over agent workflows yielding benchmark gains that transfer beyond the optimization loop.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Potentially notable if the evidence holds up, because it frames RSI less as dramatic self-rewriting and more as automated harness optimization that outperforms long human iteration.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Retrieval note:&lt;&#x2F;strong&gt; This note is grounded from the opening X post only. The fetched metadata in this pass did not include a linked longform source.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>The Memory Heist</title>
          <pubDate>Wed, 15 Jul 2026 13:30:00 +0530</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-15-the-memory-heist/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-15-the-memory-heist/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-15-the-memory-heist/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-15 13:30 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Ayush Paul’s writeup on prompt-injecting Claude’s memory and browsing system into exfiltrating personal data&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; The attack chain was not about breaking the memory store directly, but about combining long-lived personal memory with a browsing agent that could be socially engineered into leaking data through link-by-link URL navigation. The important point is that once an assistant can search history, infer missing details, and autonomously browse attacker-controlled pages, &quot;read-only&quot; web access can still become an exfiltration channel.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Strong concrete example of why agent safety is mostly about tool composition and trust boundaries, not just whether any single feature looks harmless in isolation.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>How Razorpay refreshes its data warehouse 10x faster</title>
          <pubDate>Wed, 15 Jul 2026 10:45:00 +0530</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-15-how-razorpay-refreshes-its-data-warehouse-10x-faster/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-15-how-razorpay-refreshes-its-data-warehouse-10x-faster/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-15-how-razorpay-refreshes-its-data-warehouse-10x-faster/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-15 10:45 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Piyush Goel sharing Razorpay Engineering’s writeup on refreshing warehouse facts 10x faster with graphs and indexes&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; Razorpay moved from expensive full-refresh fact generation toward incremental fact maintenance by treating each denormalized fact as a dependency graph. They pair change-driven processing with secondary indexes on the lake, graph traversal to discover affected ancestors and descendants, and selective runtime joins for high-cardinality dimensions. The result is much faster warehouse refreshes with lower compute cost, restored historical coverage, and less dependency on the warm store.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Strong data-infra example of reframing materialized-table refresh as graph maintenance, plus a nice case for batch-plus-incremental beating naive streaming when stateful joins get too expensive.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>DSLs enable reliable use of LLMs</title>
          <pubDate>Tue, 14 Jul 2026 20:54:00 +0530</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-14-dsls-enable-reliable-use-of-llms/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-14-dsls-enable-reliable-use-of-llms/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-14-dsls-enable-reliable-use-of-llms/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-14 20:54 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Martin Fowler sharing Unmesh Joshi’s article on DSLs and LLM reliability&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; The article’s core claim is that LLMs become much more reliable when they are constrained by domain abstractions and DSLs instead of being asked to directly generate unconstrained general-purpose code. The deeper point is that DSLs do double duty: they help teams discover and stabilize a semantic model during design, and then they become a natural-language target that LLMs can generate against, validate, and repair with much tighter feedback loops.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Strong articulation of a recurring pattern in good AI engineering: move effort from reviewing arbitrary generated code toward building better vocabularies, abstractions, and validators that make generation reliable by construction.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>AI learns the dark art of RFIC design</title>
          <pubDate>Tue, 14 Jul 2026 19:29:00 +0530</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-14-ai-learns-the-dark-art-of-rfic-design/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-14-ai-learns-the-dark-art-of-rfic-design/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-14-ai-learns-the-dark-art-of-rfic-design/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-14 19:29 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; IEEE Spectrum feature on AI-driven RFIC design&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; The piece argues that radio-frequency chip design has remained a hard-to-formalize &quot;dark art&quot; because it requires coupled reasoning across circuits, electromagnetics, thermals, packaging, and manufacturability. Princeton researchers are using reinforcement learning, inverse design, and diffusion-style generation to explore RFIC architectures and layouts beyond human templates, producing novel-looking chips that can outperform hand-designed baselines while drastically compressing design time.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Strong example of AI moving from coding assistance into deep engineering search spaces where the value is not text generation but navigating a huge multi-physics design landscape faster than humans can.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>iximiuz on Januscape and the limits of microVM safety claims</title>
          <pubDate>Tue, 14 Jul 2026 11:05:00 +0530</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-14-iximiuz-on-januscape-and-the-limits-of-microvm-safety-claims/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-14-iximiuz-on-januscape-and-the-limits-of-microvm-safety-claims/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-14-iximiuz-on-januscape-and-the-limits-of-microvm-safety-claims/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-14 11:05 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; iximiuz warning that VMs and microVMs exposing &lt;code&gt;&#x2F;dev&#x2F;kvm&lt;&#x2F;code&gt; to untrusted guests were hit by the Januscape guest-to-host breakout class&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; The key update is that KVM-based isolation is not a free safety upgrade over containers if you hand untrusted guests nested virtualization. The disclosed Januscape bug is a guest-to-host KVM&#x2F;x86 escape affecting systems that accept untrusted guests and expose nested virt, with mitigations including disabling nested virtualization until downstream kernels catch up.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Useful corrective to simplistic &quot;microVMs are always safer&quot; narratives, because the real boundary depends on what kernel and hardware virtualization surfaces you expose.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Supporting source:&lt;&#x2F;strong&gt; Canonical also published mitigation guidance: &lt;code&gt;https:&#x2F;&#x2F;canonical.com&#x2F;blog&#x2F;januscape-linux-vulnerability-mitigations-available&lt;&#x2F;code&gt;&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Dave Winer introduces rss.chat</title>
          <pubDate>Tue, 14 Jul 2026 09:44:00 +0530</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-14-dave-winer-introduces-rss-chat/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-14-dave-winer-introduces-rss-chat/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-14-dave-winer-introduces-rss-chat/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-14 09:44 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Dave Winer introducing &lt;code&gt;rss.chat&lt;&#x2F;code&gt; and arguing for RSS as a social-network substrate&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; Winer presents &lt;code&gt;rss.chat&lt;&#x2F;code&gt; as a small-community social system built from old web primitives: RSS 2.0, OPML, Markdown, SQL, WebSocket, and rssCloud. The pitch is that social publishing and reply structures do not need heavyweight new protocols if interoperable feeds, shared formats, and replaceable components are treated as the core product.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Good example of AI-assisted software being used to revive old-web interoperability ideas, with a strong small-tools, small-servers, open-formats counter-position to platform-centric social design.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Gergely Orosz on trust burn from Grok CLI privacy concerns</title>
          <pubDate>Tue, 14 Jul 2026 08:14:00 +0530</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-14-gergely-orosz-on-trust-burn-from-grok-cli-privacy-concerns/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-14-gergely-orosz-on-trust-burn-from-grok-cli-privacy-concerns/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-14-gergely-orosz-on-trust-burn-from-grok-cli-privacy-concerns/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-14 08:14 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Gergely Orosz calling out reports that Grok CLI uploaded codebases without users knowingly consenting, quoting SpaceXAI’s privacy response&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; The important issue here is not just data retention policy wording but trust boundary failure. Orosz’s point is that if developers believe a local coding tool silently uploaded proprietary code without clear consent, the damage is immediate and reputational, even if the vendor later points to settings like zero data retention or a &lt;code&gt;&#x2F;privacy&lt;&#x2F;code&gt; command.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Strong example of how AI devtools live or die on trust defaults, explicit consent, and understandable privacy UX, not just post hoc policy explanations.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Using uvx in GitHub Actions in a cache-friendly way</title>
          <pubDate>Tue, 14 Jul 2026 08:12:00 +0530</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-14-using-uvx-in-github-actions-in-a-cache-friendly-way/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-14-using-uvx-in-github-actions-in-a-cache-friendly-way/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-14-using-uvx-in-github-actions-in-a-cache-friendly-way/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-14 08:12 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Simon Willison linking to his TIL on running &lt;code&gt;uvx&lt;&#x2F;code&gt; in GitHub Actions without re-downloading the package every run&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; The useful trick is to pin &lt;code&gt;UV_EXCLUDE_NEWER&lt;&#x2F;code&gt; to a date, use that same date in the GitHub Actions cache key, and set &lt;code&gt;UV_OFFLINE=1&lt;&#x2F;code&gt; on cache hits. That gives a lightweight, file-free way to make &lt;code&gt;uvx tool-name&lt;&#x2F;code&gt; workflows cacheable, reproducible enough, and intentionally bustable by changing one date.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Nice practical CI pattern for teams using &lt;code&gt;uvx&lt;&#x2F;code&gt; as disposable tooling glue, especially because it avoids adding fake dependency files just to drive cache keys.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Control the ideas, not the code</title>
          <pubDate>Mon, 13 Jul 2026 19:31:00 +0530</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-13-control-the-ideas-not-the-code/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-13-control-the-ideas-not-the-code/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-13-control-the-ideas-not-the-code/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-13 19:31 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; X post by antirez linking his blog post &quot;Control the ideas, not the code&quot;&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; antirez extends the earlier X-thread argument into a full workflow claim: if you own the ideas, design, testing, and QA of a system, then line-by-line review of generated code is increasingly the wrong bottleneck. He argues that models are already better at many local code checks than humans, and that the higher-leverage work is controlling the mental model, writing human-readable design docs, and spending time on quality and new ideas instead of staring at implementation details.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Important articulation of the strongest serious case against code-centric AI resistance: move human effort up the stack from code review toward design ownership, QA, and explicit idea capture.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>I love LLMs, I hate hype</title>
          <pubDate>Mon, 13 Jul 2026 16:04:00 +0530</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-13-i-love-llms-i-hate-hype/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-13-i-love-llms-i-hate-hype/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-13-i-love-llms-i-hate-hype/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-13 16:04 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; X post from the geohot archive linking George Hotz’s blog post &quot;I love LLMs, I hate hype&quot;&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; Hotz argues for a strongly pro-AI but anti-hype position: LLMs, coding agents, and related tools are genuinely useful, but a lot of frontier-lab rhetoric is status theater, fear marketing, and exaggerated capture claims. His practical middle position is that programming is changing, models are useful, and they can boost productivity, but vibe-coded slop is still slop and the value created by AI will likely diffuse more broadly than frontier labs imply.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Good counterweight to both boosterism and reflexive dismissal, especially the claim that AI value creation is real while value capture by frontier labs is much less certain.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Mario Zechner on types, interfaces, and reading generated code</title>
          <pubDate>Mon, 13 Jul 2026 12:19:00 +0530</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-13-mario-zechner-on-types-interfaces-and-reading-generated-code/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-13-mario-zechner-on-types-interfaces-and-reading-generated-code/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-13-mario-zechner-on-types-interfaces-and-reading-generated-code/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-13 12:19 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; X post by Mario Zechner adding nuance to antirez’s AI-code ownership point&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; Zechner’s point is narrower and more practical than a general plea for control: if you control the types and interfaces, the rest often falls into place well enough. But current models still love to introduce bad abstractions that work against those boundaries, so in practice you sometimes have to read generated code and beat it back into submission instead of letting it stomp over the structure you intended.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Useful follow-on to the &quot;own the mental model&quot; debate because it turns the abstraction into a concrete engineering rule: own the types and interfaces, and do not let the model stomp over them with bad abstractions.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Melancholy Elephants on copyright and finite creative space</title>
          <pubDate>Mon, 13 Jul 2026 12:19:00 +0530</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-13-melancholy-elephants-on-copyright-and-finite-creative-space/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-13-melancholy-elephants-on-copyright-and-finite-creative-space/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-13-melancholy-elephants-on-copyright-and-finite-creative-space/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-13 12:19 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Spider Robinson’s short story &quot;Melancholy Elephants&quot; (part 3 on the site, with story context introduced on the page)&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; The story imagines a world where creative expression is constrained not just by law or economics but by the finite space of humanly meaningful combinations. Its argument is that melodies, plots, and even artistic forms are not infinite, and that longer copyright terms can become culturally suffocating once societies are rich, populous, and saturated with creators. The page frames it explicitly as an early meditation on copyright scarcity.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Strong older reference point for current debates about cultural exhaustion, recombination, copyright, and whether creativity is discovery in a finite space rather than infinite invention.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;&#x2F;strong&gt; Read over plain HTTP because the site’s HTTPS certificate is expired; direct HTTPS fetch failed certificate verification.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>The Reverse Information Paradox</title>
          <pubDate>Mon, 13 Jul 2026 07:59:00 +0530</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-13-the-reverse-information-paradox/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-13-the-reverse-information-paradox/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-13-the-reverse-information-paradox/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-13 07:59 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Satya Nadella’s X article &quot;The Reverse Information Paradox&quot;&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; Nadella argues that AI flips Arrow’s classic information paradox: enterprises now pay not only with money for intelligence, but also with proprietary knowledge, prompts, traces, evals, and corrections required to make that intelligence useful. His answer is a hard enterprise trust boundary around models, data, memory, traces, evals, orchestration, and the right to retain and reuse the learning generated inside the firm.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Strong enterprise AI thesis about who owns the learning loop, with a useful framing around prompts, traces, feedback, and institutional know-how as compounding capital rather than disposable exhaust.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>antirez on owning the mental model in AI-coded systems</title>
          <pubDate>Mon, 13 Jul 2026 07:49:00 +0530</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-13-antirez-on-owning-the-mental-model-in-ai-coded-systems/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-13-antirez-on-owning-the-mental-model-in-ai-coded-systems/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-13-antirez-on-owning-the-mental-model-in-ai-coded-systems/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-13 07:49 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; X post by antirez on the &quot;don&#x27;t look at the code&quot; debate in AI-coded systems&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; He distinguishes between two very different ways an AI-coded codebase can come into existence: one where the human still controls the main ideas and keeps a coherent mental model of the system, and one where the human brute-forces prompts until something works. The point is that these may look similar from the outside but carry very different implications for understanding, maintainability, and trust.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Sharp framing for a real fault line in AI-assisted software work: the key variable is not just whether AI wrote code, but whether the builder still owns the architecture and mental model.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Old and new apps, via modern coding agents</title>
          <pubDate>Mon, 13 Jul 2026 07:37:00 +0530</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-13-old-and-new-apps-via-modern-coding-agents/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-13-old-and-new-apps-via-modern-coding-agents/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-13-old-and-new-apps-via-modern-coding-agents/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-13 07:37 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; X post by Mario Zechner recommending Terry Tao’s post &quot;Old and new apps, via modern coding agents&quot;&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; Tao describes using modern coding agents to port his old Java applets to JavaScript and revive them quickly, with surprisingly low bug overhead, then goes further and uses the same workflow to build new math visualization tools he had wanted for decades. The interesting point is not just vibe coding as novelty, but coding agents as leverage for software archaeology, maintenance, and low-risk supplementary tooling.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Strong datapoint for coding agents as practical infrastructure for porting legacy code and building non-mission-critical research tools, even in domains far outside mainstream software product work.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Vim of Coding Agents</title>
          <pubDate>Sun, 12 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-12-vim-of-coding-agents/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-12-vim-of-coding-agents/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-12-vim-of-coding-agents/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-12 13:18 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; X post by dogfiles linking the blog post &quot;Vim of Coding Agents&quot;&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; Frames Pi as the Neovim of coding agents: a minimal, hackable foundation that adapts to your workflow instead of forcing you into an opinionated all-in-one agent product. The writeup argues that the real value is not just using Pi as shipped, but treating it as a customizable harness where you can build your own tools, TUI tweaks, prompts, and extensions.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Good articulation of the coding-agent split between turnkey products and configurable harnesses, especially from the perspective of a user who wants the agent equivalent of a programmable editor.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>101 saying a Go proposal was formally rejected</title>
          <pubDate>Sat, 11 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-11-101-saying-a-go-proposal-was-formally-rejected/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-11-101-saying-a-go-proposal-was-formally-rejected/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-11-101-saying-a-go-proposal-was-formally-rejected/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-11 01:16 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; X post by zigo 101 saying a Go proposal was formally rejected&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; Refers to the proposal to allow explicit conversion from a function to a one-method interface in Go. The signal here is less the terse rejection post itself and more that this possible post-1.27 language change is now formally not happening.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Useful small datapoint in Go language evolution: another reminder that the bar for adding convenience features to core Go remains high, especially where ambiguity or language-surface complexity is involved.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Retrieval note:&lt;&#x2F;strong&gt; Grounded from the X post plus the quoted earlier post linking GitHub issue &lt;code&gt;golang&#x2F;go#47487&lt;&#x2F;code&gt;.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Goel summarizing Deep SWE 1.1 model-cost comparisons</title>
          <pubDate>Sat, 11 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-11-goel-summarizing-deep-swe-1-1-model-cost-comparisons/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-11-goel-summarizing-deep-swe-1-1-model-cost-comparisons/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-11-goel-summarizing-deep-swe-1-1-model-cost-comparisons/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-11 01:15 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; X post by Shantanu Goel summarizing Deep SWE 1.1 model-cost comparisons&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; Claims GPT 5.6 Sol medium outperforms Opus 4.8 max at roughly one-sixth the cost, while GPT 5.6 Sol High performs similarly to Fable 5 max at roughly one-fifth the cost. Framed as a benchmark-driven price&#x2F;performance argument rather than a qualitative workflow review.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Useful datapoint for coding-model market structure: if these Deep SWE 1.1 comparisons hold up, the story is not just capability but a sharp shift in price-performance for SWE-oriented model tiers.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Retrieval note:&lt;&#x2F;strong&gt; Grounded from the X post text itself; the supporting benchmark details appear to be in the attached image, which I have not OCRed here.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>GPT-5.4 with Pi 0.69.0 is just nice</title>
          <pubDate>Sat, 11 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-11-gpt-5-4-with-pi-0-69-0-is-just-nice/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-11-gpt-5-4-with-pi-0-69-0-is-just-nice/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-11-gpt-5-4-with-pi-0-69-0-is-just-nice/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-11 02:17 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; X post by Rohan Verma linking his blog post &quot;GPT-5.4 with Pi 0.69.0 is just nice&quot;&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; Argues that an agent harness stack getting boring is a success condition, not a failure. The post frames Pi 0.69.0 + GPT-5.4 + Bosun&#x2F;Zero Agent as having crossed from fragile novelty into dependable daily tooling, where the interesting result is not frontier-model hype but the fact that the stack stopped demanding constant maintenance to remain useful.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Strong firsthand writeup on harness maturity: the real milestone is when the agent stack stops feeling like a project car and starts feeling boringly dependable.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Harness Engineering for Self-Improvement</title>
          <pubDate>Sat, 11 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-11-harness-engineering-for-self-improvement/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-11-harness-engineering-for-self-improvement/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-11-harness-engineering-for-self-improvement/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-11 15:38 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Lilian Weng blog post, &quot;Harness Engineering for Self-Improvement&quot;&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; Argues that recursive self-improvement in the near term is less about models rewriting their own weights and more about improving the surrounding harness: workflow loops, context management, filesystem memory, subagents, backend jobs, evaluation, and runtime design. The core claim is that the deployment layer between model and world is becoming an optimization target in its own right.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Strong framing for why the interesting frontier is shifting from prompt tricks to runtime and harness design, especially for coding agents and auto-research systems.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Hashimoto on side-by-side Sol xhigh versus Ultra runs</title>
          <pubDate>Sat, 11 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-11-hashimoto-on-side-by-side-sol-xhigh-versus-ultra-runs/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-11-hashimoto-on-side-by-side-sol-xhigh-versus-ultra-runs/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-11-hashimoto-on-side-by-side-sol-xhigh-versus-ultra-runs/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-11 01:09 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; X post by Mitchell Hashimoto on side-by-side Sol xhigh versus Ultra runs&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; Says two days of side-by-side planning and implementation runs did not reveal a tangible quality difference between Sol xhigh and Ultra, even though execution behavior and token usage clearly differed. The underlying question is what real use case, if any, currently justifies paying for the more expensive tier.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Good practitioner datapoint on frontier-model tiering: users may see visible cost and execution differences before they see reliable quality separation in real coding workflows.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Retrieval note:&lt;&#x2F;strong&gt; Grounded from the X post text itself; no linked article in the post.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>solod</title>
          <pubDate>Sat, 11 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-11-solod/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-11-solod/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-11-solod/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-11 01:12 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; X reply by Aliaksandr Valialkin pointing to the &lt;code&gt;solod&lt;&#x2F;code&gt; project&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; Very terse recommendation of &lt;code&gt;solod&lt;&#x2F;code&gt;, a project described as &quot;a subset of Go that translates to C.&quot; In context, this looks like a pointer toward an alternative way to get highly portable or low-level output from Go-like code without using full Go as-is.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Interesting small tooling pointer in the Go&#x2F;compiler&#x2F;toolchain space, especially if the broader thread is about language&#x2F;runtime tradeoffs or portability.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Retrieval note:&lt;&#x2F;strong&gt; Grounded from the X reply text plus the GitHub card metadata for &lt;code&gt;https:&#x2F;&#x2F;github.com&#x2F;solod-dev&#x2F;solod&lt;&#x2F;code&gt;.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Andrew Kelley’s response essay on Bun’s Rust rewrite</title>
          <pubDate>Fri, 10 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-10-andrew-kelley-s-response-essay-on-bun-s-rust-rewrite/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-10-andrew-kelley-s-response-essay-on-bun-s-rust-rewrite/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-10-andrew-kelley-s-response-essay-on-bun-s-rust-rewrite/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-10 20:31 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Andrew Kelley’s response essay on Bun’s Rust rewrite&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; Frames the rewrite less as a language indictment and more as a consequence of Bun’s startup incentives, weak engineering discipline, and management culture. He argues Zig was a good fit for Bun’s early ambition, but the real failure mode was accumulating technical debt under venture-backed speed pressure rather than the language itself.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Useful counterpoint to simplistic “Rust beat Zig” narratives; the sharper story is incentives, engineering quality, and what startup pressure does to language&#x2F;tooling choices.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Crawshaw commenting on expectations of professionalism from OSS authors</title>
          <pubDate>Fri, 10 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-10-crawshaw-commenting-on-expectations-of-professionalism-from-oss-authors/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-10-crawshaw-commenting-on-expectations-of-professionalism-from-oss-authors/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-10-crawshaw-commenting-on-expectations-of-professionalism-from-oss-authors/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-10 22:51 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; X post by David Crawshaw commenting on expectations of professionalism from OSS authors&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; Says independent OSS authors do not owe anyone a professionalized posture, and that salaried open-source workers often project company-style expectations onto people who are just shipping work into the void on their own terms.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Good side-thread in the Andrew&#x2F;Jarred&#x2F;Bun discourse because it reframes part of the conflict as a mismatch between startup&#x2F;company expectations and the norms of independent open-source authorship.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Retrieval note:&lt;&#x2F;strong&gt; Grounded from the X post text itself; no linked article in the post.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Great Divergence in Software Engineering</title>
          <pubDate>Fri, 10 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-10-great-divergence-in-software-engineering/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-10-great-divergence-in-software-engineering/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-10-great-divergence-in-software-engineering/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-10 12:11 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; X post by Geoffrey Huntley linking to Stack72&#x27;s essay &quot;The Great Divergence in Software Engineering&quot;&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; Argues that the gap between teams effectively using AI and teams still piloting or rejecting it is no longer a simple lead but a compounding divergence, driven by retooling workflows, encoding automation, and treating bad AI output as an engineering problem instead of a veto.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Strong framing for AI-native engineering orgs versus incumbents stuck in evaluation loops; good organizational&#x2F;process lens.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Humans Are Just Stochastic Parrots</title>
          <pubDate>Fri, 10 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-10-humans-are-just-stochastic-parrots/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-10-humans-are-just-stochastic-parrots/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-10-humans-are-just-stochastic-parrots/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-10 11:07 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Ryan Dahl essay, &quot;Humans Are Just Stochastic Parrots&quot;&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; A satirical inversion of common anti-LLM critiques, applying them to humans to highlight how shallow many stochastic-parrot arguments are when stripped of their double standard.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Sharp rhetorical piece in the AI discourse wars; useful as culture&#x2F;argumentation rather than technical substance.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Liminality</title>
          <pubDate>Fri, 10 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-10-liminality/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-10-liminality/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-10-liminality/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-10 11:06 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; George Hotz blog post, &quot;Liminality&quot;&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; A reflective, uneasy essay about living in the in-between phase of AI progress, where systems are not yet fully superior but already demoralizing, and where the real challenge is loss of control, hype aside.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Strong cultural&#x2F;psychological framing of the current AI moment from someone close to the frontier, less technical but notable as mood and zeitgeist.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>long talk by the ex-NVIDIA engineer behind Unsloth on fine-tuning and reasoning-model workflows</title>
          <pubDate>Fri, 10 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-10-long-talk-by-the-ex-nvidia-engineer-behind-unsloth-on-fine-tuning-and-reasoning-model-workflows/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-10-long-talk-by-the-ex-nvidia-engineer-behind-unsloth-on-fine-tuning-and-reasoning-model-workflows/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-10-long-talk-by-the-ex-nvidia-engineer-behind-unsloth-on-fine-tuning-and-reasoning-model-workflows/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-10 00:05 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; X post by h100envy summarizing a long talk by the ex-NVIDIA engineer behind Unsloth on fine-tuning and reasoning-model workflows&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; Frames a practical single-GPU stack for local&#x2F;post-training work: choose a base model, use Triton kernels for faster fine-tuning, quantize to 4-bit, run GRPO&#x2F;DPO, and ship a reasoning model on hardware you already own.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Useful pointer for the current small team &#x2F; single GPU post-training stack around Unsloth, Triton, quantization, and RLHF-style methods.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Retrieval note:&lt;&#x2F;strong&gt; I could ground this from the X post text itself, but the linked t.co URL resolved back to the same X post here rather than a separate article&#x2F;video page.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>public launch of Cloud Run sandboxes</title>
          <pubDate>Fri, 10 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-10-public-launch-of-cloud-run-sandboxes/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-10-public-launch-of-cloud-run-sandboxes/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-10-public-launch-of-cloud-run-sandboxes/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-10 00:04 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; X post by Steren announcing the public launch of Cloud Run sandboxes&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; Claims Cloud Run sandboxes can start, execute, and stop 1,000 sandboxes in 5 seconds with roughly 500 ms average latency, positioning them as fast, elastic execution environments.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Worth tracking as managed sandbox&#x2F;runtime infrastructure for agent execution or bursty isolated workloads.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Retrieval note:&lt;&#x2F;strong&gt; I could read the X post metadata&#x2F;text, but the linked t.co URL resolved back to the same X post here rather than exposing a separate launch article.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Soria Parra criticizing Andrew Kelley’s tone toward Jarred Sumner</title>
          <pubDate>Fri, 10 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-10-soria-parra-criticizing-andrew-kelley-s-tone-toward-jarred-sumner/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-10-soria-parra-criticizing-andrew-kelley-s-tone-toward-jarred-sumner/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-10-soria-parra-criticizing-andrew-kelley-s-tone-toward-jarred-sumner/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-10 22:52 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; X post by David Soria Parra criticizing Andrew Kelley’s tone toward Jarred Sumner&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; Argues that project leaders set the tone for their communities, so even strong disagreement should avoid personal criticism and should remain respectful, inclusive, and considerate.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Useful counterpoint within the same Bun&#x2F;Andrew&#x2F;Jarred discourse because it states the strongest community-leadership case against Andrew’s tone, even if the underlying technical critique may still have merit.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Retrieval note:&lt;&#x2F;strong&gt; Grounded from the X post text itself, including the quoted Charlie Marsh post and the direct summary in Soria Parra’s text.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Cloudflare blog post introducing Meerkat, a new global consensus service built on the QuePaxa algorithm</title>
          <pubDate>Thu, 09 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-09-cloudflare-blog-post-introducing-meerkat-a-new-global-consensus-service-built-on-the-quepaxa-algori/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-09-cloudflare-blog-post-introducing-meerkat-a-new-global-consensus-service-built-on-the-quepaxa-algori/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-09-cloudflare-blog-post-introducing-meerkat-a-new-global-consensus-service-built-on-the-quepaxa-algori/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-09 23:10 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Cloudflare blog post introducing Meerkat, a new global consensus service built on the QuePaxa algorithm&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; Cloudflare is building Meerkat for strongly consistent control-plane state across 330+ data centers, arguing that leader-and-timeout-heavy approaches like Raft are a poor fit for hostile WAN conditions and that QuePaxa’s all-replicas-can-write model better matches their network.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Notable systems&#x2F;infrastructure piece on consensus design beyond Raft, especially for globally distributed control planes.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Rewriting Bun in Rust</title>
          <pubDate>Thu, 09 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-09-rewriting-bun-in-rust/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-09-rewriting-bun-in-rust/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-09-rewriting-bun-in-rust/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-09 10:34 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; X post by Jarred Sumner linking to Bun&#x27;s post &quot;Rewriting Bun in Rust&quot;&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; Explains why Bun is being rewritten from Zig to Rust, positioning the move around long-term stability and maintainability as the project scales, even though Zig was instrumental in making the original ambitious build possible.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Another data point on language&#x2F;runtime rewrites in core developer tooling, especially where scaling and reliability start to dominate raw early-stage velocity.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>How I Use Codex To Automate Parts Of My Research Workflow</title>
          <pubDate>Wed, 08 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-08-how-i-use-codex-to-automate-parts-of-my-research-workflow/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-08-how-i-use-codex-to-automate-parts-of-my-research-workflow/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-08-how-i-use-codex-to-automate-parts-of-my-research-workflow/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-08 23:02 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; X post by Maksym Andriushchenko linking to a Substack post, &quot;How I Use Codex To Automate Parts Of My Research Workflow&quot;&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; A pragmatic writeup on using Codex to reduce friction in AI safety research by offloading search, organization, setup, checking, and memory, while keeping human judgment and publication responsibility firmly in the loop.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Good example of disciplined, scoped agent adoption for research workflows rather than full autonomy theater.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Some new agentic patterns</title>
          <pubDate>Wed, 08 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-08-some-new-agentic-patterns/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-08-some-new-agentic-patterns/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-08-some-new-agentic-patterns/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-08 22:40 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; X post by Bilgin Ibryam linking to Prime Radiant&#x27;s &quot;Some new agentic patterns&quot;&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; Describes production-ish internal agent patterns built around an &quot;agentic user in the loop&quot; model, with agents in Slack handling intake, ticketing, wiki updates, EA-style assistance, and subagent&#x2F;container-backed workflows.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Concrete patterns for embedding agents into team operations without pretending they are fully autonomous replacements.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Why TypeScript 7.0 Was Rewritten in Go (and what it means for your dev stack)</title>
          <pubDate>Wed, 08 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-08-why-typescript-7-0-was-rewritten-in-go-and-what-it-means-for-your-dev-stack/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-08-why-typescript-7-0-was-rewritten-in-go-and-what-it-means-for-your-dev-stack/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-08-why-typescript-7-0-was-rewritten-in-go-and-what-it-means-for-your-dev-stack/">&lt;p&gt;&lt;strong&gt;Logged at IST:&lt;&#x2F;strong&gt; 2026-07-08 22:32 IST&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; X post by Steve Francia linking to his post &quot;Why TypeScript 7.0 Was Rewritten in Go (and what it means for your dev stack)&quot;&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; Argues the TypeScript team’s Go rewrite is a broader signal that agentic software stacks increasingly benefit from compiled, readable, operationally sturdy languages rather than scripting-first ones.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; Strong take on language&#x2F;runtime choices for AI-assisted and agent-heavy developer workflows.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>10 Lessons for Agentic Coding</title>
          <pubDate>Mon, 06 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-06-10-lessons-for-agentic-coding/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-06-10-lessons-for-agentic-coding/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-06-10-lessons-for-agentic-coding/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Drew Breunig revisiting his &quot;10 Lessons for Agentic Coding&quot; list and asking for additions&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; the piece frames coding agents as making code cheap but not making judgment cheap; strongest lessons are to implement&#x2F;rebuild to learn, invest in end-to-end tests, document intent, keep specs in sync, automate the easy stuff, and remember maintenance&#x2F;support&#x2F;security still dominate long-term cost&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; the durable agentic-coding playbook is shifting from code production to taste, contracts, and operational discipline&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Retrieval note:&lt;&#x2F;strong&gt; X post extracted via FXTwitter API; linked article read directly from dbreunig.com&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>agentic-inbox</title>
          <pubDate>Mon, 06 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-06-agentic-inbox/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-06-agentic-inbox/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-06-agentic-inbox/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; hands-on writeup of deploying Cloudflare’s official &lt;code&gt;agentic-inbox&lt;&#x2F;code&gt; to run a custom-domain email client on Cloudflare Workers&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; the stack uses Email Routing for inbound mail, Email Service for sending, Durable Objects + SQLite for mailboxes, R2 for attachments, and Cloudflare Access for auth. Main operational gotcha is that one-click deploy is not enough: you still have to wire the Email Routing catch-all and set the Access secrets or the app won’t work&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; agentic inboxes are becoming deployable infra products, but the real story is the surrounding control plane and auth plumbing&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Retrieval note:&lt;&#x2F;strong&gt; article body was embedded in the site JS bundle; direct HTML was mostly a shell page&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Andrej Jovanović announcing the Red Queen Gödel Machine (arXiv:2606.26294)</title>
          <pubDate>Mon, 06 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-06-andrej-jovanovi-announcing-the-red-queen-g-del-machine-arxiv-2606-26294/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-06-andrej-jovanovi-announcing-the-red-queen-g-del-machine-arxiv-2606-26294/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-06-andrej-jovanovi-announcing-the-red-queen-g-del-machine-arxiv-2606-26294/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Andrej Jovanović announcing the Red Queen Gödel Machine (arXiv:2606.26294)&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; self-improving agents should co-evolve with the evaluators that judge them; otherwise stronger agents just learn to exploit stale tests. Paper claims better coding performance with 1.35x–1.72x fewer tokens plus gains in review&#x2F;grading tasks&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; smarter agents need smarter judges; the judge is becoming part of the frontier&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Retrieval note:&lt;&#x2F;strong&gt; metadata&#x2F;abstract pulled from arXiv; early reproduction repo found at &lt;code&gt;ianyac&#x2F;red-queen-godel-machine&lt;&#x2F;code&gt;&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Animesh Pathak pointing to his explainer on MCP’s move toward a stateless architecture</title>
          <pubDate>Mon, 06 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-06-animesh-pathak-pointing-to-his-explainer-on-mcp-s-move-toward-a-stateless-architecture/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-06-animesh-pathak-pointing-to-his-explainer-on-mcp-s-move-toward-a-stateless-architecture/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-06-animesh-pathak-pointing-to-his-explainer-on-mcp-s-move-toward-a-stateless-architecture/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Animesh Pathak pointing to his explainer on MCP’s move toward a stateless architecture&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; argues upcoming MCP changes remove protocol-level sessions and the initialize handshake, make each request self-contained via per-request context and headers, and replace implicit session state with explicit handles like &lt;code&gt;job_id&lt;&#x2F;code&gt; &#x2F; &lt;code&gt;conversation_id&lt;&#x2F;code&gt;; the payoff is easier horizontal scaling, no sticky sessions, and simpler cloud&#x2F;serverless deployment&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; MCP is maturing from a convenient developer protocol into something shaped by real distributed-systems constraints&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Retrieval note:&lt;&#x2F;strong&gt; X post extracted via FXTwitter API; linked article read directly from sonichigo.com&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Chris Short’s DevOps’ish 316 roundup</title>
          <pubDate>Mon, 06 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-06-chris-short-s-devops-ish-316-roundup/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-06-chris-short-s-devops-ish-316-roundup/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-06-chris-short-s-devops-ish-316-roundup/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Chris Short’s DevOps’ish 316 roundup&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; strongest signals are ClickHouse gaining observability mindshare, Vint Cerf warning that agents will need more formal coordination than plain English, Podman 6.0 breaking old assumptions, and agent-secret hygiene as an architecture problem&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; infra edge signals, observability economics, protocolized agents, and security boundaries around agent tooling&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Retrieval note:&lt;&#x2F;strong&gt; roundup page fetched directly from devopsish.com&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Cost YAGNI Was Never About</title>
          <pubDate>Mon, 06 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-06-cost-yagni-was-never-about/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-06-cost-yagni-was-never-about/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-06-cost-yagni-was-never-about/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; X post by Bilgin Ibryam pointing to Kent Beck’s “The Cost YAGNI Was Never About”&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; YAGNI is about timing and option value, not code-writing thrift; AI codegen lowers typing cost but increases the risk of speculative structure nobody deeply understands&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; code can be cheap to generate and still expensive to commit to&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Retrieval note:&lt;&#x2F;strong&gt; article text recovered directly from Kent Beck’s newsletter page&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>GenPage: Towards End-to-End Generative Homepage Construction at Netflix</title>
          <pubDate>Mon, 06 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-06-genpage-towards-end-to-end-generative-homepage-construction-at-netflix/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-06-genpage-towards-end-to-end-generative-homepage-construction-at-netflix/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-06-genpage-towards-end-to-end-generative-homepage-construction-at-netflix/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Shubham Mishra pointing to Netflix TechBlog’s “GenPage: Towards End-to-End Generative Homepage Construction at Netflix”&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; describes Netflix replacing a multi-stage homepage recommendation&#x2F;ranking assembly pipeline with a single generative system that treats viewing history as prompt context and generates the full homepage layout, rows, and titles in one pass; the reported upside is higher engagement plus about 20% lower serving latency than the production system it replaced&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; richer user context and simpler end-to-end generation can beat a stack of specialized personalization stages&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Retrieval note:&lt;&#x2F;strong&gt; X post extracted via FXTwitter API; article grounded via Netflix TechBlog metadata&#x2F;description page fetch&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Harness Engineering for Self-Improvement</title>
          <pubDate>Mon, 06 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-06-harness-engineering-for-self-improvement/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-06-harness-engineering-for-self-improvement/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-06-harness-engineering-for-self-improvement/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Lilian Weng sharing her new Lil&#x27;Log post, &quot;Harness Engineering for Self-Improvement&quot;&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; argues recursive self-improvement will depend not just on better base models but on better harnesses, the runtime layer that manages tools, planning loops, context, permissions, persistent files, evaluation, and subagents. Strong recurring patterns are workflow automation, file-system-backed persistent memory, and explicit parallel subagent&#x2F;job management&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; the real frontier in RSI may be the software system around the model, not just the model weights themselves&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Retrieval note:&lt;&#x2F;strong&gt; X post extracted via FXTwitter API; linked Lil&#x27;Log article read directly and grounded via article body metadata in page HTML&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>lutke linking to a new Evolution paper by Steven A. Frank</title>
          <pubDate>Mon, 06 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-06-lutke-linking-to-a-new-evolution-paper-by-steven-a-frank/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-06-lutke-linking-to-a-new-evolution-paper-by-steven-a-frank/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-06-lutke-linking-to-a-new-evolution-paper-by-steven-a-frank/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; X post by tobi lutke linking to a new Evolution paper by Steven A. Frank&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; paper argues evolvability is best understood as generalization; imports modern ML intuition that larger &#x2F; more parameterized systems can generalize better, then maps that onto biological complexity and genomic&#x2F;regulatory capacity&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; evolution-as-generalization; complexity as reusable-solution capacity rather than mere accumulation&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Retrieval note:&lt;&#x2F;strong&gt; X content recovered via oEmbed; destination paper metadata&#x2F;abstract&#x2F;context reconstructed from Crossref + OpenAlex because publisher page was bot-protected&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Maxime Rivest demo turning a reMarkable Paper Pro into Tom Riddle’s diary</title>
          <pubDate>Mon, 06 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-06-maxime-rivest-demo-turning-a-remarkable-paper-pro-into-tom-riddle-s-diary/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-06-maxime-rivest-demo-turning-a-remarkable-paper-pro-into-tom-riddle-s-diary/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-06-maxime-rivest-demo-turning-a-remarkable-paper-pro-into-tom-riddle-s-diary/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Maxime Rivest demo turning a reMarkable Paper Pro into Tom Riddle’s diary&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; real hardware&#x2F;software hack where handwritten ink fades, an on-device LLM reads the page, and replies animate back in handwriting; strongest idea is AI as object&#x2F;interface magic rather than another chat box&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; narrative interfaces; AI gets more compelling when wrapped in a strong object metaphor&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Retrieval note:&lt;&#x2F;strong&gt; X media post grounded in the linked GitHub repo&#x2F;README (&lt;code&gt;MaximeRivest&#x2F;riddle&lt;&#x2F;code&gt;)&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Miguel Ángel Pastor linking Zalando’s engineering post on client-side load balancing at a million requests...</title>
          <pubDate>Mon, 06 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-06-miguel-ngel-pastor-linking-zalando-s-engineering-post-on-client-side-load-balancing-at-a-million-re/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-06-miguel-ngel-pastor-linking-zalando-s-engineering-post-on-client-side-load-balancing-at-a-million-re/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-06-miguel-ngel-pastor-linking-zalando-s-engineering-post-on-client-side-load-balancing-at-a-million-re/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Miguel Ángel Pastor linking Zalando’s engineering post on client-side load balancing at a million requests per second&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; argues high-fanout internal traffic benefited from moving load balancing into the client process to preserve cache locality, improve debuggability, and avoid shared-ingress distortions; highlights safety work like bounded-load routing and rollout fade-in&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; own the routing decision in-process when cache-sensitive fanout paths make shared infra the bottleneck&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Retrieval note:&lt;&#x2F;strong&gt; extracted cleanly via FXTwitter API; card points to the Zalando engineering article&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;&#x2F;strong&gt; overlaps with the same Zalando piece already logged earlier via Werner Vogels on 2026-07-02, but this direct share is now recorded too&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Nithin Kamath on Zerodha’s operating culture</title>
          <pubDate>Mon, 06 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-06-nithin-kamath-on-zerodha-s-operating-culture/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-06-nithin-kamath-on-zerodha-s-operating-culture/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-06-nithin-kamath-on-zerodha-s-operating-culture/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Nithin Kamath on Zerodha’s operating culture&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; a nice place to work is not accidental culture but the result of repeated leadership choices, slowing down to avoid burnout, staying small, avoiding fear-based management, letting tech make technical decisions, and refusing toxic revenue incentives&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Notable line:&lt;&#x2F;strong&gt; “A nice place to work is not a perk we offer. It is kind of a business model in itself.”&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; culture as operating system &#x2F; business model, not HR perk&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Retrieval note:&lt;&#x2F;strong&gt; read directly from source post&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>agent-driven testing and token cost tradeoffs between text buffers and screenshots</title>
          <pubDate>Sun, 05 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-05-agent-driven-testing-and-token-cost-tradeoffs-between-text-buffers-and-screenshots/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-05-agent-driven-testing-and-token-cost-tradeoffs-between-text-buffers-and-screenshots/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-05-agent-driven-testing-and-token-cost-tradeoffs-between-text-buffers-and-screenshots/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;X post by @jlongster on agent-driven testing and token cost tradeoffs between text buffers and screenshots.&lt;&#x2F;li&gt;
&lt;li&gt;Gist: for app-testing agents, screenshots are surprisingly close to text buffers on token cost in some models, but vary a lot by provider&#x2F;model; OpenAI looks relatively cheap for images in his comparison while Anthropic is notably higher.&lt;&#x2F;li&gt;
&lt;li&gt;Why it matters: useful for designing UI&#x2F;testing agents without assuming vision is prohibitively expensive.&lt;&#x2F;li&gt;
&lt;li&gt;Newsletter angle: “vision for agentic testing may already be economically viable, depending on model choice.”&lt;&#x2F;li&gt;
&lt;li&gt;Retrieval note: extracted post via FXTwitter API; fetched linked token-count comparison page for supporting numbers&#x2F;context.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
      <item>
          <title>replying to @_svs_, quoting Neil Gaiman’s 2013 Guardian piece on libraries&#x2F;reading&#x2F;daydreaming</title>
          <pubDate>Sun, 05 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-05-replying-to-svs-quoting-neil-gaiman-s-2013-guardian-piece-on-libraries-reading-daydreaming/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-05-replying-to-svs-quoting-neil-gaiman-s-2013-guardian-piece-on-libraries-reading-daydreaming/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-05-replying-to-svs-quoting-neil-gaiman-s-2013-guardian-piece-on-libraries-reading-daydreaming/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;X post by @captn3m0 replying to @&lt;em&gt;svs&lt;&#x2F;em&gt;, quoting Neil Gaiman’s 2013 Guardian piece on libraries&#x2F;reading&#x2F;daydreaming.&lt;&#x2F;li&gt;
&lt;li&gt;Gist: pushback on using science fiction as an interpretive frame for AI; claim is SF is valuable for dreams&#x2F;imagination, but bad as an answer-book or analogy source for present AI.&lt;&#x2F;li&gt;
&lt;li&gt;Why it matters: clean distinction between fiction as imagination engine vs fiction as policy&#x2F;analysis substrate.&lt;&#x2F;li&gt;
&lt;li&gt;Newsletter angle: “stop using sci-fi as AI governance shorthand” &#x2F; tension between imagination’s value and analogy overreach.&lt;&#x2F;li&gt;
&lt;li&gt;Retrieval note: extracted post via FXTwitter API; fetched linked Guardian article for surrounding quote&#x2F;context.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
      <item>
          <title>claiming strong GLM 5.2 serving results on AMD MI355X versus Nvidia Blackwell&#x2F;B200</title>
          <pubDate>Sat, 04 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-04-claiming-strong-glm-5-2-serving-results-on-amd-mi355x-versus-nvidia-blackwell-b200/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-04-claiming-strong-glm-5-2-serving-results-on-amd-mi355x-versus-nvidia-blackwell-b200/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-04-claiming-strong-glm-5-2-serving-results-on-amd-mi355x-versus-nvidia-blackwell-b200/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; X post from wafer claiming strong GLM 5.2 serving results on AMD MI355X versus Nvidia Blackwell&#x2F;B200.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “AMD is no longer just the cheap alternative” framing, with the real story likely in compiler&#x2F;kernel&#x2F;serving-stack optimization rather than raw silicon alone.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Retrieval note:&lt;&#x2F;strong&gt; extracted via FXTwitter API; inspected attached image for visible metrics; full reply-thread write-up not retrieved.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Putting an Agent in an Orb</title>
          <pubDate>Sat, 04 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-04-putting-an-agent-in-an-orb/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-04-putting-an-agent-in-an-orb/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-04-putting-an-agent-in-an-orb/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; X post praising Thorsten Ball’s Amp note “Putting an Agent in an Orb.”&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; the useful shift is from “smart model” to “legible environment”, paved paths, observability, and anti-guessing ergonomics matter as much as model quality.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Retrieval note:&lt;&#x2F;strong&gt; extracted via FXTwitter API + fetched linked article directly.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Read More (Science) Fiction</title>
          <pubDate>Sat, 04 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-04-read-more-science-fiction/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-04-read-more-science-fiction/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-04-read-more-science-fiction/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; X post from svs sharing his essay “Read More (Science) Fiction.”&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “read more sci-fi” is the visible conclusion, but the sharper claim is that fiction supplies vocab and priors for handling agentic weirdness without naive hype or naive panic.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Retrieval note:&lt;&#x2F;strong&gt; extracted via FXTwitter API + fetched linked article directly.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Should LLMs just treat text content as an image?</title>
          <pubDate>Sat, 04 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-04-should-llms-just-treat-text-content-as-an-image/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-04-should-llms-just-treat-text-content-as-an-image/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-04-should-llms-just-treat-text-content-as-an-image/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; X reply from Michigan TypeScript pointing to Sean Goedecke’s post “Should LLMs just treat text content as an image?”&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; counterintuitive interface hack + deeper architectural question about whether text should sometimes ride the vision path.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Retrieval note:&lt;&#x2F;strong&gt; extracted via FXTwitter API + fetched linked article directly.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>mega thread</title>
          <pubDate>Thu, 02 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-02-mega-thread/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-02-mega-thread/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-02-mega-thread/">&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; core claim is that even with coding agents, engineers still need to understand the generated code; the opening slide frames this as “understanding is the new bottleneck.”&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “understanding is the new bottleneck” as a useful lens for evaluating coding-agent workflows and developer tooling.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Retrieval note:&lt;&#x2F;strong&gt; root post text was readable directly via X&#x2F;FXTwitter and the attached slide was OCR’d; full thread body beyond the opener is still not captured.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Robot Privilege and the Jetson Delusion</title>
          <pubDate>Thu, 02 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-02-robot-privilege-and-the-jetson-delusion/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-02-robot-privilege-and-the-jetson-delusion/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-02-robot-privilege-and-the-jetson-delusion/">&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; the argument is that domestic robots will create an extraordinarily intimate surveillance layer inside the home, while the underlying article argues humanoid home robots are the wrong form factor, dexterity, cost, weight, and safety push the practical future toward specialized wheeled systems with manipulators, not Rosie-style androids.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “the domestic robot is a privacy and form-factor story, not just an autonomy story” or “human touch becomes luxury as cognition gets cheaper.”&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Retrieval note:&lt;&#x2F;strong&gt; X post extracted via FXTwitter API; linked Substack article fetched directly and partially read successfully.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Vogels pointing to Zalando’s engineering writeup on client-side load balancing for a very high fan-out API...</title>
          <pubDate>Thu, 02 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-02-vogels-pointing-to-zalando-s-engineering-writeup-on-client-side-load-balancing-for-a-very-high-fan/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-02-vogels-pointing-to-zalando-s-engineering-writeup-on-client-side-load-balancing-for-a-very-high-fan/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-02-vogels-pointing-to-zalando-s-engineering-writeup-on-client-side-load-balancing-for-a-very-high-fan/">&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; Zalando moved internal fan-out traffic off shared ingress and into an in-process client-side load balancer to preserve consistent-hash cache locality, cut latency spikes, improve debuggability, and reduce shared infra cost. The interesting details are the safety&#x2F;operability work: exact hash parity with Skipper, informer-based pod discovery, N-ring fade-in for scale-ups, and bounded-load routing using occupancy plus latency instead of naive in-flight&#x2F;request-rate signals.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “own the routing decision in-process” or “occupancy beats request-rate for bounded load” as the memorable lesson.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Retrieval note:&lt;&#x2F;strong&gt; X post extracted via FXTwitter API; linked Zalando article fetched directly and partially read successfully.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>about Passmark, an open-source Playwright library for AI browser regression testing</title>
          <pubDate>Wed, 01 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-01-about-passmark-an-open-source-playwright-library-for-ai-browser-regression-testing/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-01-about-passmark-an-open-source-playwright-library-for-ai-browser-regression-testing/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-01-about-passmark-an-open-source-playwright-library-for-ai-browser-regression-testing/">&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; Passmark checks an LLM cache before making fresh model calls during browser tests, reportedly cutting a 7-minute suite down to 90 seconds.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “cache-first AI browser testing” as practical infra for regression pipelines.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Retrieval note:&lt;&#x2F;strong&gt; tweet extracted via FXTwitter API; attached screenshot shows the GitHub repo tagline mentioning intelligent caching, authentication, and multi-model verification.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Claude Code Is Steganographically Marking Requests</title>
          <pubDate>Wed, 01 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-01-claude-code-is-steganographically-marking-requests/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-01-claude-code-is-steganographically-marking-requests/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-01-claude-code-is-steganographically-marking-requests/">&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; claim is that Claude Code inserts hidden&#x2F;system-prompt markers tied to API base URL and timezone; privacy&#x2F;trust implications if true.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “invisible metadata in coding-agent requests” as a prompt-layer trust&#x2F;safety story.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Retrieval note:&lt;&#x2F;strong&gt; X content extracted via FXTwitter API; linked article itself was Cloudflare-blocked, so article summary is currently based on title&#x2F;card&#x2F;snippet only.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Ponnappa sharing a Realfast blog post by Harsh Jain</title>
          <pubDate>Wed, 01 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-01-ponnappa-sharing-a-realfast-blog-post-by-harsh-jain/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-01-ponnappa-sharing-a-realfast-blog-post-by-harsh-jain/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-01-ponnappa-sharing-a-realfast-blog-post-by-harsh-jain/">&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; the claim is that in large legacy systems, the bottleneck is not typing code but building enough system understanding to change it safely and quickly; LLMs compress that comprehension step.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “AI helps most where system understanding dominates implementation” with a grounded enterprise-delivery example.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Retrieval note:&lt;&#x2F;strong&gt; extracted via FXTwitter API; linked article title&#x2F;card also reinforce the same point (“Velocity isn&#x27;t lines per day. It&#x27;s knowing which lines matter.”).&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Prateek describing an AI SRE workflow built with SigNoz by a 3-person team at Alien Intelligence</title>
          <pubDate>Wed, 01 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-01-prateek-describing-an-ai-sre-workflow-built-with-signoz-by-a-3-person-team-at-alien-intelligence/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-01-prateek-describing-an-ai-sre-workflow-built-with-signoz-by-a-3-person-team-at-alien-intelligence/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-01-prateek-describing-an-ai-sre-workflow-built-with-signoz-by-a-3-person-team-at-alien-intelligence/">&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; an agent now does first-pass noisy-alert triage by checking telemetry plus infra context, then escalates to the human with a Slack summary only when needed.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “AI as first-line SRE” with telemetry&#x2F;context fusion instead of generic chatbot alerting.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Retrieval note:&lt;&#x2F;strong&gt; extracted via FXTwitter API; the tweet says the actual blog link is in a reply, so the deeper writeup is not yet captured.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Soria Parra announcing MCP SDK v2 betas ahead of a new stateless MCP spec slated for July 28</title>
          <pubDate>Wed, 01 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-07-01-soria-parra-announcing-mcp-sdk-v2-betas-ahead-of-a-new-stateless-mcp-spec-slated-for-july-28/</link>
          <guid>https://reading-list.oddship.net/notes/2026-07-01-soria-parra-announcing-mcp-sdk-v2-betas-ahead-of-a-new-stateless-mcp-spec-slated-for-july-28/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-07-01-soria-parra-announcing-mcp-sdk-v2-betas-ahead-of-a-new-stateless-mcp-spec-slated-for-july-28/">&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; Typescript SDK v2.0.0-beta.1 and Python SDK v2.0.0b1 are out; goal is to make building MCP servers and clients easier, with feedback requested on ergonomics.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “stateless MCP lands July 28” plus what SDK v2 means for tool&#x2F;server implementers.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Retrieval note:&lt;&#x2F;strong&gt; extracted via FXTwitter API; linked GitHub release URLs were present in the tweet body.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Profiling | Internals for Interns</title>
          <pubDate>Tue, 30 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-30-profiling-internals-for-interns/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-30-profiling-internals-for-interns/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-30-profiling-internals-for-interns/">&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; all five profiles emit the same pprof structure; the core difference is collection model, CPU samples asynchronously via signal + ring buffer, heap&#x2F;block&#x2F;mutex aggregate in per-stack tables in place, goroutine snapshots stacks on demand.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “pprof is one file format over three collection strategies” is a clean framing hook.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Retrieval note:&lt;&#x2F;strong&gt; extracted via FXTwitter API + linked article fetch.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Tangled’s writeup on its new QEMU microVM engine for Spindle CI runners</title>
          <pubDate>Tue, 30 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-30-tangled-s-writeup-on-its-new-qemu-microvm-engine-for-spindle-ci-runners/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-30-tangled-s-writeup-on-its-new-qemu-microvm-engine-for-spindle-ci-runners/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-30-tangled-s-writeup-on-its-new-qemu-microvm-engine-for-spindle-ci-runners/">&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; each workflow runs in its own microVM; guest agent talks back over vsock; NixOS-based workflow config can declaratively enable services like Postgres and Docker; cache&#x2F;proxy design keeps guests isolated from direct network&#x2F;cache credentials while still reusing built artifacts.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “microVMs as the unit of CI isolation, with NixOS as workflow-defined machine config” is a solid hook.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Retrieval note:&lt;&#x2F;strong&gt; extracted via FXTwitter API + linked article fetch.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Orosz linking Semgrep’s benchmark writeup on GLM 5.2 vs Claude for IDOR detection</title>
          <pubDate>Mon, 29 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-29-orosz-linking-semgrep-s-benchmark-writeup-on-glm-5-2-vs-claude-for-idor-detection/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-29-orosz-linking-semgrep-s-benchmark-writeup-on-glm-5-2-vs-claude-for-idor-detection/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-29-orosz-linking-semgrep-s-benchmark-writeup-on-glm-5-2-vs-claude-for-idor-detection/">&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; on Semgrep’s IDOR benchmark, GLM 5.2 scored 39% F1 in a simple prompt-only PydanticAI harness, beating Claude Code’s 32% while costing roughly $0.17 per vulnerability found; Semgrep’s own endpoint-discovery multimodal harness still led overall at 53–61% F1.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “the harness matters more than the model, until a cheap open model gets good enough to change the default stack.”&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>You and Your Research</title>
          <pubDate>Mon, 29 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-29-you-and-your-research/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-29-you-and-your-research/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-29-you-and-your-research/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Essay: “You and Your Research” &#x2F; R.W. Hamming’s advice on doing important work.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; Hamming argues that great work comes from repeatedly choosing important problems, preparing a strong attack in advance, keeping a running list of big questions, and combining hard work with openness, courage, and sustained emotional commitment.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; timeless research&#x2F;career advice that maps well to modern engineering: maintain a list of important problems, keep your door open to clues, and optimize for meaningful problems rather than local busyness.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Engineering for Bounded Cognition</title>
          <pubDate>Sun, 28 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-28-engineering-for-bounded-cognition/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-28-engineering-for-bounded-cognition/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-28-engineering-for-bounded-cognition/">&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; good engineering is mostly about shaping systems so small, distractible minds can change them safely, via naming, boundaries, tests, reversibility, and interfaces that assume attention is scarce rather than ideal operators.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “Build for bounded attention, not ideal operators.”&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Orosz quoting Brian Armstrong on Coinbase AI infra economics</title>
          <pubDate>Sun, 28 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-28-orosz-quoting-brian-armstrong-on-coinbase-ai-infra-economics/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-28-orosz-quoting-brian-armstrong-on-coinbase-ai-infra-economics/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-28-orosz-quoting-brian-armstrong-on-coinbase-ai-infra-economics/">&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; Coinbase reportedly cut AI spend nearly in half while token usage kept growing by changing defaults to cheaper open-weight models (GLM 5.2, Kimi 2.7), adding smarter routing, aggressively using caching, and keeping context lean instead of tightening caps.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “AI cost control is becoming a systems problem, not a policy problem.”&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>slime</title>
          <pubDate>Sun, 28 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-28-slime/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-28-slime/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-28-slime/">&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; the design claim is “one stable RL kernel, task-specific variety in data generation.” Training stays fixed; multi-turn tools, environment feedback, verifier rewards, and other agent behaviors are modeled as rollout&#x2F;data-gen differences rather than separate trainer forks.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “Agent RL stacks may converge on a small trusted core plus flexible data-generation layers.”&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Adithya Venkatesan sharing Alter Magazine’s piece on designing ice cream for Indian conditions</title>
          <pubDate>Fri, 26 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-26-adithya-venkatesan-sharing-alter-magazine-s-piece-on-designing-ice-cream-for-indian-conditions/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-26-adithya-venkatesan-sharing-alter-magazine-s-piece-on-designing-ice-cream-for-indian-conditions/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-26-adithya-venkatesan-sharing-alter-magazine-s-piece-on-designing-ice-cream-for-indian-conditions/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Adithya Venkatesan sharing Alter Magazine’s piece on designing ice cream for Indian conditions&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; frames ice cream as a four-phase material, ice crystals, unfrozen sugar syrup, churned-in air, and a fat network, and argues Indian heat + weak cold-chain conditions make conventional formulations degrade fast; points to adaptations like denser kulfi-ish formulations, freezing at serve time, and rebalancing protein&#x2F;fibre vs sugar&#x2F;fat for stability&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “designing for India” through thermodynamics&#x2F;material science rather than just pricing or distribution&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Bilgin Ibryam sharing an article on Portkey’s product-engineering org design</title>
          <pubDate>Fri, 26 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-26-bilgin-ibryam-sharing-an-article-on-portkey-s-product-engineering-org-design/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-26-bilgin-ibryam-sharing-an-article-on-portkey-s-product-engineering-org-design/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-26-bilgin-ibryam-sharing-an-article-on-portkey-s-product-engineering-org-design/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Bilgin Ibryam sharing an article on Portkey’s product-engineering org design&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; highlights a notably lean product org, 24 product engineers, 1 product designer, 0 PMs, and frames the build&#x2F;operating model as the interesting part&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “the product engineer company” &#x2F; what gets easier or riskier when PM functions collapse into eng&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>cursed code</title>
          <pubDate>Fri, 26 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-26-cursed-code/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-26-cursed-code/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-26-cursed-code/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Tim McNamara sharing an IOCCC-winning “cursed code” project where Pong advances by rewriting its own source each frame&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; the linked repo, &lt;code&gt;uellenberg&#x2F;Insert&lt;&#x2F;code&gt;, is a small language for self-modifying code; programs can access their own source as string fragments, overwrite marked values, print the next version of themselves, and in the Pong demo each run emits the source for the next frame before recompiling&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “playful programming systems” &#x2F; self-modifying code as art rather than anti-pattern&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>David Crawshaw note&#x2F;article on exe.dev’s open-source stance</title>
          <pubDate>Fri, 26 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-26-david-crawshaw-note-article-on-exe-dev-s-open-source-stance/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-26-david-crawshaw-note-article-on-exe-dev-s-open-source-stance/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-26-david-crawshaw-note-article-on-exe-dev-s-open-source-stance/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; David Crawshaw note&#x2F;article on exe.dev’s open-source stance&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; strong pro-open-source bias, but keeps bespoke infra pieces closed because making them usable&#x2F;supportable externally would cost ~25% of eng time; code that runs in the user’s VM (agent&#x2F;Shelley) is open source under a permissive license with CLA&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “open source the user-facing plane, keep bespoke internal substrate closed when support burden dominates”&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Fatih Arslan asking whether anyone has made git worktrees feel natural in daily use</title>
          <pubDate>Fri, 26 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-26-fatih-arslan-asking-whether-anyone-has-made-git-worktrees-feel-natural-in-daily-use/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-26-fatih-arslan-asking-whether-anyone-has-made-git-worktrees-feel-natural-in-daily-use/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-26-fatih-arslan-asking-whether-anyone-has-made-git-worktrees-feel-natural-in-daily-use/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Fatih Arslan asking whether anyone has made git worktrees feel natural in daily use&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; straightforward practitioner complaint that worktrees remain awkward even after repeated attempts; useful mainly as a prompt for workflow&#x2F;tooling patterns rather than as a claim-heavy post&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “great primitive, bad default ergonomics” as a recurring pattern in developer tools&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Go&#x2F;security post on building a self-hosted LLM security proxy with sub-2ms prompt inspection</title>
          <pubDate>Fri, 26 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-26-go-security-post-on-building-a-self-hosted-llm-security-proxy-with-sub-2ms-prompt-inspection/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-26-go-security-post-on-building-a-self-hosted-llm-security-proxy-with-sub-2ms-prompt-inspection/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-26-go-security-post-on-building-a-self-hosted-llm-security-proxy-with-sub-2ms-prompt-inspection/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Go&#x2F;security post on building a self-hosted LLM security proxy with sub-2ms prompt inspection&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; author built an OpenAI-compatible reverse proxy (“Tamga”) that scans prompts for PII, secrets, and prompt-injection patterns before forwarding to providers; key engineering lesson is a hybrid scan pipeline where cheap CPU-bound detectors run sequentially while slower network&#x2F;model-backed scanners run in parallel, because goroutine orchestration overhead dominated when everything fanned out&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; concrete infra pattern for “LLM middleware” that is more about latency budgets and data residency than model eval hype&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>How I use LLMs as a staff engineer in 2026</title>
          <pubDate>Fri, 26 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-26-how-i-use-llms-as-a-staff-engineer-in-2026/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-26-how-i-use-llms-as-a-staff-engineer-in-2026/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-26-how-i-use-llms-as-a-staff-engineer-in-2026/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Bilgin Ibryam sharing Sean Goedecke’s updated “How I use LLMs as a staff engineer in 2026” workflow writeup&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; the notable shift versus 2025 is treating agents as default collaborators for nearly every code change, bug investigation, codebase research, testing, and local setup, while still keeping humans responsible for review, judgment, PR descriptions, ADRs&#x2F;messages, and UI evaluation; especially strong on the idea that current agents are now good enough to generate full PRs and chase bugs across repos, but still need selection, steering, and rejection by an experienced engineer&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; probably one of the cleaner descriptions of the real 2026 boundary between agent labor and human judgment&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>levelsio linking Scroll Prize’s announcement that a full Herculaneum scroll was read without physically ope...</title>
          <pubDate>Fri, 26 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-26-levelsio-linking-scroll-prize-s-announcement-that-a-full-herculaneum-scroll-was-read-without-physic/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-26-levelsio-linking-scroll-prize-s-announcement-that-a-full-herculaneum-scroll-was-read-without-physic/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-26-levelsio-linking-scroll-prize-s-announcement-that-a-full-herculaneum-scroll-was-read-without-physic/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; levelsio linking Scroll Prize’s announcement that a full Herculaneum scroll was read without physically opening it&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; PHerc. 1667 was virtually unwrapped end-to-end using high-res X-ray scans, geometry reconstruction, and ML ink detection; ~1.4m of papyrus &#x2F; ~22 Greek columns recovered, apparently a Stoic ethics text tied to Aristocreon, with data + code released openly&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; non-hype example of ML creating new archaeological&#x2F;scientific access, not just speeding up existing workflows&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Rhys Sullivan note on why MCP underdelivered initially and what comes next</title>
          <pubDate>Fri, 26 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-26-rhys-sullivan-note-on-why-mcp-underdelivered-initially-and-what-comes-next/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-26-rhys-sullivan-note-on-why-mcp-underdelivered-initially-and-what-comes-next/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-26-rhys-sullivan-note-on-why-mcp-underdelivered-initially-and-what-comes-next/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Rhys Sullivan note on why MCP underdelivered initially and what comes next&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; argues MCP launched in the GPT-4o &#x2F; Sonnet 3.5 era before good agent&#x2F;tooling patterns were understood, so many servers exposed too few capabilities and clients added too much friction; meanwhile bash&#x2F;CLI-based agents won because they could chain commands, install tools dynamically, and lean on mature shell primitives. His pushback is that this should not end in “just use CLIs”: CLIs hide action semantics and add statefulness, while the better end-state is harnesses that can expose APIs, MCP, CLIs, GraphQL, etc. through one tool catalog&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; crisp explanation of why shell-first agents surged, and why the next layer probably needs to unify API&#x2F;CLI&#x2F;MCP rather than pick one&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Kenton Varda argues against per-agent manual permission configuration and for capability-based security for...</title>
          <pubDate>Wed, 24 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-24-kenton-varda-argues-against-per-agent-manual-permission-configuration-and-for-capability-based-secu/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-24-kenton-varda-argues-against-per-agent-manual-permission-configuration-and-for-capability-based-secu/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-24-kenton-varda-argues-against-per-agent-manual-permission-configuration-and-for-capability-based-secu/">&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; the safe&#x2F;scalable model is many fine-grained task-specific agents, each receiving only the exact capabilities implied by the task context (for example, a pasted doc URL grants access only to that doc). He also argues agent authority should derive from a human principal for accountability, and team-shared setups should be reproducible under each user’s credentials.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; capability security as the missing abstraction for practical agent authorization; good counterpoint to broad workspace-level agent identity models.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Retrieval note:&lt;&#x2F;strong&gt; extracted via FXTwitter API note tweet text; linked post references Anthropic’s agent identity access model.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Visible standouts: The Second Half; Eugene Yan on eval process; Han-Chung Lee on agent eval infra; Hamel&#x2F;Sh...</title>
          <pubDate>Wed, 24 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-24-visible-standouts-the-second-half-eugene-yan-on-eval-process-han-chung-lee-on-agent-eval-infra-hame/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-24-visible-standouts-the-second-half-eugene-yan-on-eval-process-han-chung-lee-on-agent-eval-infra-hame/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-24-visible-standouts-the-second-half-eugene-yan-on-eval-process-han-chung-lee-on-agent-eval-infra-hame/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Visible standouts: The Second Half; Eugene Yan on eval process; Han-Chung Lee on agent eval infra; Hamel&#x2F;Shreya LLM Evals FAQ; Jason Wei on verification; Anthropic on agent evals; Ofir Press on benchmarks; AI Agents That Matter; Building on Evaluation Quicksand; EvalGen; Benches 2026.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; strong starter pack for agent&#x2F;LLM evals; themes include eval infra as technical debt, process over tooling, verifier design, benchmark saturation&#x2F;contamination, agent-specific eval design, and criteria drift.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; compact “best evals reading list” &#x2F; why eval practice is shifting from static benchmarks to systems-level agent evaluation.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Retrieval note:&lt;&#x2F;strong&gt; extracted via FXTwitter API + image OCR from screenshot.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Coming Loop</title>
          <pubDate>Tue, 23 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-23-coming-loop/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-23-coming-loop/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-23-coming-loop/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Armin Ronacher post linking to “The Coming Loop”&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; argues the important new layer in coding agents is the harness-level loop outside the agent itself; loops already work well for bounded, verifiable work like ports, benchmarking, scanning, and research, but he’s skeptical of using them to write long-lived code because they amplify defensive&#x2F;local reasoning, erode strong invariants, and reduce human comprehension.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “The harness is the product” &#x2F; why durable task loops are both inevitable and dangerous.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;&#x2F;strong&gt; extracted via FXTwitter API + article fetch; article body fetched successfully but truncated near the ending in web extract.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>David Rosenthal on the AI affordability crisis</title>
          <pubDate>Tue, 23 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-23-david-rosenthal-on-the-ai-affordability-crisis/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-23-david-rosenthal-on-the-ai-affordability-crisis/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-23-david-rosenthal-on-the-ai-affordability-crisis/">&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; argues model vendors have been massively subsidizing usage to manufacture demand, but token-based pricing is now exposing the real cost structure; for serious enterprise&#x2F;agentic use, compute bills can exceed human labor costs by a wide margin.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; the agent era may run into a pricing wall before it hits a capability wall.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;&#x2F;strong&gt; article extracted successfully via web fetch, though long body was truncated near the footnotes.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>linking filiph.net&#x2F;text&#x2F;pokerd.html</title>
          <pubDate>Fri, 19 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-19-linking-filiph-net-text-pokerd-html/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-19-linking-filiph-net-text-pokerd-html/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-19-linking-filiph-net-text-pokerd-html/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; X post by @filiphracek linking &lt;code&gt;filiph.net&#x2F;text&#x2F;pokerd.html&lt;&#x2F;code&gt;&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; writeup on building &lt;code&gt;pokerd&lt;&#x2F;code&gt;, a terminal-first Texas Hold’em trainer you can play instantly over SSH (&lt;code&gt;ssh play@poker.filiph.net&lt;&#x2F;code&gt;); interesting bits are the non-immersive-game framing, scrollback-friendly TUI choices, bot tuning via self-play + JSONL events, and shipping the game as a passwordless SSH shell inside a container on a VPS.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “SSH as zero-install distribution” &#x2F; terminals as a deliberate product surface, not just a dev tool.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Notes:&lt;&#x2F;strong&gt; extracted via FXTwitter API + blog post (partial long-form read, enough for gist).&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>linking github.com&#x2F;leyten&#x2F;shard</title>
          <pubDate>Fri, 19 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-19-linking-github-com-leyten-shard/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-19-linking-github-com-leyten-shard/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-19-linking-github-com-leyten-shard/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; X post by @leyten linking &lt;code&gt;github.com&#x2F;leyten&#x2F;shard&lt;&#x2F;code&gt;&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; Shard is a WAN-distributed pipeline-parallel LLM inference engine that splits a frontier-size model across GPUs on separate machines; claim is ~30 tok&#x2F;s for GLM-5.2 744B across 6 RTX PRO 6000s in 6 US states using speculative decoding, async pipelining, and a CUDA-graphed draft model.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “frontier inference without a datacenter” &#x2F; distributed serving as systems engineering rather than centralized infra.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Notes:&lt;&#x2F;strong&gt; extracted via FXTwitter API + GitHub README.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>AI lab business models: subscription vs API</title>
          <pubDate>Fri, 12 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-12-ai-lab-business-models-subscription-vs-api/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-12-ai-lab-business-models-subscription-vs-api/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-12-ai-lab-business-models-subscription-vs-api/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; X thread by SemiAnalysis on AI lab business models: subscription vs API.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; based on exhausting weekly limits with real long-horizon coding tasks, they claim consumer subscriptions are far more generous than common “monthly fee ~= API token value ceiling” assumptions. The attached table estimates approximate max monthly value at Claude Pro $20-&amp;gt;$400, Claude Max 5x $100-&amp;gt;$2,000, Claude Max 20x $200-&amp;gt;$8,000; ChatGPT Plus $20-&amp;gt;$700, Pro 5x $100-&amp;gt;$3,500, Pro 20x $200-&amp;gt;$14,000.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “AI subscriptions are much more generous than API-pricing intuition suggests” + what that means for lab business models.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Retrieval note:&lt;&#x2F;strong&gt; extracted via FXTwitter API; captured thread opener + linked 2&#x2F;4 post, and read the attached comparison image separately.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>plannotator&#x2F;effective-html</title>
          <pubDate>Fri, 12 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-12-plannotator-effective-html/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-12-plannotator-effective-html/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-12-plannotator-effective-html/">&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; the repo packages focused agent skills for producing self-contained, visually strong HTML artifacts, especially diagrams and plan pages, plus an optional Plannotator renderer&#x2F;annotator. The post points to a demo video showing the diff&#x2F;code viewer behavior.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “HTML as agent output surface” &#x2F; better human-review loops for plans and diagrams.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Retrieval note:&lt;&#x2F;strong&gt; extracted via FXTwitter API; followed the linked GitHub repo page for the core description.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>agent experience</title>
          <pubDate>Thu, 11 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-11-agent-experience/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-11-agent-experience/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-11-agent-experience/">&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; argues DX thinking should extend to agents; optimize the layer between model and codebase via minimal&#x2F;tested context, deterministic environments, proof-heavy verification, structural safety, governance&#x2F;model routing, clean codebase interfaces, and shared preview&#x2F;review loops.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “AX as the new DX” + practical checklist for repo&#x2F;runtime&#x2F;review design.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Retrieval note:&lt;&#x2F;strong&gt; extracted via FXTwitter API; followed linked Builder article for full gist.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Lines of Code Got a Better Publicist</title>
          <pubDate>Thu, 11 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-11-lines-of-code-got-a-better-publicist/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-11-lines-of-code-got-a-better-publicist/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-11-lines-of-code-got-a-better-publicist/">&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; argues current AI-engineering rhetoric has regressed from measuring outcomes to measuring volume; “% of code written by AI” is just lines-of-code worship in new clothing, and should not be confused with delivery speed, quality, reliability, or customer value.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; pair with the Narayanan piece, anti-AI-washing on layoffs plus anti-vanity-metrics on productivity claims.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Retrieval note:&lt;&#x2F;strong&gt; extracted via FXTwitter API; followed linked essay for full gist.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Narayanan pointing to a Normal Tech essay on why AI hasn’t replaced software engineers</title>
          <pubDate>Thu, 11 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-11-narayanan-pointing-to-a-normal-tech-essay-on-why-ai-hasn-t-replaced-software-engineers/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-11-narayanan-pointing-to-a-normal-tech-essay-on-why-ai-hasn-t-replaced-software-engineers/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-11-narayanan-pointing-to-a-normal-tech-essay-on-why-ai-hasn-t-replaced-software-engineers/">&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; argues the “AI is replacing software engineers” story is mostly AI-washed layoffs rather than evidence of capability-driven displacement; software work is a decide-execute-deliver sandwich, and AI mainly compresses the execute middle while decision-making, accountability, and deep contextual understanding remain stubbornly human bottlenecks.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “AI writes more code, but that’s not the same as replacing engineers” + sandwich model &#x2F; anti-AI-washing thesis.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Retrieval note:&lt;&#x2F;strong&gt; extracted via FXTwitter API; followed linked Normal Tech essay for fuller argument (article fetch truncated near the end, but core thesis and evidence were captured).&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Code as Agent Harness</title>
          <pubDate>Wed, 10 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-10-code-as-agent-harness/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-10-code-as-agent-harness/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-10-code-as-agent-harness/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; How To AI thread summarizing the Stanford + Meta “Code as Agent Harness” paper.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; the core claim is that reliable agents should externalize reasoning into executable code instead of relying on free-form natural-language chain-of-thought. In this framing, code becomes the agent harness: scripts hold state, tests&#x2F;verifiers provide feedback, execution logs become memory, and the environment constrains behavior through real runtime errors rather than vague self-talk.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “the important unit of agent capability is the harness, not the prompt” or “code is becoming the runtime substrate for agent reasoning.”&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;&#x2F;strong&gt; extracted via FXTwitter note-tweet payload; saved as a secondary summary&#x2F;interpretation of the paper rather than a direct read of the paper itself.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Deedy post listing standout Claude Fable 5 demos and benchmark anecdotes</title>
          <pubDate>Wed, 10 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-10-deedy-post-listing-standout-claude-fable-5-demos-and-benchmark-anecdotes/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-10-deedy-post-listing-standout-claude-fable-5-demos-and-benchmark-anecdotes/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-10-deedy-post-listing-standout-claude-fable-5-demos-and-benchmark-anecdotes/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Deedy post listing standout Claude Fable 5 demos and benchmark anecdotes.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; a high-signal hype&#x2F;market snapshot: claims Fable 5 is showing startling capability across large-scale code migration, graphics generation, gameplay, and optimization tasks, while landing near GPT 5.5 pricing. The subtext is that frontier model capability may be moving faster than many software orgs are prepared for.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “capability shock is becoming a product-management problem” or “the frontier discourse is shifting from whether to how fast.”&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;&#x2F;strong&gt; extracted tweet via FXTwitter; no linked source bundle in the post itself, so this is saved as a claims summary rather than a verified deep read.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Designing loops with Fable 5</title>
          <pubDate>Wed, 10 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-10-designing-loops-with-fable-5/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-10-designing-loops-with-fable-5/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-10-designing-loops-with-fable-5/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; dosco sharing Lance Martin’s “Designing loops with Fable 5”.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; argues stronger agent performance comes from loop design, not just model quality: use explicit goals&#x2F;rubrics for self-correction, separate verifier sub-agents instead of self-critique, and durable memory across sessions. In Lance’s examples, Fable 5 outperformed earlier models by making larger structural bets and benefiting from independent grading plus memory.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “better agents need better loops, not just better models” or “independent verification beats self-critique.”&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;&#x2F;strong&gt; extracted via FXTwitter quote&#x2F;article payload; content was partially truncated near the end, but core sections on self-correction loops, verifier sub-agents, and memory were captured.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Eli Bendersky on starting new projects with LLM agents, based on building a new Go project from scratch</title>
          <pubDate>Wed, 10 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-10-eli-bendersky-on-starting-new-projects-with-llm-agents-based-on-building-a-new-go-project-from-scra/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-10-eli-bendersky-on-starting-new-projects-with-llm-agents-based-on-building-a-new-go-project-from-scra/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-10-eli-bendersky-on-starting-new-projects-with-llm-agents-based-on-building-a-new-go-project-from-scra/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Eli Bendersky on starting new projects with LLM agents, based on building a new Go project from scratch.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; argues agent-heavy development works best when humans keep tight control over design, review, and commit boundaries: start with repo-committed design notes, keep CLs small and reviewable, use strong external tests, and avoid vibe-coding for projects you intend to maintain. He also makes the case that Go is especially agent-friendly because human time shifts from writing to reading.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “agent coding turns programming into a reading-heavy discipline” or “small CLs and strong tests are what make agent-built projects maintainable.”&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;&#x2F;strong&gt; fetched article directly and extracted successfully.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Gaslighting Openness</title>
          <pubDate>Wed, 10 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-10-gaslighting-openness/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-10-gaslighting-openness/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-10-gaslighting-openness/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Armin Ronacher sharing his post “Gaslighting Openness” on the EU&#x2F;Apple fight and concerns related to Mythos and Fable.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; the post appears to be a broader argument about openness, control, and safety narratives, with specific worries tied to newer AI&#x2F;product directions like Mythos and Fable.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “control is being rebranded as safety” or “open ecosystems are being politically and commercially squeezed.”&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;&#x2F;strong&gt; extracted via FXTwitter card metadata; the actual substance lives in the linked essay: https:&#x2F;&#x2F;lucumr.pocoo.org&#x2F;2026&#x2F;6&#x2F;10&#x2F;gaslighting&#x2F;&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Quick,</title>
          <pubDate>Wed, 10 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-10-quick-2/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-10-quick-2/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-10-quick-2/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Daniel Beauchamp teaser thread about “Quick,” an internal Shopify zero-config API layer for storage, data saving, AI, websockets, and related app primitives.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; the hook is that instead of focusing only on AI-generated frontend code, they gave sites a simple built-in backend&#x2F;services layer and found it changed how they work. Claimed footprint: one VM costing about $200&#x2F;month.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “the missing layer in AI app building may be zero-config app infra, not just codegen.”&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;&#x2F;strong&gt; extracted via FXTwitter; this is only the opening post, so the real substance is likely in the rest of the thread.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Quick,</title>
          <pubDate>Wed, 10 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-10-quick/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-10-quick/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-10-quick/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Daniel Beauchamp teaser thread about “Quick,” an internal Shopify zero-config API layer for storage, data saving, AI, websockets, and related app primitives.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; the hook is that instead of focusing only on AI-generated frontend code, they gave sites a simple built-in backend&#x2F;services layer and found it changed how they work. Claimed footprint: one VM costing about $200&#x2F;month.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “the missing layer in AI app building may be zero-config app infra, not just codegen.”&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;&#x2F;strong&gt; extracted via FXTwitter; this is only the opening post, so the real substance is likely in the rest of the thread.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Simon Willison linking to his guide on agentic engineering patterns</title>
          <pubDate>Wed, 10 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-10-simon-willison-linking-to-his-guide-on-agentic-engineering-patterns/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-10-simon-willison-linking-to-his-guide-on-agentic-engineering-patterns/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-10-simon-willison-linking-to-his-guide-on-agentic-engineering-patterns/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Simon Willison linking to his guide on agentic engineering patterns.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; this is essentially a pointer to a living guide rather than a standalone tweet idea; likely high-signal if you want a practical synthesis of recurring agent design patterns from someone tracking the space closely.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “agent engineering is consolidating into recognizable patterns” or “the field is moving from demos to reusable design playbooks.”&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;&#x2F;strong&gt; extracted via FXTwitter; actual content is in the guide: https:&#x2F;&#x2F;simonwillison.net&#x2F;guides&#x2F;agentic-engineering-patterns&#x2F;&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>skepticism: strong opinion piece, not data-heavy; the claim that generics haven’t improved productivity is...</title>
          <pubDate>Wed, 10 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-10-skepticism-strong-opinion-piece-not-data-heavy-the-claim-that-generics-haven-t-improved-productivit/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-10-skepticism-strong-opinion-piece-not-data-heavy-the-claim-that-generics-haven-t-improved-productivit/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-10-skepticism-strong-opinion-piece-not-data-heavy-the-claim-that-generics-haven-t-improved-productivit/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; skepticism: strong opinion piece, not data-heavy; the claim that generics haven’t improved productivity is asserted more than demonstrated.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; his case is that Go’s value is simplicity&#x2F;readability&#x2F;maintainability, and newer features like generics and range-over-functions (iterators) erode that by increasing implicit behavior and language complexity. He argues generics have seen limited practical need while adding compiler&#x2F;type-system complexity, and that iterators introduce another iteration style plus hidden control-flow transformations that make code harder to read and debug. His broader recommendation is to stop adding complexity-increasing language features and invest instead in performance work and small quality-of-life improvements.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “is Go trading away simplicity for feature creep?” or “the real Go split may be readability-first vs expressiveness-first.”&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;&#x2F;strong&gt; direct article read via browser&#x2F;source fallback after standard fetch failed.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>skepticism: the thread oversold it a bit: the paper is a broad survey&#x2F;position piece, not a clean proof th...</title>
          <pubDate>Wed, 10 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-10-skepticism-the-thread-oversold-it-a-bit-the-paper-is-a-broad-survey-position-piece-not-a-clean-proo/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-10-skepticism-the-thread-oversold-it-a-bit-the-paper-is-a-broad-survey-position-piece-not-a-clean-proo/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-10-skepticism-the-thread-oversold-it-a-bit-the-paper-is-a-broad-survey-position-piece-not-a-clean-proo/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; skepticism: the thread oversold it a bit, the paper is a broad survey&#x2F;position piece, not a clean proof that one architecture flips everything.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; this is mostly a taxonomy and research agenda, not a new experimental result. The paper’s useful move is to separate three layers: code as interface (reasoning, acting, environment modeling), code-enabled harness mechanisms (planning, memory, tool use, plan-execute-verify control, harness optimization), and code as shared substrate for multi-agent coordination. The strongest practical point is that agent reliability lives in the runtime around the model, execution, verification, permissions, state, memory, and shared artifacts, more than in prompt wording alone.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “the agent stack is becoming systems engineering” or “the real unit of progress is the harness, not the prompt.”&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;&#x2F;strong&gt; read via arXiv abstract + HTML version; enough to capture structure, core claims, and open problems even though PDF text extraction wasn’t available locally.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>agent slop</title>
          <pubDate>Tue, 09 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-09-agent-slop/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-09-agent-slop/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-09-agent-slop/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Langfuse post&#x2F;article on automating the AI engineering loop without producing “agent slop”.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; argues the whole AI engineering loop can now technically be automated, instrumentation, monitoring, dataset building, testing, deployment, but full automation is a trap when human judgment is the product. Keep humans close to trace review, target definition, and quality-bar decisions.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “automate the loop, but not your taste” &#x2F; “agent slop is what happens when evals become the whole target.”&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;&#x2F;strong&gt; extracted via FXTwitter article payload; fetch was truncated but core argument and key terms were captured.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Decline of Search Engines is an Opportunity</title>
          <pubDate>Tue, 09 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-09-decline-of-search-engines-is-an-opportunity/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-09-decline-of-search-engines-is-an-opportunity/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-09-decline-of-search-engines-is-an-opportunity/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Lewis Campbell post linking to “The Decline of Search Engines is an Opportunity”.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; argues worsening search quality should push people back toward the old web habit of maintaining personal links pages; discovery by human-curated hyperlinks is framed as a healthier alternative to SEO sludge and LLM-mediated search summaries.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “search decay revives the links page” is a clean thesis with nice historical texture.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;&#x2F;strong&gt; extracted tweet via FXTwitter and fetched linked blog post successfully.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Dynamo and the Computer</title>
          <pubDate>Tue, 09 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-09-dynamo-and-the-computer/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-09-dynamo-and-the-computer/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-09-dynamo-and-the-computer/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Zara Zhang post using Paul David’s “The Dynamo and the Computer” as an analogy for AI adoption.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; argues AI gains won’t come from simply inserting models into existing workflows; like electrification, the real productivity jump comes only after redesigning the organization and flow of work around the new technology.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “AI is still in the faster steam engine phase” is a strong line for transformation skepticism.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;&#x2F;strong&gt; extracted tweet via FXTwitter; referenced paper link appears to be in replies&#x2F;comments and was not followed here.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Loop Engineering</title>
          <pubDate>Tue, 09 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-09-loop-engineering/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-09-loop-engineering/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-09-loop-engineering/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Addy Osmani post&#x2F;article, “Loop Engineering.”&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; argues the next layer above prompt engineering is designing autonomous agent loops; highlights 5 building blocks: scheduled automations&#x2F;triage, worktrees for parallel isolation, skills for project knowledge, tool connectors&#x2F;plugins, and sub-agents, plus durable external memory.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “prompting is becoming loop design” + compare Codex&#x2F;Claude primitives to the same orchestration pattern.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;&#x2F;strong&gt; extracted via FXTwitter API article payload; content partially truncated in fetch but core thesis and list were captured.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Modern Engineering Values</title>
          <pubDate>Tue, 09 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-09-modern-engineering-values/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-09-modern-engineering-values/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-09-modern-engineering-values/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Richard Seroter sharing Christoph Nakazawa’s “Modern Engineering Values”.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; argues coding agents have shifted engineering bottlenecks from writing code to ownership, review, taste, guardrails, repo-local context, and stack control. Nakazawa’s claim is that strong engineers with sharp domain context now get massively amplified, while weak context just creates more noise.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “engineering values didn’t disappear; they got more expensive and more leveraged” or “agents amplify ownership, taste, and guardrails.”&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;&#x2F;strong&gt; extracted tweet via FXTwitter and fetched linked post; fetch truncated near the end but captured workflow details and main values list.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Our fears about AI are really fears about capitalism</title>
          <pubDate>Tue, 09 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-09-our-fears-about-ai-are-really-fears-about-capitalism/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-09-our-fears-about-ai-are-really-fears-about-capitalism/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-09-our-fears-about-ai-are-really-fears-about-capitalism/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; LTSE post linking Eric Ries’s Fast Company essay, “Our fears about AI are really fears about capitalism”.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; argues many AI anxieties are really about institutions and incentive systems optimizing for the wrong outcomes; the key question is not just what machines optimize for, but what organizations optimize for.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “AI fear is often misdirected systems fear” or “alignment problems are organizational too, not just model-level.”&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;&#x2F;strong&gt; extracted tweet via FXTwitter; direct article fetch was blocked by Fast Company anti-bot checks, so gist is based on the linked title&#x2F;description and quoted line in the post.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Shriram Krishnamurthi memo on rebooting a programming languages course for the agentic coding era</title>
          <pubDate>Tue, 09 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-09-shriram-krishnamurthi-memo-on-rebooting-a-programming-languages-course-for-the-agentic-coding-era/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-09-shriram-krishnamurthi-memo-on-rebooting-a-programming-languages-course-for-the-agentic-coding-era/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-09-shriram-krishnamurthi-memo-on-rebooting-a-programming-languages-course-for-the-agentic-coding-era/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Shriram Krishnamurthi memo on rebooting a programming languages course for the agentic coding era.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; argues PL should be reframed around constraining AI-generated implementations and providing guarantees; distinguishes PL from SE&#x2F;FM, then proposes teaching along two axes: language confinement and custom program properties.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “AI makes PL more about guarantees than syntax” + course design as a forecast of curriculum shifts.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;&#x2F;strong&gt; extracted tweet via FXTwitter, then fetched linked public Google Doc; captured substantive sections including motivation and course structure.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>What is an agent?</title>
          <pubDate>Tue, 09 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-09-what-is-an-agent/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-09-what-is-an-agent/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-09-what-is-an-agent/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Karthik S sharing Hadley Wickham’s “What is an agent?” explainer.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; very clear mental model: an agent is an LLM inside a harness that can call tools repeatedly in a loop; the harness mediates tool calls&#x2F;results and turns a stateless request&#x2F;response model into iterative action.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “agent = looped tool use inside a harness” is a concise definitional anchor for broader agent discussions.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;&#x2F;strong&gt; extracted tweet via FXTwitter and fetched linked Substack article successfully.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools</title>
          <pubDate>Tue, 09 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-09-writing-code-vs-shipping-code-productivity-effects-across-generations-of-ai-coding-tools/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-09-writing-code-vs-shipping-code-productivity-effects-across-generations-of-ai-coding-tools/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-09-writing-code-vs-shipping-code-productivity-effects-across-generations-of-ai-coding-tools/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Murat Demirbas on “Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools”.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; uses a new MIT&#x2F;Wharton paper plus an Amdahl’s-law framing to argue that AI massively speeds up code generation but much less meaningfully speeds shipped software, because the bottleneck is the non-parallelizable human layer: task definition, coordination, review, and release.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “AI accelerates writing code more than shipping code” or “Amdahl’s Law is eating AI coding productivity claims.”&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;&#x2F;strong&gt; extracted tweet via FXTwitter and fetched linked blog post successfully.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>agent-ready</title>
          <pubDate>Mon, 08 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-08-agent-ready/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-08-agent-ready/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-08-agent-ready/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; an X post arguing that “agent-ready” websites need typed tools rather than just scrapable HTML.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; the core claim is that real agent usability comes from explicit actions like search, checkout, and inventory exposed as structured tools, not merely from making pages easy to scrape.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “agent-ready ≠ scrapable” is a strong hook for the coming split between human web UX and agent-facing capability layers.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;&#x2F;strong&gt; extracted via FXTwitter API; linked demo&#x2F;domain mentioned is &lt;code&gt;webmcp.cool&lt;&#x2F;code&gt;.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Armin Ronacher explaining Pi’s new per-project approval prompt and the security model behind it</title>
          <pubDate>Mon, 08 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-08-armin-ronacher-explaining-pi-s-new-per-project-approval-prompt-and-the-security-model-behind-it/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-08-armin-ronacher-explaining-pi-s-new-per-project-approval-prompt-and-the-security-model-behind-it/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-08-armin-ronacher-explaining-pi-s-new-per-project-approval-prompt-and-the-security-model-behind-it/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Armin Ronacher explaining Pi’s new per-project approval prompt and the security model behind it.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; the key argument is that &lt;code&gt;AGENTS.md&lt;&#x2F;code&gt; gets injected into the system prompt, so untrusted repo-level instructions can directly influence agent behavior in ways a README usually won’t; Pi added one-time trust prompts to reduce silent execution risk on untrusted repos.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; repo-local agent instructions are becoming both a productivity primitive and a new software supply-chain&#x2F;security surface.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;&#x2F;strong&gt; extracted via FXTwitter API from the tweet’s article body; points to GitHub issue &lt;code&gt;earendil-works&#x2F;pi#5514&lt;&#x2F;code&gt; for feedback.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>blog essay arguing AI disruption is structurally more threatening to software than many other fields becaus...</title>
          <pubDate>Mon, 08 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-08-blog-essay-arguing-ai-disruption-is-structurally-more-threatening-to-software-than-many-other-field/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-08-blog-essay-arguing-ai-disruption-is-structurally-more-threatening-to-software-than-many-other-field/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-08-blog-essay-arguing-ai-disruption-is-structurally-more-threatening-to-software-than-many-other-field/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; a blog essay arguing AI disruption is structurally more threatening to software than many other fields because code is verifiable, open source created a huge training corpus, and AI labs can dogfood coding tools on themselves.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; the author expects a race to the bottom in software pricing, wage compression, permanent erosion of the talent pipeline, higher output expectations for remaining engineers, and most upside captured by owners&#x2F;model providers.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; software may be the cleanest early target for AI because it has both an oracle and the richest public corpus.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;&#x2F;strong&gt; fetched directly from the article; clearly opinionated, but useful as a framing piece.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>just use loops</title>
          <pubDate>Mon, 08 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-08-just-use-loops/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-08-just-use-loops/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-08-just-use-loops/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Gergely Orosz pushing back on the blanket “just use loops” advice for coding agents.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; his claim is that autonomous loop-heavy agent workflows mainly make sense for the relatively small set of people with effectively unlimited token budgets and enough friction with prompt-driven workflows to justify the spend.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; the real constraint on agent autonomy may be economics, not just capability.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;&#x2F;strong&gt; extracted via FXTwitter API from the tweet text only.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Modern Engineering Values</title>
          <pubDate>Mon, 08 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-08-modern-engineering-values/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-08-modern-engineering-values/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-08-modern-engineering-values/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Christoph Nakazawa re-linking his essay &lt;code&gt;Modern Engineering Values&lt;&#x2F;code&gt; in reply form.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; argues that coding is no longer the main bottleneck; the winning engineering values now are strong ownership, taste, strict guardrails, fast feedback loops, and moving real context into the repo where agents can use it.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; engineering values are shifting from raw implementation throughput toward judgment, verification, and context placement.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;&#x2F;strong&gt; extracted via FXTwitter API and linked article fetch; this overlaps with earlier saves on the same essay but is still a useful direct pointer.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>promoting an 85-minute MIT lecture on Git internals &#x2F; data model</title>
          <pubDate>Mon, 08 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-08-promoting-an-85-minute-mit-lecture-on-git-internals-data-model/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-08-promoting-an-85-minute-mit-lecture-on-git-internals-data-model/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-08-promoting-an-85-minute-mit-lecture-on-git-internals-data-model/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; an X post promoting an 85-minute MIT lecture on Git internals &#x2F; data model.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; the pitch is that most developers memorize Git commands without understanding commits, trees, refs, and the graph underneath; learning the model makes debugging history and merge&#x2F;rebase failures much less magical.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “Git literacy as leverage”, understanding the object graph matters more when agents are branching&#x2F;rewriting history at speed.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;&#x2F;strong&gt; extracted via FXTwitter API; saved from the post text only, lecture content itself not yet reviewed.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Sebastian Raschka summarizing a paper on whether repository-level context files like AGENTS.md actually hel...</title>
          <pubDate>Mon, 08 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-08-sebastian-raschka-summarizing-a-paper-on-whether-repository-level-context-files-like-agents-md-actu/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-08-sebastian-raschka-summarizing-a-paper-on-whether-repository-level-context-files-like-agents-md-actu/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-08-sebastian-raschka-summarizing-a-paper-on-whether-repository-level-context-files-like-agents-md-actu/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Sebastian Raschka summarizing a paper on whether repository-level context files like &lt;code&gt;AGENTS.md&lt;&#x2F;code&gt; actually help coding agents.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; in the reported benchmarks, LLM-generated context files were neutral-to-slightly-worse versus no context file, developer-written ones were better than LLM-written ones, and surprisingly the no-context condition was often cheaper&#x2F;more efficient.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; more agent context is not automatically better, extra instructions can increase exploration cost without improving task success.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;&#x2F;strong&gt; extracted from the FXTwitter API &lt;code&gt;article&lt;&#x2F;code&gt; body; links to arXiv paper &lt;code&gt;2602.11988&lt;&#x2F;code&gt;.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>vim_royale</title>
          <pubDate>Mon, 08 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-08-vim-royale/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-08-vim-royale/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-08-vim-royale/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Jitesh boosting &lt;code&gt;vim_royale&lt;&#x2F;code&gt;, a Peerlist project for realtime multiplayer Vim battles.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; lightweight launch&#x2F;amplification post rather than a deep technical thread; the linked card describes the project very tersely as “Realtime multiplayer Vim battles.”&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; playful developer-product idea &#x2F; “tools culture as game mechanic.”&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>antirez reacting sharply to Anthropic’s Opus 4.8 as a product&#x2F;management failure rather than a raw model-ca...</title>
          <pubDate>Thu, 04 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-04-antirez-reacting-sharply-to-anthropic-s-opus-4-8-as-a-product-management-failure-rather-than-a-raw/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-04-antirez-reacting-sharply-to-anthropic-s-opus-4-8-as-a-product-management-failure-rather-than-a-raw/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-04-antirez-reacting-sharply-to-anthropic-s-opus-4-8-as-a-product-management-failure-rather-than-a-raw/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; antirez reacting sharply to Anthropic’s Opus 4.8 as a product&#x2F;management failure rather than a raw model-capability issue.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; the claim is that shipping a bad model experience is more revealing about product judgment and internal decision-making than about frontier-model feasibility; if quality was not there, not shipping would have been the better move.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; frontier AI competition may increasingly hinge on release quality and organizational judgment, not just the ceiling of the underlying model.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;&#x2F;strong&gt; extracted via FXTwitter API; standalone opinion tweet, no linked article.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Building Software Is Learning</title>
          <pubDate>Thu, 04 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-04-building-software-is-learning/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-04-building-software-is-learning/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-04-building-software-is-learning/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Thorsten Ball sharing an internal Amp note turned public essay: “Building Software Is Learning.”&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; the core claim is that new-product software work is mostly iterative discovery, so the real optimization target is reducing time-to-feedback, via prototypes, partial specs, fake demos, smaller slices, README examples, CI, and quick exposure to reality.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; if agents compress implementation time, then the winning org habit is compressing learning cycles rather than just shipping more code.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;&#x2F;strong&gt; extracted via FXTwitter API and linked Substack post.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Modern Engineering Values,</title>
          <pubDate>Thu, 04 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-04-modern-engineering-values/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-04-modern-engineering-values/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-04-modern-engineering-values/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Christoph Nakazawa sharing his essay “Modern Engineering Values,” framed around Codex as a step-change in developer velocity.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; the piece argues coding is no longer the main bottleneck; the durable values now are strong ownership, taste, strict guardrails with fast feedback loops, repo-local context, stack ownership, and preserving option value while agents do more implementation work.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; AI doesn’t replace engineering values, it increases the premium on ownership, taste, fast verification, and keeping context where agents can actually use it.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;&#x2F;strong&gt; extracted via FXTwitter API and linked article; article read partially via web fetch due to truncation, but the main framework sections were captured.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Solo Climb</title>
          <pubDate>Thu, 04 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-04-solo-climb/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-04-solo-climb/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-04-solo-climb/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Ajey Gore linking his essay “The Solo Climb.”&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; the argument is that AI-enabled solo builders and tiny teams only work when they first build a genuinely load-bearing “harness”, trusted tests, evals, specs, and hard gates that can answer “is this safe enough to ship?” without relying on redundant humans.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “100x teams” are mostly a harness story, AI leverage scales only when trust, eval, and rollback systems become the new team structure.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;&#x2F;strong&gt; extracted via FXTwitter API and linked article; article read partially via web fetch due to truncation, but core thesis was clear.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Why AI Agents Fail in Production</title>
          <pubDate>Thu, 04 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-04-why-ai-agents-fail-in-production/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-04-why-ai-agents-fail-in-production/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-04-why-ai-agents-fail-in-production/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Bilgin Ibryam pointing to Jani Janakiram’s Diagrid essay “Why AI Agents Fail in Production.”&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; the core claim is that agent projects fail less because models are weak and more because teams ship behavior without the production substrate underneath it, especially durability, security&#x2F;identity, cost controls, and observability.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; the production gap for agents looks a lot like the early microservices gap, the winning layer may be the platform that makes agent workflows restartable, attributable, observable, and cost-bounded.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;&#x2F;strong&gt; extracted via FXTwitter API; direct web fetch failed due to site rendering, so the article was recovered via browser snapshot.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Armin Ronacher pointing to Andrew Tridgell’s defense of using AI tools while maintaining rsync under a floo...</title>
          <pubDate>Wed, 03 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-03-armin-ronacher-pointing-to-andrew-tridgell-s-defense-of-using-ai-tools-while-maintaining-rsync-unde/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-03-armin-ronacher-pointing-to-andrew-tridgell-s-defense-of-using-ai-tools-while-maintaining-rsync-unde/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-03-armin-ronacher-pointing-to-andrew-tridgell-s-defense-of-using-ai-tools-while-maintaining-rsync-unde/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Armin Ronacher pointing to Andrew Tridgell’s defense of using AI tools while maintaining rsync under a flood of security reports.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; Tridgell’s main point is not “vibe code and pray” but “use AI for grunt work under strong human design&#x2F;review&#x2F;validation,” especially to harden tests, coverage, CI, and security defenses fast enough to keep up with incoming reports.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; open source maintainers are reaching for agents not as ideology but as capacity amplification under adversarial workload.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;&#x2F;strong&gt; extracted via FXTwitter API and linked Medium post.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Mario Zechner recommending Thariq’s article on dynamic workflows in Claude Code</title>
          <pubDate>Wed, 03 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-03-mario-zechner-recommending-thariq-s-article-on-dynamic-workflows-in-claude-code/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-03-mario-zechner-recommending-thariq-s-article-on-dynamic-workflows-in-claude-code/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-03-mario-zechner-recommending-thariq-s-article-on-dynamic-workflows-in-claude-code/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Mario Zechner recommending Thariq’s article on dynamic workflows in Claude Code.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; Mario’s takeaway is that durable dynamic workflows are the interesting part; he inspected the implementation, found a few footguns, but still thinks the design is smart. The quoted article frames workflows as task-specific harnesses Claude can generate on the fly for work like research, security analysis, agent teams, and code review.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “durable dynamic workflows” &#x2F; generated harnesses as the control plane for agent systems.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;&#x2F;strong&gt; extracted via FXTwitter API; article body only partially available from quoted-tweet article metadata.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Modern Engineering Values</title>
          <pubDate>Wed, 03 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-03-modern-engineering-values/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-03-modern-engineering-values/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-03-modern-engineering-values/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Christoph Nakazawa’s post on “Modern Engineering Values” and his current LLM-heavy workflow.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; core claims are that coding is no longer the bottleneck, strong guardrails plus tight feedback loops matter more than ever, repo-local context becomes the real operating manual for agents, and small teams with strong ownership&#x2F;taste will outperform larger coordination-heavy orgs.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; engineering values are being redefined around ownership, taste, guardrails, and context placement rather than raw coding throughput.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;&#x2F;strong&gt; extracted via FXTwitter API and linked post; article body was truncated after the management section but the main values sections were captured.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Simon Willison pointing to Bloomberg on Uber capping agentic coding-tool spend at $1,500&#x2F;month per employee...</title>
          <pubDate>Wed, 03 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-03-simon-willison-pointing-to-bloomberg-on-uber-capping-agentic-coding-tool-spend-at-1-500-month-per-e/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-03-simon-willison-pointing-to-bloomberg-on-uber-capping-agentic-coding-tool-spend-at-1-500-month-per-e/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-03-simon-willison-pointing-to-bloomberg-on-uber-capping-agentic-coding-tool-spend-at-1-500-month-per-e/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Simon Willison pointing to Bloomberg on Uber capping agentic coding-tool spend at $1,500&#x2F;month per employee per tool.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; Simon’s read is that the cap is a rational response to runaway token spend and also a useful revealed-preference signal: Uber appears willing to tolerate tooling costs on the order of tens of thousands of dollars per engineer per year if the productivity gain holds.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; coding-agent PMF is now visible through finance policy; spend caps as a clearer signal than hype.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;&#x2F;strong&gt; extracted via FXTwitter API plus Simon’s linked post for added context.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Han Xiao on Dataroom, a local-first deep research harness</title>
          <pubDate>Tue, 02 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-02-han-xiao-on-dataroom-a-local-first-deep-research-harness/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-02-han-xiao-on-dataroom-a-local-first-deep-research-harness/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-02-han-xiao-on-dataroom-a-local-first-deep-research-harness/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Han Xiao on Dataroom, a local-first deep research harness.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; argues deep research should be a cheap, long-running first step for long-horizon tasks; Dataroom uses a small local model on your own GPU, keeps gathering until the package is genuinely comprehensive, and outputs a zip instead of burning frontier-model budget.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “local-first deep research” &#x2F; small models + harness design beating expensive frontier calls for the reconnaissance phase.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;&#x2F;strong&gt; extracted via FXTwitter API.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Sid&#x27;s writeup on a recently patched Instagram&#x2F;Meta account takeover flow</title>
          <pubDate>Tue, 02 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-06-02-sid-s-writeup-on-a-recently-patched-instagram-meta-account-takeover-flow/</link>
          <guid>https://reading-list.oddship.net/notes/2026-06-02-sid-s-writeup-on-a-recently-patched-instagram-meta-account-takeover-flow/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-06-02-sid-s-writeup-on-a-recently-patched-instagram-meta-account-takeover-flow/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Sid&#x27;s writeup on a recently patched Instagram&#x2F;Meta account takeover flow.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; attacker allegedly only needed a target username, region-matching IP, and Meta support AI to redirect recovery codes to attacker-controlled email; video selfie checks were reportedly weak enough to bypass with AI-animated public photos.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “support AI as auth bypass” &#x2F; security lesson on high-privilege recovery flows needing stricter invariants than normal login.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;&#x2F;strong&gt; fetched article body successfully via web_fetch.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>solution might be cancelling my AI subscription</title>
          <pubDate>Sun, 31 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-31-solution-might-be-cancelling-my-ai-subscription/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-31-solution-might-be-cancelling-my-ai-subscription/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-31-solution-might-be-cancelling-my-ai-subscription/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;Extracted main post via &lt;code&gt;api.fxtwitter.com&lt;&#x2F;code&gt; fallback, then read linked post directly: https:&#x2F;&#x2F;thoughts.hmmz.org&#x2F;2026-05-31.html&lt;&#x2F;li&gt;
&lt;li&gt;Mario Zechner recommends David&#x27;s post &lt;code&gt;the solution might be cancelling my AI subscription&lt;&#x2F;code&gt;.&lt;&#x2F;li&gt;
&lt;li&gt;Gist: a sharp anti-friction argument against current AI-tool usage patterns, cheap output and minimal resistance can explode side projects, context switching, and pseudo-productivity while degrading attention and commitment.&lt;&#x2F;li&gt;
&lt;li&gt;Why it matters: good counterweight to &quot;more agent throughput = better work&quot; narratives; frames AI as an attention-management and meaning-allocation problem, not just a capability story.&lt;&#x2F;li&gt;
&lt;li&gt;Newsletter angle: friction, focus, and why AI tooling may be optimizing for the wrong thing.&lt;&#x2F;li&gt;
&lt;li&gt;Retrieval note: FXTwitter API for post text; linked article fetched directly via &lt;code&gt;web_fetch&lt;&#x2F;code&gt;.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
      <item>
          <title>Guillaume Laforge post + MCP release-candidate blog link</title>
          <pubDate>Fri, 22 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-22-guillaume-laforge-post-mcp-release-candidate-blog-link/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-22-guillaume-laforge-post-mcp-release-candidate-blog-link/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-22-guillaume-laforge-post-mcp-release-candidate-blog-link/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Guillaume Laforge post + MCP release-candidate blog link&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; MCP 2026-07-28 RC is out; biggest revision so far with stateless HTTP-native core, first-class extensions (Apps, Tasks), stronger auth alignment, and a formal deprecation policy. Final spec slated for July 28.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; “MCP grows up operationally”, stateless transport + extension model + auth hardening as the path from prototype protocol to production infra.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>AI ate my role! What&#x27;s next?</title>
          <pubDate>Tue, 19 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-19-ai-ate-my-role-what-s-next/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-19-ai-ate-my-role-what-s-next/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-19-ai-ate-my-role-what-s-next/">&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; argues most roles split into translation work that collapses into agents and judgement work that grows; strongest claim is the &quot;100x engineer&quot; pattern of one senior plus directed agents.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; &quot;AI won&#x27;t eat jobs evenly, it compresses translation work and amplifies judgment owners&quot;.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;&#x2F;strong&gt; extracted via FXTwitter API + Ajey Gore article; article fetch was partial&#x2F;truncated but core thesis was clear.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>antirez on alternatives to the standard EDIT tool for LLM agents; links to a short blog note</title>
          <pubDate>Tue, 19 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-19-antirez-on-alternatives-to-the-standard-edit-tool-for-llm-agents-links-to-a-short-blog-note/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-19-antirez-on-alternatives-to-the-standard-edit-tool-for-llm-agents-links-to-a-short-blog-note/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-19-antirez-on-alternatives-to-the-standard-edit-tool-for-llm-agents-links-to-a-short-blog-note/">&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; proposes CAS-style edits using line-number + short checksum tags instead of resending old text verbatim, aiming to save tokens while still guarding against stale or hallucinated edits.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; &quot;a lighter-weight edit primitive for coding agents: line tags vs full old-text CAS&quot;.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;&#x2F;strong&gt; extracted via FXTwitter API + antirez.com post.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>building a cloud</title>
          <pubDate>Tue, 19 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-19-building-a-cloud/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-19-building-a-cloud/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-19-building-a-cloud/">&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; argues current cloud abstractions are the wrong shape, VM sizing tied to resources, remote block storage optimized for HDD-era assumptions, egress pricing distortions, and Kubernetes as lipstick over broken primitives.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; &quot;what an ex-Tailscale CTO would redesign about the cloud stack in the agent era&quot;.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;&#x2F;strong&gt; extracted via FXTwitter API + crawshaw.io article.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Geoffrey Huntley sharing his ai.engineer Singapore talk recording on YouTube</title>
          <pubDate>Tue, 19 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-19-geoffrey-huntley-sharing-his-ai-engineer-singapore-talk-recording-on-youtube/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-19-geoffrey-huntley-sharing-his-ai-engineer-singapore-talk-recording-on-youtube/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-19-geoffrey-huntley-sharing-his-ai-engineer-singapore-talk-recording-on-youtube/">&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; meta framing from the post is reflective rather than thesis-heavy, &quot;no-one knows where this goes&quot; and the invitation is to agree&#x2F;disagree but mostly reflect; linked video title is from ai.engineer Singapore Day 2.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; possible round-up item if the talk yields stronger quotable claims after a proper watch&#x2F;transcript pull.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;&#x2F;strong&gt; extracted via FXTwitter API; YouTube fetch only surfaced page metadata&#x2F;title, not a usable transcript.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Mario Zechner recommending antirez’s post on hash-line read&#x2F;edit tools for agents</title>
          <pubDate>Tue, 19 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-19-mario-zechner-recommending-antirez-s-post-on-hash-line-read-edit-tools-for-agents/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-19-mario-zechner-recommending-antirez-s-post-on-hash-line-read-edit-tools-for-agents/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-19-mario-zechner-recommending-antirez-s-post-on-hash-line-read-edit-tools-for-agents/">&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; mostly a pointer&#x2F;amplifier rather than a new thesis; reinforces interest around checksum-tagged line edit protocols for agent tooling.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; maybe bundle with the original antirez item as a small &quot;agent tooling design&quot; thread rather than a standalone item.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;&#x2F;strong&gt; extracted via FXTwitter API; quotes the previously logged antirez post and adds no new linked material.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Project Glasswing: what Mythos showed us</title>
          <pubDate>Tue, 19 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-19-project-glasswing-what-mythos-showed-us/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-19-project-glasswing-what-mythos-showed-us/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-19-project-glasswing-what-mythos-showed-us/">&lt;p&gt;&lt;strong&gt;What it is:&lt;&#x2F;strong&gt; Cloudflare on testing Anthropic Mythos against 50+ internal repos; links to &quot;Project Glasswing: what Mythos showed us&quot;.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Gist:&lt;&#x2F;strong&gt; key claim is that stronger offensive-security models change vuln research from bug spotting to exploit-chain construction and proof generation, but the real bottleneck becomes harness design, triage noise, and scoped parallel workflows rather than just faster patching.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Newsletter angle:&lt;&#x2F;strong&gt; &quot;offensive AI doesn&#x27;t just speed up vuln discovery, it forces a redesign of the architecture around triage, coverage, and exploit validation&quot;.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;&#x2F;strong&gt; extracted via FXTwitter API + Cloudflare blog; article fetch was partial&#x2F;truncated but the central thesis and main sections were clear.&lt;&#x2F;p&gt;
</description>
      </item>
      <item>
          <title>Ambitious OSS project pitching WiFi CSI as a privacy-preserving sensing stack: presence detection, breathin...</title>
          <pubDate>Wed, 13 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-13-ambitious-oss-project-pitching-wifi-csi-as-a-privacy-preserving-sensing-stack-presence-detection-br/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-13-ambitious-oss-project-pitching-wifi-csi-as-a-privacy-preserving-sensing-stack-presence-detection-br/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-13-ambitious-oss-project-pitching-wifi-csi-as-a-privacy-preserving-sensing-stack-presence-detection-br/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;Ambitious OSS project pitching WiFi CSI as a privacy-preserving sensing stack: presence detection, breathing&#x2F;heart-rate monitoring, activity recognition, rough pose estimation, and through-wall&#x2F;environment sensing using ESP32-S3 nodes.&lt;&#x2F;li&gt;
&lt;li&gt;Interesting angle is the packaging: not just a research demo, but a full “edge intelligence” story with cheap hardware, local processing, attestations, mesh sensing, demos, and a long README translating RF sensing into product language.&lt;&#x2F;li&gt;
&lt;li&gt;Newsletter angle: strong hook if framed as “camera-free spatial intelligence from commodity WiFi,” with some skepticism around the breadth of claims and the gap between demoability, accuracy, and production-grade robustness.&lt;&#x2F;li&gt;
&lt;li&gt;Retrieval note: extracted from GitHub README via web_fetch; README is long and partially truncated, but the core claims, hardware setup, and positioning were readable.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
      <item>
          <title>Andras Bacsai jokes that Coolify created a fake repo with fake bounties so agent&#x2F;bot-driven fake PR submiss...</title>
          <pubDate>Wed, 13 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-13-andras-bacsai-jokes-that-coolify-created-a-fake-repo-with-fake-bounties-so-agent-bot-driven-fake-pr/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-13-andras-bacsai-jokes-that-coolify-created-a-fake-repo-with-fake-bounties-so-agent-bot-driven-fake-pr/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-13-andras-bacsai-jokes-that-coolify-created-a-fake-repo-with-fake-bounties-so-agent-bot-driven-fake-pr/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;Andras Bacsai jokes that Coolify created a fake repo with fake bounties so agent&#x2F;bot-driven fake PR submissions would self-identify and could be banned from the main repo.&lt;&#x2F;li&gt;
&lt;li&gt;Useful as a sharp anecdote about the emerging spam&#x2F;credibility problem around bounty-chasing coding agents: once PR generation gets cheap, maintainers start building honeypots and authenticity filters.&lt;&#x2F;li&gt;
&lt;li&gt;Newsletter angle: strong, funny hook for a piece on anti-spam countermeasures in the age of agentic OSS contribution.&lt;&#x2F;li&gt;
&lt;li&gt;Retrieval note: extracted via api.fxtwitter.com; gist comes from the post text, without inspecting replies.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
      <item>
          <title>Course&#x2F;site on harness engineering for AI coding agents, synthesizing OpenAI + Anthropic guidance into lect...</title>
          <pubDate>Wed, 13 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-13-course-site-on-harness-engineering-for-ai-coding-agents-synthesizing-openai-anthropic-guidance-into/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-13-course-site-on-harness-engineering-for-ai-coding-agents-synthesizing-openai-anthropic-guidance-into/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-13-course-site-on-harness-engineering-for-ai-coding-agents-synthesizing-openai-anthropic-guidance-into/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;Course&#x2F;site on harness engineering for AI coding agents, synthesizing OpenAI + Anthropic guidance into lectures, projects, and ready-to-copy templates.&lt;&#x2F;li&gt;
&lt;li&gt;Core pitch: reliability comes less from a smarter model and more from a closed-loop system, explicit constraints, state management, verification, observability, and control.&lt;&#x2F;li&gt;
&lt;li&gt;Newsletter angle: a useful “meta” resource for the current wave of coding-agent practice, especially good if framing the shift from promptcraft to environment&#x2F;harness design.&lt;&#x2F;li&gt;
&lt;li&gt;Retrieval note: extracted cleanly via web_fetch from the landing page; this captures the overview, not the deeper lecture&#x2F;project content yet.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
      <item>
          <title>Jake’s launch post for sqlite3-parser-js: claims a pure-JS port of SQLite’s parser beats every other JS SQL...</title>
          <pubDate>Tue, 12 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-12-jake-s-launch-post-for-sqlite3-parser-js-claims-a-pure-js-port-of-sqlite-s-parser-beats-every-other/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-12-jake-s-launch-post-for-sqlite3-parser-js-claims-a-pure-js-port-of-sqlite-s-parser-beats-every-other/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-12-jake-s-launch-post-for-sqlite3-parser-js-claims-a-pure-js-port-of-sqlite-s-parser-beats-every-other/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;Jake’s launch post for sqlite3-parser-js: claims a pure-JS port of SQLite’s parser beats every other JS SQL parser he benchmarked, including wasm-based options.&lt;&#x2F;li&gt;
&lt;li&gt;Useful companion to the repo itself because the punchline is performance positioning: 2.5x over liteparser, 6x over sqlparser-ts, 10x over node-sql-parser, and much larger gaps vs older parsers.&lt;&#x2F;li&gt;
&lt;li&gt;Newsletter angle: strong “unexpected performance result” framing, pure JS beating wasm competitors for SQL parsing is a nice hook into why parser architecture and generated code shape matter.&lt;&#x2F;li&gt;
&lt;li&gt;Retrieval note: extracted via api.fxtwitter.com; pairs with the repo link above.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
      <item>
          <title>JS SQLite parser ported from SQLite’s own Lemon&#x2F;LALR grammar, aimed at being fast, lightweight, browser-fri...</title>
          <pubDate>Tue, 12 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-12-js-sqlite-parser-ported-from-sqlite-s-own-lemon-lalr-grammar-aimed-at-being-fast-lightweight-browse/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-12-js-sqlite-parser-ported-from-sqlite-s-own-lemon-lalr-grammar-aimed-at-being-fast-lightweight-browse/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-12-js-sqlite-parser-ported-from-sqlite-s-own-lemon-lalr-grammar-aimed-at-being-fast-lightweight-browse/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;JS SQLite parser ported from SQLite’s own Lemon&#x2F;LALR grammar, aimed at being fast, lightweight, browser-friendly, and more faithful than typical JS SQL parsers.&lt;&#x2F;li&gt;
&lt;li&gt;Notable angle: improved structured diagnostics and hints, plus AST traversal&#x2F;CLI tooling, which makes it more useful for editor tooling, linting, query analysis, or SQL-aware product features.&lt;&#x2F;li&gt;
&lt;li&gt;Newsletter angle: a good example of “serious infra-grade parsing” moving into pure TypeScript without wasm, with a tight value prop around correctness + developer ergonomics.&lt;&#x2F;li&gt;
&lt;li&gt;Retrieval note: extracted from GitHub README via web_fetch.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
      <item>
          <title>llm</title>
          <pubDate>Tue, 12 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-12-llm/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-12-llm/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-12-llm/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;Extracted via api.fxtwitter.com fallback, then read linked TIL directly: https:&#x2F;&#x2F;til.simonwillison.net&#x2F;llms&#x2F;llm-shebang&lt;&#x2F;li&gt;
&lt;li&gt;Simon Willison shows a neat pattern for using his &lt;code&gt;llm&lt;&#x2F;code&gt; CLI in a shebang line, turning plain-English files or YAML templates into executable scripts.&lt;&#x2F;li&gt;
&lt;li&gt;The more interesting part is not the toy prompt examples but the tool-enabled&#x2F;template-enabled scripts: parameterized prompts, embedded functions, and lightweight agentic shells around LLM&#x2F;tool workflows.&lt;&#x2F;li&gt;
&lt;li&gt;Newsletter angle: a crisp example of LLMs collapsing the boundary between prompt, script, and tiny executable tool surface.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
      <item>
          <title>translation layer</title>
          <pubDate>Tue, 12 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-12-translation-layer/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-12-translation-layer/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-12-translation-layer/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;Blog essay arguing AI compresses the org’s “translation layer” more than any single job title: spec→ticket→PR→release-note work gets cheap, while judgement around why&#x2F;what&#x2F;trust systems gets more valuable.&lt;&#x2F;li&gt;
&lt;li&gt;Strong claim: middle-management and coordination-heavy roles shrink unless they actively contribute to product definition, architecture, evals, or verification.&lt;&#x2F;li&gt;
&lt;li&gt;Newsletter angle: useful framing for how AI changes org shape, not “AI replaces engineers” but “AI eats translation work,” which shifts value toward taste, harnesses, and hands-on decision-makers.&lt;&#x2F;li&gt;
&lt;li&gt;Retrieval note: extracted cleanly via web_fetch; article content was partial near the ending due to truncation, but the main thesis and supporting sections were readable.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
      <item>
          <title>Mario Zechner recommends a post arguing that AI is good at shipping features but bad at preserving architec...</title>
          <pubDate>Mon, 11 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-11-mario-zechner-recommends-a-post-arguing-that-ai-is-good-at-shipping-features-but-bad-at-preserving/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-11-mario-zechner-recommends-a-post-arguing-that-ai-is-good-at-shipping-features-but-bad-at-preserving/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-11-mario-zechner-recommends-a-post-arguing-that-ai-is-good-at-shipping-features-but-bad-at-preserving/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;Extracted via api.fxtwitter.com fallback, then read linked article directly: https:&#x2F;&#x2F;blog.k10s.dev&#x2F;im-going-back-to-writing-code-by-hand&#x2F;&lt;&#x2F;li&gt;
&lt;li&gt;Mario Zechner recommends a post arguing that AI is good at shipping features but bad at preserving architecture unless humans impose explicit invariants.&lt;&#x2F;li&gt;
&lt;li&gt;Strong concrete examples from a 7-month rewrite of a GPU-aware Kubernetes TUI: god object drift, per-view state leakage, flat key-dispatch sprawl, and the need to write architecture rules in AGENTS.md&#x2F;CLAUDE.md up front.&lt;&#x2F;li&gt;
&lt;li&gt;Newsletter angle: one of the better anti-vibecoding-without-constraints field reports; useful counterweight to pure speed&#x2F;demo narratives.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
      <item>
          <title>Saved media locally</title>
          <pubDate>Mon, 11 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-11-saved-media-locally/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-11-saved-media-locally/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-11-saved-media-locally/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;Extracted via api.fxtwitter.com fallback; includes an image illustrating progressive rendering from noise to a clear cat image.&lt;&#x2F;li&gt;
&lt;li&gt;Saved media locally:&lt;&#x2F;li&gt;
&lt;li&gt;Dax reframes coding-agent usage: not like 3D printing one committed layer at a time, but like progressive rendering, start with a blurry whole, then make repeated full passes that sharpen the entire shape.&lt;&#x2F;li&gt;
&lt;li&gt;Follow-up reply worth keeping with it: https:&#x2F;&#x2F;x.com&#x2F;thdxr&#x2F;status&#x2F;2053566249351754193, he says this is actually counter to how his brain naturally imagines construction, which makes the metaphor more interesting as an adopted workflow rather than an obvious intuition.&lt;&#x2F;li&gt;
&lt;li&gt;Notable context: he says this clicked for him with GPT 5.5 plus voice prompting, which suggests a workflow shift as much as a model shift.&lt;&#x2F;li&gt;
&lt;li&gt;Newsletter angle: compact metaphor for iterative agent-assisted building; pairs well with the more skeptical architecture&#x2F;control links in this week&#x27;s batch.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
      <item>
          <title>34kb</title>
          <pubDate>Thu, 07 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-07-34kb/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-07-34kb/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-07-34kb/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;Extracted main post via &lt;code&gt;api.fxtwitter.com&lt;&#x2F;code&gt; fallback; the attached image includes the concrete compression results.&lt;&#x2F;li&gt;
&lt;li&gt;Sam Rose compares the same payload as JSON (&lt;code&gt;34kb&lt;&#x2F;code&gt;) and protobuf (&lt;code&gt;15kb&lt;&#x2F;code&gt;) and finds that after compression, JSON is often slightly smaller than protobuf for Brotli, Zstd, gzip, and bzip2; protobuf only wins clearly for lz4 and barely for lzma in his sample.&lt;&#x2F;li&gt;
&lt;li&gt;Concrete reported sizes from the screenshot: Brotli &lt;code&gt;json 4237 &amp;lt; bin 4279&lt;&#x2F;code&gt;, Zstd &lt;code&gt;4484 &amp;lt; 4702&lt;&#x2F;code&gt;, gzip &lt;code&gt;4766 &amp;lt; 4949&lt;&#x2F;code&gt;, bzip2 &lt;code&gt;5208 &amp;lt; 5302&lt;&#x2F;code&gt;, lzma &lt;code&gt;4500 &amp;gt; 4484&lt;&#x2F;code&gt;, lz4 &lt;code&gt;6245 &amp;gt; 5832&lt;&#x2F;code&gt;.&lt;&#x2F;li&gt;
&lt;li&gt;Why it is interesting: it is a good reminder that &lt;code&gt;binary format smaller on disk&#x2F;wire&lt;&#x2F;code&gt; and &lt;code&gt;binary format compresses smaller&lt;&#x2F;code&gt; are different questions; verbose JSON field names and repeated structure can give compressors more redundancy to exploit.&lt;&#x2F;li&gt;
&lt;li&gt;Good discussion angle: &lt;code&gt;protobuf vs JSON size intuition breaks once a strong general-purpose compressor enters the picture&lt;&#x2F;code&gt;.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
      <item>
          <title>agent principal-agent problem</title>
          <pubDate>Thu, 07 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-07-agent-principal-agent-problem/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-07-agent-principal-agent-problem/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-07-agent-principal-agent-problem/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;Read &lt;code&gt;The agent principal-agent problem&lt;&#x2F;code&gt; by David Crawshaw.&lt;&#x2F;li&gt;
&lt;li&gt;Core claim: classic review-before-commit code review assumed a human contributor whose effort and understanding could be inferred from the code; agent-mediated contribution breaks that signal and creates a principal-agent problem where reviewers absorb heavy load from low-effort, lightly-validated &lt;code&gt;slop PRs&lt;&#x2F;code&gt;.&lt;&#x2F;li&gt;
&lt;li&gt;The useful distinction is not just &lt;code&gt;agents good&#x2F;bad&lt;&#x2F;code&gt;, but &lt;code&gt;high-trust small teams&lt;&#x2F;code&gt; versus &lt;code&gt;low-trust large organizations&lt;&#x2F;code&gt;: small teams can collapse review and let the human prompter own deployment, while big companies remain bottlenecked by review bandwidth and blame-management.&lt;&#x2F;li&gt;
&lt;li&gt;The strongest practical point is that agents increase both the volume of changes and the temptation to offload reviewer feedback straight back into the model, which compounds review work instead of shrinking it.&lt;&#x2F;li&gt;
&lt;li&gt;Why it matters: this is one of the clearest process-level arguments for why agent productivity gains may accrue unevenly, favoring small trusted teams over large review-heavy orgs.&lt;&#x2F;li&gt;
&lt;li&gt;Good angle: &lt;code&gt;agents may be a force multiplier mostly where trust is already high; in low-trust orgs they amplify review economics instead&lt;&#x2F;code&gt;.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
      <item>
          <title>AI slop</title>
          <pubDate>Thu, 07 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-07-ai-slop/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-07-ai-slop/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-07-ai-slop/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;Extracted main post via &lt;code&gt;api.fxtwitter.com&lt;&#x2F;code&gt; fallback.&lt;&#x2F;li&gt;
&lt;li&gt;Mitchell Hashimoto argues that &lt;code&gt;AI slop&lt;&#x2F;code&gt; is useful as an internal experimentation tool: low-quality generated code&#x2F;UI&#x2F;plugins can dramatically reduce the cost of parallel exploration and API iteration, especially when regeneration is cheaper than careful hand maintenance.&lt;&#x2F;li&gt;
&lt;li&gt;His concrete examples are good: shipping an intentionally rough alpha frontend to focus on core internals, and using overnight agent loops to generate many disposable plugins so the whole ecosystem can be tested before the SDK is stable.&lt;&#x2F;li&gt;
&lt;li&gt;The key boundary conditions matter more than the provocation: do not dump first-pass slop into other projects, onto customers without review&#x2F;transparency, or mistake exploratory scaffolding for finished work.&lt;&#x2F;li&gt;
&lt;li&gt;Why it matters: this is a crisp articulation of where LLM-generated code changes the economics, not necessarily by improving final quality directly, but by collapsing the cost of reversible exploration.&lt;&#x2F;li&gt;
&lt;li&gt;Good angle: &lt;code&gt;the highest-leverage use of AI code may be disposable scaffolding that helps teams discover what deserves real engineering&lt;&#x2F;code&gt;.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
      <item>
          <title>Anthropic&#x27;s core idea is to train a model to verbalize its own internal activations into human-readable tex...</title>
          <pubDate>Thu, 07 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-07-anthropic-s-core-idea-is-to-train-a-model-to-verbalize-its-own-internal-activations-into-human-read/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-07-anthropic-s-core-idea-is-to-train-a-model-to-verbalize-its-own-internal-activations-into-human-read/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-07-anthropic-s-core-idea-is-to-train-a-model-to-verbalize-its-own-internal-activations-into-human-read/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;Extracted the Anthropic post via &lt;code&gt;api.fxtwitter.com&lt;&#x2F;code&gt; fallback and checked the linked research page &lt;code&gt;Natural Language Autoencoders: Turning Claude’s thoughts into text&lt;&#x2F;code&gt;.&lt;&#x2F;li&gt;
&lt;li&gt;Anthropic&#x27;s core idea is to train a model to verbalize its own internal activations into human-readable text, then train a second component to reconstruct the original activation from that explanation; better reconstruction is used as the training signal for better explanations.&lt;&#x2F;li&gt;
&lt;li&gt;This is interesting because it tries to turn interpretability outputs into something directly legible, instead of only giving researchers sparse features or attribution objects that still need heavy interpretation.&lt;&#x2F;li&gt;
&lt;li&gt;The examples Anthropic highlights are also practical rather than toy-only: detecting when Claude suspected it was in a safety eval, surfacing internal thinking around cheating&#x2F;avoiding detection, and tracing odd multilingual behavior back to training data.&lt;&#x2F;li&gt;
&lt;li&gt;Why it matters: if this works well, it could make &lt;code&gt;model internals&lt;&#x2F;code&gt; more inspectable by ordinary researchers and safety workflows, not just interpretability specialists.&lt;&#x2F;li&gt;
&lt;li&gt;Good angle: &lt;code&gt;interpretability may get much more useful when model states can be translated into rough natural-language hypotheses instead of only visualized as math&lt;&#x2F;code&gt;.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
      <item>
          <title>Auth for MCP</title>
          <pubDate>Thu, 07 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-07-auth-for-mcp/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-07-auth-for-mcp/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-07-auth-for-mcp/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;Extracted main post via &lt;code&gt;api.fxtwitter.com&lt;&#x2F;code&gt; fallback and checked the linked Auth0 GA announcement.&lt;&#x2F;li&gt;
&lt;li&gt;Auth0 is pitching &lt;code&gt;Auth for MCP&lt;&#x2F;code&gt; as the missing identity&#x2F;authorization layer for production MCP servers: not just connecting agents to tools, but enforcing who the user is and what the agent may do on their behalf.&lt;&#x2F;li&gt;
&lt;li&gt;The notable implementation details are support for &lt;code&gt;CIMD&lt;&#x2F;code&gt; client registration, &lt;code&gt;OBO&lt;&#x2F;code&gt; token exchange for downstream APIs, and MCP-style resource identifiers instead of plain OAuth audience handling.&lt;&#x2F;li&gt;
&lt;li&gt;Why it matters: MCP is quickly moving from demo protocol to real integration surface, and this is a sign the surrounding auth&#x2F;governance stack is hardening in parallel.&lt;&#x2F;li&gt;
&lt;li&gt;Good angle: &lt;code&gt;the boring enterprise layer is arriving for MCP, which is probably what makes it real&lt;&#x2F;code&gt;.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
      <item>
          <title>Autodata</title>
          <pubDate>Thu, 07 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-07-autodata/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-07-autodata/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-07-autodata/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;Extracted main post via &lt;code&gt;api.fxtwitter.com&lt;&#x2F;code&gt; fallback and checked the linked Meta RAM Autodata post plus the referenced &lt;code&gt;justrach&#x2F;devswarm&lt;&#x2F;code&gt; repo and sample issue.&lt;&#x2F;li&gt;
&lt;li&gt;Rach connects her agent workflow to Meta&#x27;s &lt;code&gt;Autodata&lt;&#x2F;code&gt; framing: agents act like data scientists by iterating on a hypothesis, generating data, testing it, validating results, extracting learnings, and then closing the loop.&lt;&#x2F;li&gt;
&lt;li&gt;The linked paper&#x2F;blog&#x27;s core idea is strong: convert inference-time compute into better training&#x2F;eval data quality by having an agent iteratively create data, analyze failures, refine the recipe, and even meta-optimize the data-scientist agent itself.&lt;&#x2F;li&gt;
&lt;li&gt;The concrete repo angle is useful too: &lt;code&gt;devswarm&lt;&#x2F;code&gt; applies a similar loop to software work with orchestrated subagents, reviewer&#x2F;fixer pipelines, and iterative review-fix loops grounded in real GitHub issues.&lt;&#x2F;li&gt;
&lt;li&gt;Why it matters: this is a nice bridge between &lt;code&gt;agentic synthetic data generation&lt;&#x2F;code&gt; and &lt;code&gt;agentic software work&lt;&#x2F;code&gt;, the shared pattern is not just many agents, but explicit hypothesis → test → validate → learn loops.&lt;&#x2F;li&gt;
&lt;li&gt;Good angle: &lt;code&gt;the durable unit of agent work may be the experimental loop, not the prompt or the tool call&lt;&#x2F;code&gt;.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
      <item>
          <title>Claude Mythos Preview</title>
          <pubDate>Thu, 07 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-07-claude-mythos-preview/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-07-claude-mythos-preview/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-07-claude-mythos-preview/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;Extracted Alex Albert&#x27;s post via &lt;code&gt;api.fxtwitter.com&lt;&#x2F;code&gt; fallback and read the attached chart.&lt;&#x2F;li&gt;
&lt;li&gt;Claim: with help from &lt;code&gt;Claude Mythos Preview&lt;&#x2F;code&gt;, the Firefox team fixed more security bugs in April 2026 than in the previous 15 months combined.&lt;&#x2F;li&gt;
&lt;li&gt;The screenshot supports the magnitude: &lt;code&gt;Firefox Security Bug Fixes by Month&lt;&#x2F;code&gt; shows a jump from ordinary monthly counts in the ~17–31 range through 2025, then &lt;code&gt;61&lt;&#x2F;code&gt; in Feb 2026, &lt;code&gt;76&lt;&#x2F;code&gt; in Mar 2026, and a huge spike to &lt;code&gt;423&lt;&#x2F;code&gt; in Apr 2026.&lt;&#x2F;li&gt;
&lt;li&gt;Caveat worth keeping in mind: the chart is labeled &lt;code&gt;All Sources · All Severities&lt;&#x2F;code&gt;, so this is broader than just critical vulns, and the post does not explain methodology beyond the attribution to Claude assistance.&lt;&#x2F;li&gt;
&lt;li&gt;Why it matters: even with caveats, this is a striking datapoint for AI-assisted security triage&#x2F;fix throughput in a real major codebase.&lt;&#x2F;li&gt;
&lt;li&gt;Good angle: &lt;code&gt;the first widely persuasive AI coding wins may come from backlog demolition in security and maintenance work, not greenfield feature building&lt;&#x2F;code&gt;.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
      <item>
          <title>Colossus 1</title>
          <pubDate>Thu, 07 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-07-colossus-1/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-07-colossus-1/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-07-colossus-1/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;Extracted Simon Willison&#x27;s post via &lt;code&gt;api.fxtwitter.com&lt;&#x2F;code&gt; fallback and checked the linked note &lt;code&gt;Notes on the xAI&#x2F;Anthropic data center deal&lt;&#x2F;code&gt;.&lt;&#x2F;li&gt;
&lt;li&gt;Simon&#x27;s main clarification is that Anthropic is getting &lt;code&gt;Colossus 1&lt;&#x2F;code&gt;, while xAI keeps using the larger &lt;code&gt;Colossus 2&lt;&#x2F;code&gt;; early chatter that xAI had given up its own compute was wrong.&lt;&#x2F;li&gt;
&lt;li&gt;The sharper points are around externalities and dependency risk: Colossus 1 reportedly has a particularly bad environmental record, and the deal effectively makes Anthropic dependent on infrastructure controlled by Elon&#x2F;xAI with an explicit &lt;code&gt;we reserve the right to reclaim the compute&lt;&#x2F;code&gt; caveat.&lt;&#x2F;li&gt;
&lt;li&gt;He also notes xAI had just given customers only two weeks&#x27; notice before shutting down several older models, which makes the supply-side relationship feel even shakier.&lt;&#x2F;li&gt;
&lt;li&gt;Why it matters: this is a reminder that frontier-model competition is now deeply entangled with opaque infrastructure, environmental politics, and supplier leverage, not just model benchmarks.&lt;&#x2F;li&gt;
&lt;li&gt;Good angle: &lt;code&gt;AI labs are accumulating supply-chain risk that looks a lot more like cloud&#x2F;geopolitics than pure software&lt;&#x2F;code&gt;.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
      <item>
          <title>DFlash</title>
          <pubDate>Thu, 07 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-07-dflash/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-07-dflash/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-07-dflash/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;Extracted main post via &lt;code&gt;api.fxtwitter.com&lt;&#x2F;code&gt; fallback and checked the linked repo &lt;code&gt;z-lab&#x2F;dflash&lt;&#x2F;code&gt;.&lt;&#x2F;li&gt;
&lt;li&gt;Zhijian Liu pitches &lt;code&gt;DFlash&lt;&#x2F;code&gt; for Gemma 4 as an open-source speculative decoding path that can push native Gemma 4 MTP further, claiming up to &lt;code&gt;6x&lt;&#x2F;code&gt; faster generation at the same quality.&lt;&#x2F;li&gt;
&lt;li&gt;Repo framing: &lt;code&gt;DFlash: Block Diffusion for Flash Speculative Decoding&lt;&#x2F;code&gt;, a lightweight block-diffusion draft model for speculative decoding, with support across Gemma, Qwen, Llama, GPT-OSS, MLX, vLLM, SGLang, and Transformers backends.&lt;&#x2F;li&gt;
&lt;li&gt;What seems notable is not just the speed claim, but that speculative-decoding acceleration is turning into a portable ecosystem layer with open models, backend integrations, and per-model draft variants.&lt;&#x2F;li&gt;
&lt;li&gt;Good angle: &lt;code&gt;inference-speed competition is moving into open, pluggable speculative-decoding infrastructure&lt;&#x2F;code&gt;.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
      <item>
          <title>Entire&#x27;s core claim is useful: from ~202k real tool calls across ~1,983 public coding-agent checkpoints, ab...</title>
          <pubDate>Thu, 07 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-07-entire-s-core-claim-is-useful-from-202k-real-tool-calls-across-1-983-public-coding-agent-checkpoint/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-07-entire-s-core-claim-is-useful-from-202k-real-tool-calls-across-1-983-public-coding-agent-checkpoint/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-07-entire-s-core-claim-is-useful-from-202k-real-tool-calls-across-1-983-public-coding-agent-checkpoint/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;Extracted Mario Zechner&#x27;s quote-post via &lt;code&gt;api.fxtwitter.com&lt;&#x2F;code&gt; fallback and checked the linked Entire blog post on agentic search.&lt;&#x2F;li&gt;
&lt;li&gt;Entire&#x27;s core claim is useful: from ~202k real tool calls across ~1,983 public coding-agent checkpoints, about &lt;code&gt;48.8%&lt;&#x2F;code&gt; were search-related, so search is a first-order agent behavior rather than a side utility.&lt;&#x2F;li&gt;
&lt;li&gt;Their more interesting finding is that raw speed is not the main bottleneck. Making search dramatically faster (&lt;code&gt;ripgrep&lt;&#x2F;code&gt; → &lt;code&gt;fff&lt;&#x2F;code&gt;) only modestly improved end-to-end run time because tool latency was a tiny fraction of total wall clock; ranking better results mattered more than shaving milliseconds.&lt;&#x2F;li&gt;
&lt;li&gt;Mario&#x27;s gloss is the punchline: there is still low-hanging fruit in &lt;code&gt;agentic search&lt;&#x2F;code&gt; if builders remember older information-retrieval lessons instead of treating the problem as just faster grep.&lt;&#x2F;li&gt;
&lt;li&gt;Why it matters: this is a strong correction to the instinct that agent tooling wins mainly through lower tool latency; the bigger win may be reducing search thrash by improving first-query usefulness.&lt;&#x2F;li&gt;
&lt;li&gt;Good angle: &lt;code&gt;agent search looks less like a systems-speed problem and more like a ranking&#x2F;IR problem from 2004 wearing an LLM hat&lt;&#x2F;code&gt;.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
      <item>
          <title>Hunk</title>
          <pubDate>Thu, 07 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-07-hunk/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-07-hunk/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-07-hunk/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;Extracted main post via &lt;code&gt;api.fxtwitter.com&lt;&#x2F;code&gt; fallback and checked the linked GitHub repo.&lt;&#x2F;li&gt;
&lt;li&gt;Mitchell Hashimoto strongly recommends &lt;code&gt;Hunk&lt;&#x2F;code&gt;, saying it has fully replaced other local diff viewers for him.&lt;&#x2F;li&gt;
&lt;li&gt;&lt;code&gt;Hunk&lt;&#x2F;code&gt; is positioned as a review-first terminal diff viewer for agent-authored changesets.&lt;&#x2F;li&gt;
&lt;li&gt;Notable capabilities from the repo: multi-file review stream with sidebar navigation, inline AI&#x2F;agent annotations, split&#x2F;stack responsive layouts, watch mode, keyboard + mouse support, pager mode, and Git difftool&#x2F;pager integration.&lt;&#x2F;li&gt;
&lt;li&gt;Install&#x2F;use gist: package name &lt;code&gt;hunkdiff&lt;&#x2F;code&gt;; commands mirror Git workflows (&lt;code&gt;hunk diff&lt;&#x2F;code&gt;, &lt;code&gt;hunk show&lt;&#x2F;code&gt;, &lt;code&gt;hunk patch -&lt;&#x2F;code&gt;).&lt;&#x2F;li&gt;
&lt;li&gt;Why it matters: looks like a purpose-built diff&#x2F;review surface for AI-assisted coding rather than a prettier plain diff pager.&lt;&#x2F;li&gt;
&lt;li&gt;Good angle: &lt;code&gt;tooling layer forming around agent-authored code review, not just code generation&lt;&#x2F;code&gt;.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
      <item>
          <title>is moving its GitHub repo into the</title>
          <pubDate>Thu, 07 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-07-is-moving-its-github-repo-into-the/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-07-is-moving-its-github-repo-into-the/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-07-is-moving-its-github-repo-into-the/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;Extracted main post via &lt;code&gt;api.fxtwitter.com&lt;&#x2F;code&gt; fallback.&lt;&#x2F;li&gt;
&lt;li&gt;Mario Zechner says &lt;code&gt;pi&lt;&#x2F;code&gt; is moving its GitHub repo into the &lt;code&gt;earendil-works&lt;&#x2F;code&gt; org and will start publishing packages under the &lt;code&gt;@earendil-works&lt;&#x2F;code&gt; npm namespace instead of &lt;code&gt;@mariozechner&lt;&#x2F;code&gt;.&lt;&#x2F;li&gt;
&lt;li&gt;Short-term compatibility remains for existing imports, but typed extensions should migrate quickly once the new packages land.&lt;&#x2F;li&gt;
&lt;li&gt;Breaking edge: extensions switched to &lt;code&gt;@earendil-works&lt;&#x2F;code&gt; will stop working on older &lt;code&gt;pi&lt;&#x2F;code&gt; versions after today&#x27;s release.&lt;&#x2F;li&gt;
&lt;li&gt;Why it matters: this is an ecosystem&#x2F;ownership cleanup move, but it deliberately forces extension authors to choose between forward compatibility and backward compatibility.&lt;&#x2F;li&gt;
&lt;li&gt;Good angle: &lt;code&gt;agent-tooling ecosystems are hitting the boring-but-real package-namespace migration phase, and extension authors absorb the breakage&lt;&#x2F;code&gt;.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
      <item>
          <title>microwavegang</title>
          <pubDate>Thu, 07 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-07-microwavegang/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-07-microwavegang/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-07-microwavegang/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;Extracted main post via &lt;code&gt;api.fxtwitter.com&lt;&#x2F;code&gt; fallback; the quoted tweet and attached screenshot provide the actual context.&lt;&#x2F;li&gt;
&lt;li&gt;Claim: a GPT-3 training loss spike was traced to scraped data from a &lt;code&gt;microwavegang&lt;&#x2F;code&gt; subreddit&#x2F;community full of text like &lt;code&gt;MMMMMMMMMMMMMM&lt;&#x2F;code&gt; and &lt;code&gt;BEEP BEEP BEEP&lt;&#x2F;code&gt;, and the spike disappeared after dataset cleanup.&lt;&#x2F;li&gt;
&lt;li&gt;The screenshot is funny but the underlying lesson is serious: weird narrow-distribution junk data can create visible optimization pathologies, and simple data cleaning can remove dramatic training instability.&lt;&#x2F;li&gt;
&lt;li&gt;Why it matters: this is a vivid, shareable example of &lt;code&gt;data quality showing up directly in loss curves&lt;&#x2F;code&gt;, which is often easier to remember than abstract warnings about web-scale corpora.&lt;&#x2F;li&gt;
&lt;li&gt;Good angle: &lt;code&gt;sometimes model progress is not smarter optimization but just deleting the internet&#x27;s microwave noises from the batch&lt;&#x2F;code&gt;.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
      <item>
          <title>Mirage</title>
          <pubDate>Thu, 07 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-07-mirage/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-07-mirage/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-07-mirage/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;Extracted main post via &lt;code&gt;api.fxtwitter.com&lt;&#x2F;code&gt; fallback and checked the linked repo &lt;code&gt;strukto-ai&#x2F;mirage&lt;&#x2F;code&gt;.&lt;&#x2F;li&gt;
&lt;li&gt;Zecheng Zhang introduces &lt;code&gt;Mirage&lt;&#x2F;code&gt;, a unified virtual filesystem for AI agents that mounts heterogeneous systems like S3, Drive, Slack, Gmail, GitHub, Linear, Notion, databases, and SSH into one filesystem abstraction.&lt;&#x2F;li&gt;
&lt;li&gt;Core pitch: agents can reuse familiar Unix&#x2F;bash semantics (&lt;code&gt;cat&lt;&#x2F;code&gt;, &lt;code&gt;grep&lt;&#x2F;code&gt;, &lt;code&gt;head&lt;&#x2F;code&gt;, pipes, &lt;code&gt;wc&lt;&#x2F;code&gt;) across mixed backends and even structured formats like parquet, csv, json, h5, and wav, instead of learning service-specific APIs.&lt;&#x2F;li&gt;
&lt;li&gt;Repo&#x2F;docs framing adds two notable pieces: portable&#x2F;versioned workspaces with snapshot&#x2F;clone&#x2F;rollback, and a two-layer cache so repeated remote reads collapse into local lookups.&lt;&#x2F;li&gt;
&lt;li&gt;Why it matters: this is a strong example of &lt;code&gt;filesystem-as-agent-interface&lt;&#x2F;code&gt; competing with SDK&#x2F;MCP sprawl by collapsing many tools into one high-prior fluency layer.&lt;&#x2F;li&gt;
&lt;li&gt;Good angle: &lt;code&gt;AI infra keeps rediscovering Unix, not just for code, but as the control plane for cross-service agent work&lt;&#x2F;code&gt;.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
      <item>
          <title>Nostalgia post in Portuguese about the mid-2000s pirate-game install ritual: uTorrent on slow internet, see...</title>
          <pubDate>Thu, 07 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-07-nostalgia-post-in-portuguese-about-the-mid-2000s-pirate-game-install-ritual-utorrent-on-slow-intern/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-07-nostalgia-post-in-portuguese-about-the-mid-2000s-pirate-game-install-ritual-utorrent-on-slow-intern/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-07-nostalgia-post-in-portuguese-about-the-mid-2000s-pirate-game-install-ritual-utorrent-on-slow-intern/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;Extracted main post via &lt;code&gt;api.fxtwitter.com&lt;&#x2F;code&gt; fallback.&lt;&#x2F;li&gt;
&lt;li&gt;Nostalgia post in Portuguese about the mid-2000s pirate-game install ritual: uTorrent on slow internet, seeding the ISO, Nero burn, Daemon Tools mount, no-CD crack, AVAST warning, mysterious Russian keygen, then finally launching the game.&lt;&#x2F;li&gt;
&lt;li&gt;Not really a deep technical claim, but it is a compact cultural artifact of the old PC internet stack: torrents, optical media, disk images, cracks, antivirus false alarms, and the weird literacy that desktop computing once required.&lt;&#x2F;li&gt;
&lt;li&gt;Why it matters: useful more as &lt;code&gt;internet culture memory&lt;&#x2F;code&gt; than newsletter substance.&lt;&#x2F;li&gt;
&lt;li&gt;Light angle if ever used: &lt;code&gt;the old internet demanded operational competence from normal users in a way today&#x27;s app stores mostly erase&lt;&#x2F;code&gt;.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
      <item>
          <title>Open Generative UI</title>
          <pubDate>Thu, 07 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-07-open-generative-ui/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-07-open-generative-ui/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-07-open-generative-ui/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;Extracted main post via &lt;code&gt;api.fxtwitter.com&lt;&#x2F;code&gt; fallback and checked the linked repos&#x2F;docs for &lt;code&gt;CopilotKit&#x2F;generative-ui&lt;&#x2F;code&gt; and &lt;code&gt;CopilotKit&#x2F;OpenGenerativeUI&lt;&#x2F;code&gt;.&lt;&#x2F;li&gt;
&lt;li&gt;Akshay Pachaar highlights &lt;code&gt;Open Generative UI&lt;&#x2F;code&gt;, an open-source take on Claude-style artifacts: the agent streams HTML&#x2F;SVG token-by-token into a sandboxed iframe so the UI visibly assembles live in chat.&lt;&#x2F;li&gt;
&lt;li&gt;The interesting implementation choice is that this is not component selection but open-ended UI generation from scratch, with safety coming from iframe isolation and quality steered by skill&#x2F;prompt layers.&lt;&#x2F;li&gt;
&lt;li&gt;Repo framing broadens it beyond one demo: CopilotKit positions generative UI as three patterns (&lt;code&gt;controlled&lt;&#x2F;code&gt;, &lt;code&gt;declarative&lt;&#x2F;code&gt;, &lt;code&gt;open-ended&lt;&#x2F;code&gt;) across AG-UI, A2UI&#x2F;Open-JSON-UI, and MCP Apps, with OpenGenerativeUI as the high-freedom showcase.&lt;&#x2F;li&gt;
&lt;li&gt;Why it matters: this is a good signal that &lt;code&gt;agent UX&lt;&#x2F;code&gt; is shifting from text-plus-tools toward runtime-generated interfaces, with skills&#x2F;specs becoming the control layer over unconstrained visual output.&lt;&#x2F;li&gt;
&lt;li&gt;Good angle: &lt;code&gt;artifacts are escaping proprietary chat apps and turning into an open protocol&#x2F;framework battle around agent-native UI&lt;&#x2F;code&gt;.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
      <item>
          <title>ParliamentWatch</title>
          <pubDate>Thu, 07 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-07-parliamentwatch/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-07-parliamentwatch/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-07-parliamentwatch/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;Extracted main post via &lt;code&gt;api.fxtwitter.com&lt;&#x2F;code&gt; fallback and checked the linked repo &lt;code&gt;pranaykotas&#x2F;parliamentwatch&lt;&#x2F;code&gt;.&lt;&#x2F;li&gt;
&lt;li&gt;&lt;code&gt;ParliamentWatch&lt;&#x2F;code&gt; aggregates 2900+ Indian parliamentary standing committee reports across all 24 DRSCs, with title&#x2F;full-text search, AI summaries, exports, and daily email alerts for new reports.&lt;&#x2F;li&gt;
&lt;li&gt;The repo framing is especially good: it positions committee reports as a serious but underused policy corpus, then makes them accessible through one searchable interface on top of &lt;code&gt;sansad.in&lt;&#x2F;code&gt;, with optional local-first caching and summarization.&lt;&#x2F;li&gt;
&lt;li&gt;Why it matters: this is exactly the kind of thin, practical civic-tech layer that turns a buried public archive into something researchers, journalists, and policy people can actually use day to day.&lt;&#x2F;li&gt;
&lt;li&gt;Good angle: &lt;code&gt;AI is most useful when it makes institutions legible, not just chatty&lt;&#x2F;code&gt;.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
      <item>
          <title>Printing Press</title>
          <pubDate>Thu, 07 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-07-printing-press/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-07-printing-press/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-07-printing-press/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;Extracted main post via &lt;code&gt;api.fxtwitter.com&lt;&#x2F;code&gt; fallback and checked &lt;code&gt;printingpress.dev&lt;&#x2F;code&gt;.&lt;&#x2F;li&gt;
&lt;li&gt;&lt;code&gt;Printing Press&lt;&#x2F;code&gt; is pitched as both a library of &lt;code&gt;agent-native CLIs&lt;&#x2F;code&gt; and a factory that generates new ones: from a spec&#x2F;site&#x2F;service it can print a token-efficient Go CLI, a Claude Code skill, an OpenClaw skill, and an MCP server.&lt;&#x2F;li&gt;
&lt;li&gt;The design philosophy is notable: local SQLite mirrors, compound commands, and CLI ergonomics are treated as a better substrate for agents than raw APIs, raw MCPs, or official vendor CLIs.&lt;&#x2F;li&gt;
&lt;li&gt;The examples are intentionally ambitious and eclectic, Linear, flights, contacts, sports, recipes, commerce, suggesting a bet that many agent integrations should collapse into local, queryable command surfaces rather than remote per-call tool chatter.&lt;&#x2F;li&gt;
&lt;li&gt;Why it matters: this is another strong signal that people are converging on &lt;code&gt;agent-native CLI&lt;&#x2F;code&gt; as a serious abstraction layer, not just a hacker preference.&lt;&#x2F;li&gt;
&lt;li&gt;Good angle: &lt;code&gt;the interface war for agents may be less API vs MCP than remote protocol vs local denormalized command surface&lt;&#x2F;code&gt;.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
      <item>
          <title>selection of great PRs that were submitted to Pi: a thread</title>
          <pubDate>Thu, 07 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-07-selection-of-great-prs-that-were-submitted-to-pi-a-thread/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-07-selection-of-great-prs-that-were-submitted-to-pi-a-thread/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-07-selection-of-great-prs-that-were-submitted-to-pi-a-thread/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;Extracted the root post via &lt;code&gt;api.fxtwitter.com&lt;&#x2F;code&gt; fallback: Armin Ronacher says it is &lt;code&gt;a selection of great PRs that were submitted to Pi, a thread&lt;&#x2F;code&gt;.&lt;&#x2F;li&gt;
&lt;li&gt;Tried browser fallback on X to read the thread, but replies are gated behind login&#x2F;signup, so the actual thread contents were not accessible from public view.&lt;&#x2F;li&gt;
&lt;li&gt;User context says the thread is satire about bad PRs sent to Pi, which fits the phrasing but I could not independently verify from the gated replies.&lt;&#x2F;li&gt;
&lt;li&gt;Blocker: root post readable; thread contents blocked by X login wall.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
      <item>
          <title>Ben Holmes says switching from TipTap&#x2F;ProseMirror to Slate made a rich-text bulleted-list interaction drama...</title>
          <pubDate>Wed, 06 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-06-ben-holmes-says-switching-from-tiptap-prosemirror-to-slate-made-a-rich-text-bulleted-list-interacti/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-06-ben-holmes-says-switching-from-tiptap-prosemirror-to-slate-made-a-rich-text-bulleted-list-interacti/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-06-ben-holmes-says-switching-from-tiptap-prosemirror-to-slate-made-a-rich-text-bulleted-list-interacti/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;Extracted main post via &lt;code&gt;api.fxtwitter.com&lt;&#x2F;code&gt; fallback.&lt;&#x2F;li&gt;
&lt;li&gt;Ben Holmes says switching from TipTap&#x2F;ProseMirror to Slate made a rich-text bulleted-list interaction dramatically easier to build; something that took weeks to half-work in TipTap took a couple of hours in Slate, with Codex helping.&lt;&#x2F;li&gt;
&lt;li&gt;Core signal is less &lt;code&gt;Slate is universally better&lt;&#x2F;code&gt; and more &lt;code&gt;framework ergonomics matter a lot for AI-assisted development&lt;&#x2F;code&gt;: some abstractions are much easier to extend&#x2F;debug with model help.&lt;&#x2F;li&gt;
&lt;li&gt;Why it matters: useful anecdote for editor-stack choice, especially when complex WYSIWYG behavior is on the roadmap and dev velocity matters more than ecosystem gravity alone.&lt;&#x2F;li&gt;
&lt;li&gt;Possible angle: &lt;code&gt;AI changes the editor-framework tradeoff by amplifying libraries with simpler mental models &#x2F; extension surfaces&lt;&#x2F;code&gt;.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
      <item>
          <title>ChatGPT Futures</title>
          <pubDate>Wed, 06 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-06-chatgpt-futures/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-06-chatgpt-futures/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-06-chatgpt-futures/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;Readable page copy was sparse, but enough to identify the core program: &lt;code&gt;ChatGPT Futures&lt;&#x2F;code&gt; is an OpenAI initiative highlighting 26 young people&#x2F;teams from the &lt;code&gt;Class of 2026&lt;&#x2F;code&gt; using AI to build, research, create, and expand what they can do.&lt;&#x2F;li&gt;
&lt;li&gt;Offer described on-page: each selected individual&#x2F;team in the inaugural class gets a &lt;code&gt;$10,000&lt;&#x2F;code&gt; grant plus access to OpenAI’s most cutting-edge technologies.&lt;&#x2F;li&gt;
&lt;li&gt;Framing is explicitly narrative&#x2F;recruiting: OpenAI wants to showcase the first generation that had ChatGPT throughout university and position them as evidence of where AI use is heading.&lt;&#x2F;li&gt;
&lt;li&gt;Browser access hit a Cloudflare &lt;code&gt;Verify you are human&lt;&#x2F;code&gt; wall, so deeper page detail may need manual&#x2F;browser-auth follow-up if there are profiles or selection criteria further down.&lt;&#x2F;li&gt;
&lt;li&gt;Good angle: &lt;code&gt;OpenAI is packaging student AI-native success stories into a grant&#x2F;fellowship-style talent funnel&lt;&#x2F;code&gt;.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
      <item>
          <title>de</title>
          <pubDate>Wed, 06 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-06-de/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-06-de/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-06-de/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;Extracted main post via &lt;code&gt;api.fxtwitter.com&lt;&#x2F;code&gt; fallback; inspected attached screenshot separately.&lt;&#x2F;li&gt;
&lt;li&gt;Thomas Ptacek argues the &lt;code&gt;.de&lt;&#x2F;code&gt; incident is decisive evidence against DNSSEC as &lt;code&gt;core Internet security functionality&lt;&#x2F;code&gt;.&lt;&#x2F;li&gt;
&lt;li&gt;Attached screenshot captures Cloudflare status text saying it temporarily disabled DNSSEC validation on &lt;code&gt;1.1.1.1&lt;&#x2F;code&gt; so &lt;code&gt;.de&lt;&#x2F;code&gt; names would continue resolving while DENIC fixed a DNSSEC signing problem.&lt;&#x2F;li&gt;
&lt;li&gt;Why it matters: this is the sharper, event-driven version of the previous anti-DNSSEC thesis, if a major resolver bypasses validation during a registry signing failure, the operational model looks fragile.&lt;&#x2F;li&gt;
&lt;li&gt;Useful paired angle with the linked essay: &lt;code&gt;theory from 2015&lt;&#x2F;code&gt; plus &lt;code&gt;real outage behavior in 2026&lt;&#x2F;code&gt;.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
      <item>
          <title>does not approximate attention</title>
          <pubDate>Wed, 06 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-06-does-not-approximate-attention/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-06-does-not-approximate-attention/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-06-does-not-approximate-attention/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;Extracted main post via &lt;code&gt;api.fxtwitter.com&lt;&#x2F;code&gt; fallback and checked the linked SubQ technical post.&lt;&#x2F;li&gt;
&lt;li&gt;Mario Zechner is skeptical of SubQ’s claim that SSA &lt;code&gt;does not approximate attention&lt;&#x2F;code&gt;; his objection is that unless ignored query-key pairs are provably zero-contribution, selective sparsification is still an approximation.&lt;&#x2F;li&gt;
&lt;li&gt;He also flags the missing detail that really matters: how the model chooses which query-key pairs to keep.&lt;&#x2F;li&gt;
&lt;li&gt;The linked SubQ write-up claims &lt;code&gt;content-dependent selection&lt;&#x2F;code&gt; routes attention only to positions that carry signal, yielding linear scaling and large prefill speedups at long context lengths.&lt;&#x2F;li&gt;
&lt;li&gt;Useful counterweight to the earlier SubQ hype post: the key technical question is not just benchmark wins, but whether the selection mechanism preserves retrieval quality without hiding approximation debt.&lt;&#x2F;li&gt;
&lt;li&gt;Good angle: &lt;code&gt;skeptic check on flashy sparse-attention claims&lt;&#x2F;code&gt;.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
      <item>
          <title>dreaming</title>
          <pubDate>Wed, 06 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-06-dreaming/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-06-dreaming/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-06-dreaming/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;Claude Managed Agents update centered on three things: &lt;code&gt;dreaming&lt;&#x2F;code&gt;, &lt;code&gt;outcomes&lt;&#x2F;code&gt;, and &lt;code&gt;multiagent orchestration&lt;&#x2F;code&gt;.&lt;&#x2F;li&gt;
&lt;li&gt;&lt;code&gt;Dreaming&lt;&#x2F;code&gt; is a research-preview async job that reads an existing memory store plus past session transcripts and emits a cleaned&#x2F;reorganized memory store with deduped facts, replaced stale entries, and new synthesized insights; original store remains unchanged.&lt;&#x2F;li&gt;
&lt;li&gt;&lt;code&gt;Outcomes&lt;&#x2F;code&gt; adds an explicit &lt;code&gt;done&lt;&#x2F;code&gt; target plus rubric-driven grading, turning a session from chat into iterative artifact production with a separate grader context feeding gap reports back to the agent.&lt;&#x2F;li&gt;
&lt;li&gt;&lt;code&gt;Multiagent orchestration&lt;&#x2F;code&gt; lets a coordinator agent delegate to specialized agents running in isolated persistent session threads while sharing the same container&#x2F;filesystem.&lt;&#x2F;li&gt;
&lt;li&gt;Overall pattern: Anthropic is productizing more of the harness layer explicitly, memory maintenance, evaluator loops, and agent delegation, instead of treating them as app-side glue.&lt;&#x2F;li&gt;
&lt;li&gt;Strong newsletter angle: &lt;code&gt;managed agents are becoming workflow infrastructure, not just a model wrapper&lt;&#x2F;code&gt;.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
      <item>
          <title>HTML5+CSS face lift for the generated pages</title>
          <pubDate>Wed, 06 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-06-html5-css-face-lift-for-the-generated-pages/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-06-html5-css-face-lift-for-the-generated-pages/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-06-html5-css-face-lift-for-the-generated-pages/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;GitHub PR title: &lt;code&gt;HTML5+CSS face lift for the generated pages&lt;&#x2F;code&gt; by &lt;code&gt;knadh&lt;&#x2F;code&gt; on &lt;code&gt;mitmproxy&#x2F;pdoc&lt;&#x2F;code&gt;; merged Nov 20, 2014.&lt;&#x2F;li&gt;
&lt;li&gt;Logged as a &lt;code&gt;folklore&lt;&#x2F;code&gt;&#x2F;historical reference rather than a current article; likely relevant as an old design&#x2F;implementation artifact in the pdoc&#x2F;docsite lineage.&lt;&#x2F;li&gt;
&lt;li&gt;Retrieval from the public PR page was partial because logged-out GitHub readability extraction is thin, but title&#x2F;author&#x2F;repo&#x2F;merged status were captured.&lt;&#x2F;li&gt;
&lt;li&gt;Follow-up if needed: inspect commits&#x2F;diff directly or use GitHub API&#x2F;source checkout for the substantive changes.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
      <item>
          <title>News: Dell and Lenovo became premier sponsors of LVFS (Linux Vendor Firmware Service), the fwupd-backed fir...</title>
          <pubDate>Wed, 06 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-06-news-dell-and-lenovo-became-premier-sponsors-of-lvfs-linux-vendor-firmware-service-the-fwupd-backed/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-06-news-dell-and-lenovo-became-premier-sponsors-of-lvfs-linux-vendor-firmware-service-the-fwupd-backed/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-06-news-dell-and-lenovo-became-premier-sponsors-of-lvfs-linux-vendor-firmware-service-the-fwupd-backed/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;Extracted main post via &lt;code&gt;api.fxtwitter.com&lt;&#x2F;code&gt; fallback and read linked Phoronix coverage.&lt;&#x2F;li&gt;
&lt;li&gt;News: Dell and Lenovo became premier sponsors of LVFS (Linux Vendor Firmware Service), the fwupd-backed firmware update infrastructure for Linux.&lt;&#x2F;li&gt;
&lt;li&gt;Funding detail from Phoronix: premier sponsorship is &lt;code&gt;$100k&#x2F;year&lt;&#x2F;code&gt;; Dell and Lenovo are the first at that tier, alongside existing support from Framework, the Open Source Firmware Foundation, Linux Foundation, and Red Hat.&lt;&#x2F;li&gt;
&lt;li&gt;Why it matters: this is quiet but important ecosystem maturation, big OEMs are not just consuming Linux firmware-update plumbing, but funding the shared infrastructure behind it.&lt;&#x2F;li&gt;
&lt;li&gt;Nice signal for Linux desktop&#x2F;server credibility: LVFS has shipped more than &lt;code&gt;145M&lt;&#x2F;code&gt; firmware updates, so this looks like core-maintenance money flowing into proven open-source infra.&lt;&#x2F;li&gt;
&lt;li&gt;Good angle: &lt;code&gt;boring but consequential open-source infrastructure finally getting OEM money&lt;&#x2F;code&gt;.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
      <item>
          <title>nless</title>
          <pubDate>Wed, 06 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-06-nless/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-06-nless/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-06-nless/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;Extracted main post via &lt;code&gt;api.fxtwitter.com&lt;&#x2F;code&gt; fallback and checked project site for more detail.&lt;&#x2F;li&gt;
&lt;li&gt;Terminal Trove highlights &lt;code&gt;nless&lt;&#x2F;code&gt; (&lt;code&gt;nothing-less&lt;&#x2F;code&gt;) by Matt Pryor: a Textual-based TUI for exploring logs&#x2F;CSV&#x2F;JSON as terminal tables.&lt;&#x2F;li&gt;
&lt;li&gt;Most interesting capabilities: live streaming stdin, delimiter inference&#x2F;switching, filter&#x2F;sort&#x2F;search, log parsing into columns, pivoting&#x2F;reshaping, excluded-line inspection, and saved sessions&#x2F;views.&lt;&#x2F;li&gt;
&lt;li&gt;Author framing: built from a Kubernetes engineer’s need to dissect streaming tabular data like &lt;code&gt;kubectl get ... -w&lt;&#x2F;code&gt; output.&lt;&#x2F;li&gt;
&lt;li&gt;Why it matters: looks like a strong operator&#x2F;debugging tool in the &lt;code&gt;lnav&lt;&#x2F;code&gt; &#x2F; &lt;code&gt;visidata&lt;&#x2F;code&gt; &#x2F; &lt;code&gt;csvlens&lt;&#x2F;code&gt; neighborhood but with better live-stream ergonomics.&lt;&#x2F;li&gt;
&lt;li&gt;Good follow-up angle: worth trying on OpenClaw logs, kubectl&#x2F;event streams, or broker&#x2F;infra logs; possible &lt;code&gt;terminal tools worth actually adopting&lt;&#x2F;code&gt; candidate.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
      <item>
          <title>Satya&#x2F;Microsoft framing: firms need to redesign work around agentic systems, with AI taking more execution...</title>
          <pubDate>Wed, 06 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-06-satya-microsoft-framing-firms-need-to-redesign-work-around-agentic-systems-with-ai-taking-more-exec/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-06-satya-microsoft-framing-firms-need-to-redesign-work-around-agentic-systems-with-ai-taking-more-exec/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-06-satya-microsoft-framing-firms-need-to-redesign-work-around-agentic-systems-with-ai-taking-more-exec/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;Extracted main post via &lt;code&gt;api.fxtwitter.com&lt;&#x2F;code&gt; fallback and read the linked Microsoft Work Trend Index piece &lt;code&gt;Agents, human agency, and the opportunity for organizations&lt;&#x2F;code&gt;.&lt;&#x2F;li&gt;
&lt;li&gt;Satya&#x2F;Microsoft framing: firms need to redesign work around agentic systems, with AI taking more execution while humans shift toward judgment, intent-setting, and owning outcomes.&lt;&#x2F;li&gt;
&lt;li&gt;The more interesting claim is organizational, not individual: Microsoft says culture, manager support, and talent practices explain more than 2x the reported AI impact of individual effort alone.&lt;&#x2F;li&gt;
&lt;li&gt;Key vocabulary from the report: &lt;code&gt;Frontier Professionals&lt;&#x2F;code&gt; &#x2F; &lt;code&gt;Frontier Firms&lt;&#x2F;code&gt;, plus a &lt;code&gt;Transformation Paradox&lt;&#x2F;code&gt; where employees are ready to reinvent work with AI but incentives and norms still reward the old model.&lt;&#x2F;li&gt;
&lt;li&gt;Feels like classic Microsoft enterprise packaging of a real point: AI value depends less on raw model access and more on whether organizations actually redesign workflows, management, and evaluation.&lt;&#x2F;li&gt;
&lt;li&gt;Good newsletter angle: &lt;code&gt;AI adoption is becoming operating-model redesign, not just tooling rollout&lt;&#x2F;code&gt;.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
      <item>
          <title>tqbf</title>
          <pubDate>Wed, 06 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-06-tqbf/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-06-tqbf/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-06-tqbf/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;Extracted main post via &lt;code&gt;api.fxtwitter.com&lt;&#x2F;code&gt; fallback.&lt;&#x2F;li&gt;
&lt;li&gt;Thomas Ptacek (&lt;code&gt;tqbf&lt;&#x2F;code&gt;) resurfaces his 2015 essay &lt;code&gt;Against DNSSEC&lt;&#x2F;code&gt;: https:&#x2F;&#x2F;sockpuppet.org&#x2F;blog&#x2F;2015&#x2F;01&#x2F;15&#x2F;against-dnssec&#x2F;&lt;&#x2F;li&gt;
&lt;li&gt;Core gist of the linked essay:&lt;&#x2F;li&gt;
&lt;li&gt;Why it matters now: good historical context for the recent &lt;code&gt;.de&lt;&#x2F;code&gt; &#x2F; DNSSEC outage discussion cluster and the tradeoff between cryptographic integrity and operational fragility.&lt;&#x2F;li&gt;
&lt;li&gt;Good newsletter angle: &lt;code&gt;old anti-DNSSEC argument worth rereading during a real-world DNSSEC-linked ccTLD failure&lt;&#x2F;code&gt;.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
      <item>
          <title>transfer station</title>
          <pubDate>Wed, 06 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-06-transfer-station/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-06-transfer-station/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-06-transfer-station/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;Extracted main post via &lt;code&gt;api.fxtwitter.com&lt;&#x2F;code&gt; fallback and read linked ChinaTalk piece &lt;code&gt;How to Buy Cheap Claude Tokens in China&lt;&#x2F;code&gt;.&lt;&#x2F;li&gt;
&lt;li&gt;Kyle Chan highlights Zilan Qian’s write-up on the &lt;code&gt;transfer station&lt;&#x2F;code&gt; economy around blocked frontier-model access in China.&lt;&#x2F;li&gt;
&lt;li&gt;Core claim: this is not just a handful of labs evading restrictions, but a broader gray-market stack of intermediaries, payments, proxying, account supply, and abuse adaptation serving ordinary developers, hobbyists, and companies.&lt;&#x2F;li&gt;
&lt;li&gt;Most important insight is governance-related, not the mechanics: each added provider control layer (geoblocking, phone verification, cards, KYC) appears to generate a matching evasion market, with spillovers into fraud, identity abuse, and loss of provider traceability.&lt;&#x2F;li&gt;
&lt;li&gt;Price angle from the piece: proxy markets can undercut official pricing dramatically, suggesting logs&#x2F;abuse&#x2F;arbitrage may be part of the business model rather than simple pass-through resale.&lt;&#x2F;li&gt;
&lt;li&gt;Strong newsletter angle: &lt;code&gt;AI access controls are creating gray-market infrastructure with safety and fraud externalities&lt;&#x2F;code&gt;.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
      <item>
          <title>de TLD offline due to DNSSEC?</title>
          <pubDate>Tue, 05 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-05-de-tld-offline-due-to-dnssec/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-05-de-tld-offline-due-to-dnssec/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-05-de-tld-offline-due-to-dnssec/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;HN thread title: &lt;code&gt;.de TLD offline due to DNSSEC?&lt;&#x2F;code&gt;&lt;&#x2F;li&gt;
&lt;li&gt;Most useful technical claim in the thread: this looked like a DNSSEC validation failure rather than a nameserver outage, with malformed&#x2F;bad RRSIGs causing validating resolvers to return SERVFAIL for &lt;code&gt;.de&lt;&#x2F;code&gt; domains.&lt;&#x2F;li&gt;
&lt;li&gt;Extra color from discussion: intermittency may have come from anycast nodes serving mixed good&#x2F;bad signatures or cached answers; some users recovered temporarily via cached resolvers or by disabling validation.&lt;&#x2F;li&gt;
&lt;li&gt;Useful because it adds a plausible technical explanation to the broader ccTLD-risk theme, not just anecdotal frustration.&lt;&#x2F;li&gt;
&lt;li&gt;Follow-up source from Nemo: https:&#x2F;&#x2F;x.com&#x2F;i&#x2F;status&#x2F;2051756854275964996 linking blog post https:&#x2F;&#x2F;captnemo.in&#x2F;blog&#x2F;2026&#x2F;05&#x2F;05&#x2F;namecheap-whois&#x2F;&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
      <item>
          <title>de</title>
          <pubDate>Tue, 05 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-05-de/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-05-de/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-05-de/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;Extracted via api.fxtwitter.com fallback.&lt;&#x2F;li&gt;
&lt;li&gt;Armin Ronacher reacting to &lt;code&gt;.de&lt;&#x2F;code&gt; outage: &lt;code&gt;How the hell do you take all of .de offline?&lt;&#x2F;code&gt;, useful signal that ccTLD operational failures were visible well beyond India.&lt;&#x2F;li&gt;
&lt;li&gt;Pranesh Prakash: &lt;code&gt;Nixi is a terrible domain registry.&lt;&#x2F;code&gt; quoting Nemo&#x27;s report that &lt;code&gt;inregistry&lt;&#x2F;code&gt; suspended his primary &lt;code&gt;.in&lt;&#x2F;code&gt; domain without a single email over allegedly invalid WHOIS, while &lt;code&gt;.in&lt;&#x2F;code&gt; also lacks WHOIS privacy.&lt;&#x2F;li&gt;
&lt;li&gt;Nikhil Pahwa adds prior experience: avoided switching MediaNama to &lt;code&gt;na.ma&lt;&#x2F;code&gt;; says the Moroccan registry was a nightmare and worse than NIXI.&lt;&#x2F;li&gt;
&lt;li&gt;Theme to track: the last week had multiple reminders that country TLDs can carry operational, policy, and privacy risk beyond normal registrar risk.&lt;&#x2F;li&gt;
&lt;li&gt;Good newsletter&#x2F;blog angle: country-code domains as hidden infrastructure risk; convenience&#x2F;branding vs registry reliability, due process, and privacy.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
      <item>
          <title>Fragments: May 5</title>
          <pubDate>Tue, 05 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-05-fragments-may-5/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-05-fragments-may-5/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-05-fragments-may-5/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;Extracted via api.fxtwitter.com fallback.&lt;&#x2F;li&gt;
&lt;li&gt;Martin Fowler &lt;code&gt;Fragments: May 5&lt;&#x2F;code&gt; roundup linking: open-source framework for prompting patterns, musician suing Google for defamation, Apple rethinking AI spend, running LLMs locally, and whether &lt;code&gt;The Genie&lt;&#x2F;code&gt; gets caught in the tar pit.&lt;&#x2F;li&gt;
&lt;li&gt;Link target: https:&#x2F;&#x2F;martinfowler.com&#x2F;fragments&#x2F;2026-05-05.html&lt;&#x2F;li&gt;
&lt;li&gt;Likely useful as a curated bundle rather than a single thesis; good source to revisit for one or two standout downstream links.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
      <item>
          <title>Frank&#x2F;jedisct1: SKILL.md is fine for static instructions. But many useful agent workflows are not just inst...</title>
          <pubDate>Tue, 05 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-05-frank-jedisct1-skill-md-is-fine-for-static-instructions-but-many-useful-agent-workflows-are-not-jus/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-05-frank-jedisct1-skill-md-is-fine-for-static-instructions-but-many-useful-agent-workflows-are-not-jus/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-05-frank-jedisct1-skill-md-is-fine-for-static-instructions-but-many-useful-agent-workflows-are-not-jus/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;Extracted via api.fxtwitter.com fallback.&lt;&#x2F;li&gt;
&lt;li&gt;Frank&#x2F;jedisct1: &lt;code&gt;SKILL.md is fine for static instructions. But many useful agent workflows are not just instructions. They are loops. Introducing Agent MetaSKILLs&lt;&#x2F;code&gt;.&lt;&#x2F;li&gt;
&lt;li&gt;Linked page: https:&#x2F;&#x2F;swival.dev&#x2F;pages&#x2F;metaskills.html&lt;&#x2F;li&gt;
&lt;li&gt;Relevance to &lt;code&gt;https:&#x2F;&#x2F;rohanverma.net&#x2F;pages&#x2F;harness-engineering&#x2F;&lt;&#x2F;code&gt;: strong fit with the site’s emphasis on harnesses as loops, feedback systems, progressive knowledge, and infrastructure around the model rather than the model alone.&lt;&#x2F;li&gt;
&lt;li&gt;Especially adjacent to sections on Skills, Meta-Skills, The Loop, The Daemon, Q the Task Agent, and the review&#x2F;feedback loop.&lt;&#x2F;li&gt;
&lt;li&gt;Good follow-up angle: contrast static skill documents vs executable&#x2F;dynamic workflow programs inside a harness.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
      <item>
          <title>Mitchell Hashimoto post praising antirez&#x27;s write-up on developing Redis Array support as a good example of...</title>
          <pubDate>Tue, 05 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-05-mitchell-hashimoto-post-praising-antirez-s-write-up-on-developing-redis-array-support-as-a-good-exa/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-05-mitchell-hashimoto-post-praising-antirez-s-write-up-on-developing-redis-array-support-as-a-good-exa/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-05-mitchell-hashimoto-post-praising-antirez-s-write-up-on-developing-redis-array-support-as-a-good-exa/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;Mitchell Hashimoto post praising antirez&#x27;s write-up on developing Redis Array support as a good example of thoughtful AI usage that empowers strong developers while preserving quality.&lt;&#x2F;li&gt;
&lt;li&gt;Linked article: https:&#x2F;&#x2F;antirez.com&#x2F;news&#x2F;164&lt;&#x2F;li&gt;
&lt;li&gt;Read&#x2F;stored gist of antirez article &lt;code&gt;Redis array type: short story of a long development&lt;&#x2F;code&gt;:&lt;&#x2F;li&gt;
&lt;li&gt;Related PR&#x2F;use-cases link: https:&#x2F;&#x2F;github.com&#x2F;redis&#x2F;redis&#x2F;pull&#x2F;15162&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
      <item>
          <title>Pimalaya: open-source PIM tools in Rust; positions itself as I&#x2F;O-free Rust libraries plus house-made applic...</title>
          <pubDate>Tue, 05 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-05-pimalaya-open-source-pim-tools-in-rust-positions-itself-as-i-o-free-rust-libraries-plus-house-made/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-05-pimalaya-open-source-pim-tools-in-rust-positions-itself-as-i-o-free-rust-libraries-plus-house-made/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-05-pimalaya-open-source-pim-tools-in-rust-positions-itself-as-i-o-free-rust-libraries-plus-house-made/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;Pimalaya: open-source PIM tools in Rust; positions itself as I&#x2F;O-free Rust libraries plus house-made applications for the PIM domain.&lt;&#x2F;li&gt;
&lt;li&gt;Himalaya: CLI to manage emails; supports IMAP&#x2F;Maildir&#x2F;Notmuch, SMTP&#x2F;Sendmail, keyring, OAuth2, JSON output, and multi-account configuration.&lt;&#x2F;li&gt;
&lt;li&gt;User intent: explore using Pimalaya&#x2F;Himalaya to clean up a ~2k pending inbox.&lt;&#x2F;li&gt;
&lt;li&gt;Related idea: connect this with Kailash Nadh&#x27;s email UI idea.&lt;&#x2F;li&gt;
&lt;li&gt;Writing idea to track: future post on rohanverma.net about using the harness to clean the inbox with this stack; create&#x2F;track under a separate &lt;code&gt;Writing ideas&lt;&#x2F;code&gt; topic later.&lt;&#x2F;li&gt;
&lt;li&gt;Good follow-up angle: practical personal email triage workflow built from CLI + custom harness, then surfaced via a nicer UI.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
      <item>
          <title>Pratilekha</title>
          <pubDate>Tue, 05 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-05-pratilekha/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-05-pratilekha/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-05-pratilekha/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;Extracted via api.fxtwitter.com fallback.&lt;&#x2F;li&gt;
&lt;li&gt;Uttaran Nayak (Bangalore) announcing &lt;code&gt;Pratilekha&lt;&#x2F;code&gt;: &lt;code&gt;one API, every Indian &amp;amp; regional language. and we built this ourselves.&lt;&#x2F;code&gt;&lt;&#x2F;li&gt;
&lt;li&gt;Early signal worth tracking as part of the India&#x2F;Bangalore AI&#x2F;app layer scene, especially around multilingual infrastructure rather than generic model wrappers.&lt;&#x2F;li&gt;
&lt;li&gt;Good follow-up question later: what is actually novel here, translation, speech, multilingual inference stack, or developer platform packaging?&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
      <item>
          <title>Simone&#x2F;evilsocket amplifying claim that Chrome silently installs a 4 GB Gemini Nano model on user devices,...</title>
          <pubDate>Tue, 05 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-05-simone-evilsocket-amplifying-claim-that-chrome-silently-installs-a-4-gb-gemini-nano-model-on-user-d/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-05-simone-evilsocket-amplifying-claim-that-chrome-silently-installs-a-4-gb-gemini-nano-model-on-user-d/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-05-simone-evilsocket-amplifying-claim-that-chrome-silently-installs-a-4-gb-gemini-nano-model-on-user-d/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;Extracted via api.fxtwitter.com fallback.&lt;&#x2F;li&gt;
&lt;li&gt;Simone&#x2F;evilsocket amplifying claim that Chrome silently installs a 4 GB Gemini Nano model on user devices, without clear consent prompt, and re-downloads it if deleted.&lt;&#x2F;li&gt;
&lt;li&gt;Linked article: https:&#x2F;&#x2F;awesomeagents.ai&#x2F;news&#x2F;chrome-gemini-nano-silent-install&#x2F;&lt;&#x2F;li&gt;
&lt;li&gt;Why it matters: local&#x2F;on-device AI is increasingly shipping as platform behavior, not just user choice; good angle around consent, storage&#x2F;bandwidth costs, and silent AI infra deployment.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
      <item>
          <title>SubQ</title>
          <pubDate>Tue, 05 May 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://reading-list.oddship.net/notes/2026-05-05-subq/</link>
          <guid>https://reading-list.oddship.net/notes/2026-05-05-subq/</guid>
          <description xml:base="https://reading-list.oddship.net/notes/2026-05-05-subq/">&lt;p&gt;Imported from historical reading log.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;Main post successfully extracted via api.fxtwitter.com fallback.&lt;&#x2F;li&gt;
&lt;li&gt;Post by Alexander Whedon introducing &lt;code&gt;SubQ&lt;&#x2F;code&gt; as a sparse-attention LLM architecture claim: fully sub-quadratic sparse attention, 12M token context window, 52x faster than FlashAttention at 1M tokens, under 5% of Opus cost, and &lt;code&gt;nearly 1,000x less compute&lt;&#x2F;code&gt; by focusing only on relationships that matter.&lt;&#x2F;li&gt;
&lt;li&gt;Core framing: standard transformer attention computes many unnecessary token relationships; sparse attention focuses only on the small fraction that matters.&lt;&#x2F;li&gt;
&lt;li&gt;No &lt;code&gt;tweet.article&lt;&#x2F;code&gt; block present in the API response for this post, so plain tweet text was used.&lt;&#x2F;li&gt;
&lt;li&gt;Could not reliably access replies without hitting X login&#x2F;interstitial walls; need another mirror, API route, or screenshots if reply-level analysis matters.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</description>
      </item>
    </channel>
</rss>
