<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
  <title>Red Line Digital, field notes</title>
  <subtitle>Dated lessons from building software in the open.</subtitle>
  <link rel="self" href="https://redlinedigital.dev/feed.xml" />
  <link href="https://redlinedigital.dev/notes/" />
  <id>https://redlinedigital.dev/notes/</id>
  <updated>2026-07-01T00:00:00Z</updated>
  <author>
    <name>Red Line Digital</name>
  </author>

  <entry>
    <title>Cheap models do the typing, expensive models do the judging</title>
    <link href="https://redlinedigital.dev/notes/#2026-07-01-route-models-by-judgment" />
    <id>https://redlinedigital.dev/notes/#2026-07-01-route-models-by-judgment</id>
    <published>2026-07-01T00:00:00Z</published>
    <updated>2026-07-01T00:00:00Z</updated>
    <summary>Every step in a batch now gets a model and an effort level before it gets a worker: mechanical edits run on a fast, cheap model, design and public copy run on the strongest one we have. We wrote that routing into the project rules after learning each model's strengths the expensive way, including that a worker with no model assigned quietly inherits the priciest default. Efficacy is measured in the build log as cost per batch: the first routed batch ran 23 workers for roughly a third of what a 7-worker, top-model pass had cost the day before, and the log keeps both numbers so the next batch has a baseline.</summary>
  </entry>

  <entry>
    <title>Every plan gets attacked before it gets built</title>
    <link href="https://redlinedigital.dev/notes/#2026-06-19-red-team-plus-referee" />
    <id>https://redlinedigital.dev/notes/#2026-06-19-red-team-plus-referee</id>
    <published>2026-06-19T00:00:00Z</published>
    <updated>2026-06-19T00:00:00Z</updated>
    <summary>Before we execute a plan, critic agents try to tear it apart, and a separate referee rules on every finding against the project's own written rules: keep, modify, or throw out. The referee exists because critics flag everything, and most of it is noise. We keep score on the process itself too: every time a recommendation flips after we question it, the flip goes in a log with a root-cause tag, and three of the same tag forces a rule change. That log has hardened our rules twice so far; the second time taught us that adding more prose does not change behavior, a forcing question asked at the moment of the decision does.</summary>
  </entry>

  <entry>
    <title>A lesson has to survive three audits before we trust it</title>
    <link href="https://redlinedigital.dev/notes/#2026-05-31-lessons-earn-promotion" />
    <id>https://redlinedigital.dev/notes/#2026-05-31-lessons-earn-promotion</id>
    <published>2026-05-31T00:00:00Z</published>
    <updated>2026-05-31T00:00:00Z</updated>
    <summary>When something we learn seems worth keeping, it is written into the project's live-state file first, not into permanent memory. Every session close re-audits that list: a lesson that still holds earns a tally, and one that turned out wrong dies right there. Promotion to permanent memory has to pass three filters: it survived three audits, it generalizes beyond the current project, and it can be stated as a one-line rule. The measure is built into the process, because a bad lesson never reaches three, and memory only accumulates rules that kept proving true.</summary>
  </entry>

</feed>
