Writing

A weekend each

Building systems software by directing language models.

The honest version of my portfolio: I didn't write most of it by hand. I built it with language models — frontier and local, much of it with Claude Opus — and the collaboration is the actual subject, not a disclaimer at the bottom.

That deserves unpacking, because "built with AI" usually means one of two things: someone autocompleted their boilerplate, or someone generated a thing they couldn't have written and can't explain. This is neither. Each of these systems — a streamed-tile globe, an articulated physics solver, an IDE that renders its own text in C — was scoped, structured, and verified by me, and implemented in tight collaboration with a model. Each took about a weekend.

What changed isn't that the code writes itself. It's the division of labor. My job moved up a level: I decide what the thing is, where its boundaries are, and how I'll know it's correct. The model does the laborious middle. The interesting engineering is in the seams between those.

Components, because the model needs boundaries too

I think in components — a pointable function with a boundary, not a bundle called an "engine." I always have. What surprised me is that the same discipline that keeps software composable also makes a model dramatically more effective. A well-bounded component is a task a model can actually complete: small enough to hold, with a clear contract at its edges. Hand a model "build the renderer" and you get mush; hand it "this function takes a heightfield sample and a convention and returns a normal" and you get something you can drop in and check. The component model does double duty — it's how the software stays clean, and how the model's output stays good.

Guidance by principle, not micromanagement

I don't write the model line-by-line. I give it the principle and the boundary and let it work — then I check. Camera-relative doubles, because we're at planetary scale and float won't hold. The heightmap function stays pure; the physics and the mesher both call it. State the why, fix the convention, and a capable model fills the middle correctly far more often than not. When it doesn't, the why is what lets it correct itself.

The real trick: oracles

The part that makes this produce quality rather than plausible-looking code is verification — and the best verification is the kind the model can run against itself. Wherever I can, I build an oracle: something that answers "is this right?" mechanically, and put it in the loop. A GLSL compiler is an oracle — the model writes a shader, it fails, the error goes back, it fixes it, until it compiles. A rendered frame is an oracle — capture it, reduce it to a number, and a flicker or a regression becomes a value the loop can see. A headless test is an oracle. With one in place, the iteration loop tightens until the model converges on something that actually works, and I'm reviewing an outcome instead of babysitting a process.

Where no cheap oracle exists — does it look right? — that stays my job, and I keep that loop tight too: live knobs, instant feedback, no screenshot-and-guess. And isolation is what makes every loop tight. The moment each system got its own harness — a native build that rasterizes to a PNG, a headless runner, a single embeddable page — the gap between what I meant and what the model produced collapsed, and the work sped up by an order of magnitude.

Frontier and local, scoped to the task

Not every task wants the same model. The hard reasoning — architecture, a tricky solver, a subtle bug — goes to a frontier model. The laborious-but-not-complex work — scaffolding, a mechanical refactor, a first draft of a file — a local 7B does at lightspeed, for free, on my own machine. Scoping the model to the task is itself part of the design.

Performance as a side effect of building it right

People assume model-written code is bloated. The opposite happened. Each live demo on my work page is a complete C/WASM application between 66 and 212 kB — smaller than a screenshot of it — and none is even compiled with aggressive optimization. That speed isn't from tuning. It's from design: the right data layout, the right boundaries, a principle held consistently. You get close to as-good-as-possible for nearly free when the structure is right — and the structure is exactly what a human directing by principle is responsible for.

Why it works

The thing that makes the direction effective is the domain knowledge. I can scope a graphics problem, guide it by the right principle, and recognize a wrong answer because I've spent fifteen years on the low-level end. The model isn't a replacement for that; it's a multiplier on it. Take the judgment away and the loop produces confident nonsense. Keep it, and a weekend is enough to build something real.

My work page is the evidence. Every piece is also a small experiment in this method.