<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Posts on Yaklab</title><link>https://www.yaklab.org/posts/</link><description>Recent content in Posts on Yaklab</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><copyright>© 2026 James Ainslie</copyright><atom:link href="https://www.yaklab.org/posts/index.xml" rel="self" type="application/rss+xml"/><item><title>The Desired State of Things</title><link>https://www.yaklab.org/posts/desired-state-of-things/</link><pubDate>Wed, 08 Apr 2026 00:00:00 +0000</pubDate><guid>https://www.yaklab.org/posts/desired-state-of-things/</guid><description>&lt;p&gt;It&amp;rsquo;s 2am. Something is broken in production. An engineer SSHes into the box, finds the problem (a config file with the wrong value), fixes it, restarts the service, watches the metrics recover. Crisis averted. Everyone goes back to sleep.&lt;/p&gt;
&lt;p&gt;The Ansible playbook never learns about the fix. The next scheduled run either overwrites it or, more likely, doesn&amp;rsquo;t run at all because nobody wants to roll the dice on a Friday. Six months later, someone re-provisions the server from the same playbook and the old bug is back. Nobody connects the dots for another two weeks.&lt;/p&gt;</description></item><item><title>Golden Test Methodology (With a Twist)</title><link>https://www.yaklab.org/posts/golden-test-methodology/</link><pubDate>Sun, 01 Feb 2026 00:00:00 +0000</pubDate><guid>https://www.yaklab.org/posts/golden-test-methodology/</guid><description>&lt;p&gt;This document describes how we built comprehensive golden test coverage for gomdlint&amp;rsquo;s 55 lint rules — and how we used AI agents to do most of the work.&lt;/p&gt;
&lt;p&gt;Golden testing is a well-known technique: you capture the output of your program, commit it, and fail the build if the output ever changes unexpectedly. What makes this project interesting is the scale and the process. We needed ~170 carefully constructed markdown files, each designed to trigger exactly one rule while avoiding false positives from the other 54. Writing those files requires detailed knowledge of every rule&amp;rsquo;s behavior, its edge cases, and the dozen or so ways you can accidentally create a bad test input. That&amp;rsquo;s a lot of domain knowledge to hold in your head across 55 rules.&lt;/p&gt;</description></item><item><title>On Shaving Yaks</title><link>https://www.yaklab.org/posts/hello-world/</link><pubDate>Sat, 17 Jan 2026 00:00:00 +0000</pubDate><guid>https://www.yaklab.org/posts/hello-world/</guid><description>&lt;p&gt;We are inspired by great software and the possibilities it presents. We want to spend our lives making great software - which is why we launched this collaboration.&lt;/p&gt;
&lt;p&gt;The name comes from the glorious labor of &lt;em&gt;shaving the yak&lt;/em&gt;: those quiet, essential tasks that turn rough intent into reliable craft. The work that nobody celebrates but everyone depends on. The third-order prerequisite that must be solved before you can solve the second-order problem that unlocks the first-order goal.&lt;/p&gt;</description></item></channel></rss>