<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Alex Chen</title>
    <link>https://example.org/</link>
    <description>Recent content on Alex Chen</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Sun, 17 May 2026 11:30:00 +0800</lastBuildDate>
    <atom:link href="https://example.org/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>HN: AI Agents Need Boundaries</title>
      <link>https://example.org/memos/2026/05/2026-05-17-hn-ai-agents-boundaries/</link>
      <pubDate>Sun, 17 May 2026 11:30:00 +0800</pubDate>
      <guid>https://example.org/memos/2026/05/2026-05-17-hn-ai-agents-boundaries/</guid>
      <description>&lt;p&gt;The latest Hacker News agent cluster shows a useful tension. On one side, builders are shipping agent tools, skills, memory systems, coding agents, and payment rails. On the other side, practitioners are skeptical that current models can reliably orchestrate many agents.&lt;/p&gt;&#xA;&lt;p&gt;The practical frontier is not fully autonomous swarms. It is bounded agents with narrow permissions, clear tool contracts, reviewable memory, explicit skills, observable state, and interruptible execution.&lt;/p&gt;&#xA;&lt;p&gt;Five useful signals:&lt;/p&gt;</description>
    </item>
    <item>
      <title>HN: Large Models Become Infrastructure</title>
      <link>https://example.org/memos/2026/05/2026-05-17-hn-large-models-infrastructure/</link>
      <pubDate>Sun, 17 May 2026 11:20:00 +0800</pubDate>
      <guid>https://example.org/memos/2026/05/2026-05-17-hn-large-models-infrastructure/</guid>
      <description>&lt;p&gt;The latest Hacker News discussions around large language models feel less centered on &amp;ldquo;which model is smartest&amp;rdquo; and more centered on the infrastructure around models: memory, attention cost, model provenance, and everyday engineering workflows.&lt;/p&gt;&#xA;&lt;p&gt;That is a meaningful shift. Once LLMs become a standard component in software systems, their bottlenecks are not only benchmark scores. They are latency, long-context economics, memory reliability, source influence, observability, and how engineers actually use them in production work.&lt;/p&gt;</description>
    </item>
    <item>
      <title>HN: LLMs in Quant Trading</title>
      <link>https://example.org/memos/2026/05/2026-05-17-hn-llm-quant-trading/</link>
      <pubDate>Sun, 17 May 2026 11:10:00 +0800</pubDate>
      <guid>https://example.org/memos/2026/05/2026-05-17-hn-llm-quant-trading/</guid>
      <description>&lt;p&gt;Recent Hacker News posts around LLMs and trading are converging on a practical pattern: people do not fully trust LLMs to trade autonomously, but they are increasingly willing to use them as reasoning, evaluation, and thesis-pressure-testing layers.&lt;/p&gt;&#xA;&lt;p&gt;The useful distinction is between the model as a trader and the model as an investment committee member. In the better architectures, deterministic systems still own market data ingestion, indicators, backtests, position sizing, execution, and hard risk limits. The LLM receives computed evidence and qualitative context, then contributes a reasoned view.&lt;/p&gt;</description>
    </item>
    <item>
      <title>杠铃式阅读</title>
      <link>https://example.org/memos/2026/05/2026-05-16-barbell-reading/</link>
      <pubDate>Sat, 16 May 2026 18:30:00 +0800</pubDate>
      <guid>https://example.org/memos/2026/05/2026-05-16-barbell-reading/</guid>
      <description>&lt;p&gt;硅谷传奇投资人 Marc Andreessen 最近分享了一种很有意思的阅读方法，叫“杠铃式阅读”。&lt;/p&gt;&#xA;&lt;p&gt;一端是最新的信息，比如 X 上的实时动态。因为很多行业变化太快，真正的一手信号，往往最早出现在一线从业者的推文里。&lt;/p&gt;&#xA;&lt;p&gt;另一端是特别老的书，最好是 50 年以上的经典。因为能穿越几十年还被人反复阅读的东西，通常已经经过时间筛选。&lt;/p&gt;&#xA;&lt;p&gt;中间那一层，比如报纸、杂志，他反而很少看。因为很多内容既不够快，也不够深。&lt;/p&gt;&#xA;&lt;p&gt;他还特别重视 practitioner-led newsletters，也就是一线实践者写的 newsletter。&lt;/p&gt;&#xA;&lt;p&gt;比如投资人、创业者、工程师、医生、研究员，亲自把自己在工作中看到的问题、踩过的坑、总结出的经验写下来。这类内容通常很朴素，但很接近真实世界，反而比很多包装精美的媒体文章更有价值。&lt;/p&gt;</description>
    </item>
    <item>
      <title>Agent Memory Needs a Clock</title>
      <link>https://example.org/blog/2026/05/agent-memory-needs-time/</link>
      <pubDate>Fri, 15 May 2026 10:00:00 +0800</pubDate>
      <guid>https://example.org/blog/2026/05/agent-memory-needs-time/</guid>
      <description>&lt;p&gt;Mem0&amp;rsquo;s latest article on Memory Decay makes a useful point about agent memory: remembering more is not the same thing as remembering well. Long-running agents need a sense of time, because context that mattered last month should not compete with context the user touched this morning as if both were equally alive.&lt;/p&gt;&#xA;&lt;p&gt;The feature Mem0 introduces is deliberately modest. It does not erase old memory, hide it behind a hard filter, or force developers to migrate stored data. Instead, it changes search ranking. Memories that have been retrieved recently get a boost; memories that have been idle for a while are dampened. If an old memory is still the best semantic match, it can still surface.&lt;/p&gt;</description>
    </item>
    <item>
      <title></title>
      <link>https://example.org/memos/2026/04/2026-04-18-afternoon-code/</link>
      <pubDate>Sat, 18 Apr 2026 11:15:00 +0800</pubDate>
      <guid>https://example.org/memos/2026/04/2026-04-18-afternoon-code/</guid>
      <description>&lt;p&gt;Spent the afternoon refining the memo card stack interaction. The key insight: the fan effect needs to feel physical but not chaotic.&lt;/p&gt;&#xA;&lt;p&gt;Current approach uses subtle rotation (±0.5deg) and vertical offsets. On mobile, rotation is too noisy, so it switches to pure vertical stacking with scale reduction.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Designing Quiet Software</title>
      <link>https://example.org/blog/2026/04/designing-quiet-software/</link>
      <pubDate>Sat, 18 Apr 2026 10:00:00 +0800</pubDate>
      <guid>https://example.org/blog/2026/04/designing-quiet-software/</guid>
      <description>&lt;p&gt;In a world of notification badges, infinite scroll, and dark patterns, quiet software feels like a radical act. It doesn&amp;rsquo;t demand your attention. It waits patiently for you to arrive, and when you do, it offers clarity rather than confusion.&lt;/p&gt;&#xA;&lt;h2 id=&#34;what-is-quiet-software&#34;&gt;What is quiet software?&lt;/h2&gt;&#xA;&lt;p&gt;Quiet software has a few defining characteristics:&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;&lt;strong&gt;It respects your time.&lt;/strong&gt; No onboarding tours you can&amp;rsquo;t skip. No &amp;ldquo;helpful&amp;rdquo; popups. No artificial urgency.&lt;/li&gt;&#xA;&lt;li&gt;&lt;strong&gt;It gets out of the way.&lt;/strong&gt; The interface is a container for your work, not the main event.&lt;/li&gt;&#xA;&lt;li&gt;&lt;strong&gt;It ages well.&lt;/strong&gt; Trends come and go, but quiet software relies on fundamentals: typography, spacing, clarity.&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;blockquote&gt;&#xA;&lt;p&gt;&amp;ldquo;The best design is the least design.&amp;rdquo; — Dieter Rams&lt;/p&gt;</description>
    </item>
    <item>
      <title></title>
      <link>https://example.org/memos/2026/04/2026-04-18-morning-thoughts/</link>
      <pubDate>Sat, 18 Apr 2026 08:30:00 +0800</pubDate>
      <guid>https://example.org/memos/2026/04/2026-04-18-morning-thoughts/</guid>
      <description>&lt;p&gt;The best designs are often the ones that subtract rather than add. I&amp;rsquo;ve been thinking about this a lot while working on the new portfolio site — every element needs to justify its existence.&lt;/p&gt;&#xA;&lt;p&gt;There&amp;rsquo;s a temptation to add features because you can, not because you should. Resisting that temptation is a skill.&lt;/p&gt;</description>
    </item>
    <item>
      <title></title>
      <link>https://example.org/memos/2026/04/2026-04-17-design-systems/</link>
      <pubDate>Fri, 17 Apr 2026 10:00:00 +0800</pubDate>
      <guid>https://example.org/memos/2026/04/2026-04-17-design-systems/</guid>
      <description>&lt;p&gt;Re-reading &lt;em&gt;The Elements of Typographic Style&lt;/em&gt; by Robert Bringhurst. Still the best book on typography after all these years.&lt;/p&gt;&#xA;&lt;blockquote&gt;&#xA;&lt;p&gt;&amp;ldquo;Typography exists to honor content.&amp;rdquo;&lt;/p&gt;&#xA;&lt;/blockquote&gt;&#xA;&lt;p&gt;Every time I return to this book, I find something new. Today&amp;rsquo;s insight: the importance of optical alignment over mathematical alignment. Sometimes things need to feel right more than they need to measure right.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Typography on the Web: A Practical Guide</title>
      <link>https://example.org/blog/2026/04/typography-on-the-web-a-practical-guide/</link>
      <pubDate>Fri, 10 Apr 2026 09:00:00 +0800</pubDate>
      <guid>https://example.org/blog/2026/04/typography-on-the-web-a-practical-guide/</guid>
      <description>&lt;p&gt;Good typography is invisible. When it&amp;rsquo;s done well, readers simply enjoy the content without thinking about the letters. When it&amp;rsquo;s done poorly, reading becomes a chore.&lt;/p&gt;&#xA;&lt;h2 id=&#34;the-basics&#34;&gt;The basics&lt;/h2&gt;&#xA;&lt;h3 id=&#34;measure&#34;&gt;Measure&lt;/h3&gt;&#xA;&lt;p&gt;The measure (line length) should be between 45 and 75 characters. I prefer around 65 characters for body text. Too wide and the eye loses its place; too narrow and reading feels choppy.&lt;/p&gt;&#xA;&lt;h3 id=&#34;line-height&#34;&gt;Line height&lt;/h3&gt;&#xA;&lt;p&gt;Body text typically needs a line height of 1.5 to 1.7. Headings can be tighter — around 1.2 to 1.3.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Design System Kit</title>
      <link>https://example.org/projects/design-system-kit/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://example.org/projects/design-system-kit/</guid>
      <description>&lt;p&gt;A lightweight design system starter that prioritizes pragmatism over completeness.&lt;/p&gt;&#xA;&lt;h2 id=&#34;philosophy&#34;&gt;Philosophy&lt;/h2&gt;&#xA;&lt;p&gt;Most design systems fail because they&amp;rsquo;re too ambitious. This kit starts small: tokens, a few core components, and clear documentation. Teams can extend it as needed rather than fighting against an opinionated framework.&lt;/p&gt;&#xA;&lt;h2 id=&#34;features&#34;&gt;Features&lt;/h2&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;CSS custom properties for theming&lt;/li&gt;&#xA;&lt;li&gt;Accessible React components&lt;/li&gt;&#xA;&lt;li&gt;Minimal dependencies&lt;/li&gt;&#xA;&lt;li&gt;Dark mode support out of the box&lt;/li&gt;&#xA;&lt;/ul&gt;</description>
    </item>
    <item>
      <title>Quiet Reader</title>
      <link>https://example.org/projects/quiet-reader/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://example.org/projects/quiet-reader/</guid>
      <description>&lt;p&gt;Quiet Reader is a reading app designed for focus. No social features. No sync conflicts. Just your books and articles, presented beautifully.&lt;/p&gt;&#xA;&lt;h2 id=&#34;problem&#34;&gt;Problem&lt;/h2&gt;&#xA;&lt;p&gt;Most reading apps are cluttered with features you don&amp;rsquo;t need: social sharing, achievement badges, algorithmic recommendations. For people who just want to read, this noise is exhausting.&lt;/p&gt;&#xA;&lt;h2 id=&#34;solution&#34;&gt;Solution&lt;/h2&gt;&#xA;&lt;p&gt;Quiet Reader strips away everything non-essential. The interface is deliberately minimal: a book cover, your reading position, and the text itself. Settings are limited to typography, spacing, and theme — the things that actually affect reading comfort.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
