<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>AI on Sailer.Software</title>
    <link>https://sailer.software/tags/ai/</link>
    <description>Recent content in AI on Sailer.Software</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Sat, 07 Nov 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://sailer.software/tags/ai/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Docs Are Dead, Long Live Decisions</title>
      <link>https://sailer.software/2026/11/docs-are-dead-long-live-decisions/</link>
      <pubDate>Sat, 07 Nov 2026 00:00:00 +0000</pubDate>
      <guid>https://sailer.software/2026/11/docs-are-dead-long-live-decisions/</guid>
      <description>&lt;p&gt;Code is cheap now, and so is documentation. And still I often face outdated, useless technical documentation in nearly every project I encounter. Either it is solely AI-written and therefore more or less just a description of the status quo. Or it is handwritten / AI-supported and therefore outdated (and most likely still just a description of the status quo).&lt;/p&gt;&#xA;&lt;p&gt;But there&amp;rsquo;s no point in documenting the status quo anymore. When I want to understand a project&amp;rsquo;s architecture, coding standards, or whatever, I don&amp;rsquo;t open the docs anymore. I open my coding harness, point it at the code and get a more precise answer than any documentation could give. A good harness also knows me after working with it for a while: how senior I am and how I think about software. So it explains things at my level, far better than a static page maintained by whoever drew the short straw this quarter. Sure, juniors may need a few starter questions, but an onboarding skill covers that easily.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
