How I work
The toolchain is the practice.
I build through an agent-driven toolchain — local models for bulk work, frontier models for reasoning, preregistered behavioral tests for reliability, and a capability graph that tracks what's mature and what's rotting. Every page here was built that way.
opencode is my primary development surface — skills, MCP servers, and local model routing in one toolchain. This site was built and is maintained through it. Skills encode reusable workflows; the repo you're reading carries five of them (accessibility audits, agent visibility, INP/LCP optimization, tactile UI review, UI baselines). A separate capability graph tracks which capabilities are mature, decaying, or unused — 118 capabilities across 8 domains in the August 2026 snapshot.
Capability graph →Ollama runs locally for classification, extraction, summarization, and log scanning — anything where a smaller model's output can be checked cheaply. Frontier models get the reasoning work. The routing decision is explicit and re-tested rather than assumed: when a local model silently lost tool-calling, the fix was a test script that re-verifies each model, not a note to remember.
I test agents on whether they do the right thing on a real task, not on whether they produce a plausible response. The worked example is Fast Harm, Slow Repair: a preregistered eval protocol with typed case and state schemas, a deterministic scorer, and fixtures for both the recovered and unsafe-persistence paths. Preregistration and holdout manifest are committed before results, so scoring can't be tuned after the fact. The protocol is written and the scorer is tested; the source isn't public yet.
stims is a browser music visualizer running on WebGL — 3,500+ commits since October 2024, live at toil.fyi. It runs alongside a 34-service Docker stack on a Pi5 (media, CI, AI, monitoring, self-hosted apps). Not a hobby line — a sustained practice in shipping things that hold up in browsers, on real hardware, under real load.
toil.fyi →Why this matters
The method on the rest of this site — make claims answerable, track what backs them, design correction in — is not theoretical. I build and test it through this toolchain daily. Which is also why the counts above are dated snapshots with repos attached rather than round numbers: a page arguing that claims should be checkable is the wrong place to make one you can't check.