<?xml version="1.0" encoding="UTF-8"?><rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>project &amp;mdash; Nat Knight</title>
    <link>http://natknight.xyz/tag:project</link>
    <description>Reflections, diversions, and opinions from a progressive ex-physicist programmer dad with a sore back.</description>
    <pubDate>Fri, 16 Oct 2026 16:32:21 -0700</pubDate>
    <item>
      <title>Self-hosting a Software Factory: Part 1</title>
      <link>http://natknight.xyz/self-hosting-a-software-factory-part-1</link>
      <description>&lt;![CDATA[#project #selfhosting #llms #agents&#xA;&#xA;One of the ways that folks are leveraging LLM-powered agents to do software development is the &#34;software factory&#34; (or [&#34;software dark factory&#34;]) pattern, where the LLMs write all the code and the humans aren&#39;t allowed to even review it.&#xA;&#xA;[&#34;software dark factory&#34;]: https://www.danshapiro.com/blog/2026/01/the-five-levels-from-spicy-autocomplete-to-the-software-factory/&#xA;&#xA;Apparently this works, though you need a good way to verify your product. I&#39;m a little skeptical that it&#39;s the best way to use these tools, but it&#39;s an interesting idea, so I&#39;m going to try to build one for myself.&#xA;&#xA;!--more--&#xA;&#xA;The Project&#xA;&#xA;I&#39;m cheating a little bit by picking a project that&#39;s embarrassingly easy to verify: a new interpreter for an extant programming language.&#xA;&#xA;The programming language is called [EYG] and has many interesting and desirable properties:&#xA;&#xA;functional style + a sound type system&#xA;immutable dependencies&#xA;deterministic execution&#xA;the editor tooling and compiler are independent of the runtime (so I don&#39;t have to implement them!)&#xA;&#xA;[EYG]: https://eyg.run&#xA;&#xA;Its only annoying drawback is that its interpreter is in JavaScript (compiled from Gleam, but running on Node). I&#39;d really prefer a native interpreter, or better still, a Rust library that can execute EYG code.&#xA;&#xA;Lucky for me, I have:&#xA;&#xA;access to LLMs that can cheaply churn out code, and&#xA;an &#34;oracle&#34; that can see if my project is working properly, i.e. the existing EYG interpreter.&#xA;&#xA;So that&#39;s the project: a Rust library + easily deployable binary that can interpret EYG code.&#xA;&#xA;The Rules&#xA;&#xA;The project will be split into two repos, each with different rules:&#xA;&#xA;eyg-rs is the actual interpreter/library:&#xA;&#xA;I&#39;m not allowed to write or review code here. I can peek in occasionally for quality control, but that should be the exception.&#xA;The work needs to be mediated by an automated system, not me manually driving an agent.&#xA;The code needs to end up correct, efficient, and clean.&#xA;All agent-driven work must happen in a sandbox on my own hardware.&#xA;&#xA;I&#39;m trying to learn about the factory pattern, so I actually have to build one. I could almost certainly just point Claude Code at the EYG spec and have it converge on a working interpreter, but that wouldn&#39;t teach me anything about the system that&#39;s managing the work.&#xA;&#xA;Keeping it sandboxed is a precaution against an agent hosing my home lab.&#xA;&#xA;Figuring out how to get it clean and efficient is, of course, part of the challenge.&#xA;&#xA;eyg-rs-factory is the system that tracks work, manages the agent, and validates the final product:&#xA;&#xA;I can read and write code here, including using agents to do it for me.&#xA;I can use my tools in whatever mode gets the job done.&#xA;This code can be arbitrarily janky as long as it works.&#xA;&#xA;This is where the learning happens, so it gets to be hands-on and sloppy if that&#39;s what it takes.&#xA;&#xA;I&#39;ve started building it, but it&#39;s not working yet. I&#39;ll let you know how it goes once it&#39;s closing tickets!]]&gt;</description>
      <content:encoded><![CDATA[<p><a href="http://natknight.xyz/tag:project" class="hashtag"><span>#</span><span class="p-category">project</span></a> <a href="http://natknight.xyz/tag:selfhosting" class="hashtag"><span>#</span><span class="p-category">selfhosting</span></a> <a href="http://natknight.xyz/tag:llms" class="hashtag"><span>#</span><span class="p-category">llms</span></a> <a href="http://natknight.xyz/tag:agents" class="hashtag"><span>#</span><span class="p-category">agents</span></a></p>

<p>One of the ways that folks are leveraging LLM-powered agents to do software development is the “software factory” (or <a href="https://www.danshapiro.com/blog/2026/01/the-five-levels-from-spicy-autocomplete-to-the-software-factory/">“software dark factory”</a>) pattern, where the LLMs write all the code and the humans aren&#39;t allowed to even <em>review</em> it.</p>

<p>Apparently this works, though you need a good way to verify your product. I&#39;m <a href="https://natknight.xyz/link-how-strongdms-ai-team-build-serious-software-without-even-looking-at-the">a little skeptical</a> that it&#39;s the best way to use these tools, but it&#39;s an interesting idea, so I&#39;m going to try to build one for myself.</p>



<h2 id="the-project" id="the-project">The Project</h2>

<p>I&#39;m cheating a little bit by picking a project that&#39;s embarrassingly easy to verify: a new interpreter for an extant programming language.</p>

<p>The programming language is called <a href="https://eyg.run">EYG</a> and has many interesting and desirable properties:</p>
<ul><li>functional style + a sound type system</li>
<li>immutable dependencies</li>
<li>deterministic execution</li>
<li>the editor tooling and compiler are independent of the runtime (so I don&#39;t have to implement them!)</li></ul>

<p>Its only annoying drawback is that its interpreter is in JavaScript (compiled from Gleam, but running on Node). I&#39;d really prefer a native interpreter, or better still, a Rust library that can execute EYG code.</p>

<p>Lucky for me, I have:</p>
<ul><li>access to LLMs that can cheaply churn out code, and</li>
<li>an “oracle” that can see if my project is working properly, i.e. the existing EYG interpreter.</li></ul>

<p>So that&#39;s the project: a Rust library + easily deployable binary that can interpret EYG code.</p>

<h2 id="the-rules" id="the-rules">The Rules</h2>

<p>The project will be split into two repos, each with different rules:</p>

<p><a href="https://github.com/nathanielknight/eyg-rs">eyg-rs</a> is the actual interpreter/library:</p>
<ul><li>I&#39;m <strong>not allowed to write or review code</strong> here. I can peek in occasionally for quality control, but that should be the exception.</li>
<li>The work needs to be mediated by an <strong>automated system</strong>, not me manually driving an agent.</li>
<li>The code needs to end up <strong>correct, efficient, and clean</strong>.</li>
<li>All agent-driven work must happen <strong>in a sandbox</strong> on my own hardware.</li></ul>

<p>I&#39;m trying to learn about the factory pattern, so I actually have to <em>build</em> one. I could almost certainly just point Claude Code at the EYG spec and have it converge on a working interpreter, but that wouldn&#39;t teach me anything about the system that&#39;s managing the work.</p>

<p>Keeping it sandboxed is a precaution against an agent hosing my home lab.</p>

<p>Figuring out how to get it clean and efficient is, of course, part of the challenge.</p>

<p><a href="https://github.com/nathanielknight/eyg-rs-factory">eyg-rs-factory</a> is the system that tracks work, manages the agent, and validates the final product:</p>
<ul><li>I can read and write code here, including using agents to do it for me.</li>
<li>I can use my tools in whatever mode gets the job done.</li>
<li>This code can be <strong>arbitrarily janky</strong> as long as it works.</li></ul>

<p>This is where the learning happens, so it gets to be hands-on and sloppy if that&#39;s what it takes.</p>

<p>I&#39;ve started building it, but it&#39;s not working yet. I&#39;ll let you know how it goes once it&#39;s closing tickets!</p>
]]></content:encoded>
      <guid>http://natknight.xyz/self-hosting-a-software-factory-part-1</guid>
      <pubDate>Fri, 16 Oct 2026 21:10:18 +0000</pubDate>
    </item>
  </channel>
</rss>