Skip to content

Sunday, May 17, 2026

The loop, not the tools

Jan Peter Wiersma
the-loop-not-the-tools.png

Four years of building strackt has been four years of working on the loop — even when I thought I was working on the product. Switching from Ansible to NixOS looked like picking a better tool; it was really me trying to get a rebuild I could trust. Adopting ZFS looked like picking up snapshots; it was really me trying to be able to move forward without holding my breath. Each switch was loop work in disguise. And the loop work itself has changed quite a lot since then.

The loop is plan, ship, test, learn — nothing novel about that. What I'm landing on lately is how much of the leverage actually sits inside the loop, and how the loop work changes shape over time. For years it looked like swapping tools and refining code: bigger pivots, longer rewrites, most of my hours on the parts that produce the product directly. Tools matter, and that work matters; but the same tool inside a tighter loop produces a better product, not just a faster one. NixOS on its own isn't the unlock; NixOS with rebuilds I trust is. ZFS on its own isn't the unlock; ZFS with the willingness to roll forward is.

The loop work isn't in the tools anymore; it's about where my time goes inside the loop itself. The plan-build-test rhythm I'm working on right now sits inside an agentic AI workflow. Claude Code and Codex write most of the code for me now, which means the place my hours land has shifted hard. Most of it sits on the plan now, and on the stuff around the plan — the brief, the framing, the edges, the explicit references that get them to come back with code I won't have to argue with later. Review and testing take up what's left.

What I'm learning is that the time on the plan is pretty much equal to the quality of the outcome. A good plan means they code it the way I would have; that code holds up under tests because the plan already thought about the edges; the testing pass becomes a confirmation rather than a hunt. The more I invest in the part at the front, the less work the rest of the loop has to do — fewer review rounds, fewer arguments with the diff, fewer surprises in testing...

Four years in, the work I'm doing on the loop doesn't look like it used to. Sharpen the loop and the product gets better, not just faster. That's the part I keep underestimating; and the part I'm slowly learning to invest in more.