{"id":23702,"date":"2026-09-04T02:26:13","date_gmt":"2026-09-04T02:26:13","guid":{"rendered":"https:\/\/scannn.com\/the-harness-playbook-stencil\/"},"modified":"2026-09-04T02:26:13","modified_gmt":"2026-09-04T02:26:13","slug":"the-harness-playbook-stencil","status":"publish","type":"post","link":"https:\/\/scannn.com\/lv\/the-harness-playbook-stencil\/","title":{"rendered":"The Harness Playbook \u2014 Stencil"},"content":{"rendered":"\n
\n

Before anything else: a thank you. Hundreds of thousands of you have used omp, reported what broke, suggested what was missing, and shaped what it became. This post and omp\u00b2 itself exist because of you.<\/em><\/p>\n

Upon hearing about omp\u00b2, many of you jumped to ask, “but why?”<\/p>\n

A while loop around a fetch sounds simple, but there’s a reason OpenCode, Pi, OpenClaw and omp are all
\nconcurrently working on a complete refactor: this class of software did not exist before, and only by starting
\nwith the simple version, we could see the cracks to work towards a better one.<\/p>\n

Unavoidable complexity needs an owner. At the moment, the conservation of complexity<\/a>
\ntips toward extensions and users, making it impossible to write reliable software on top of omp or Pi. I can already hear
\nthe “whaaat, it is so simple and pleasant to extend.”<\/em> Give me a few chapters to change your mind.<\/p>\n

Dijkstra wrote that “simplicity is prerequisite for
\nreliability”<\/a>, and yet he is known for
\nalgorithmically solving pathfinding. Why not just brute force? He was not, at all, making the claim
\nwe now repeat as simple good, complex bad<\/strong>. The advice was to help implementers reason. We
\nshamefully use it to excuse the implementer from reasoning.<\/p>\n

Ousterhout gives the missing half in the notes of his Stanford lectures. He tells module writers to
\n“embrace
\nsuffering”<\/a>.
\nTake on hard problems, solve them completely, and make the result easy for everybody else to use.
\nPush complexity down into the module. Let a few implementers carry it instead of making every caller
\ncarry a smaller, slightly different copy.<\/p>\n

\n

I am sure many readers remember the wave of memes from the tweet comparing Claude Code to a game
\nengine. The comparison sounds far-fetched, but if you list the responsibilities of a harness, putting rendering aside, it does match quite well.<\/p>\n

It maintains an authoritative world, journals changes, runs untrusted actions, replicates state to
\nmultiple views, schedules actors, interprets commands, adapts incompatible protocols, and renders a
\nreal-time interface.<\/p>\n

Sounds familiar? It seems game engines have spent decades owning the same categories of complexity.<\/p>\n

What follows is both a postmortem and a playbook:<\/p>\n