Build Practice
I run the method I argue for.
I build through an agent-driven toolchain — local models for bulk work, frontier models for reasoning, preregistered behavioral tests for reliability, and Ambit, a capability graph that keeps track of what the whole system can do and what it may do. Every page here was built that way.
Agent-driven development
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 seven of them (accessibility audits, agent visibility, adversarial claim review, evidence custody, INP/LCP optimization, tactile UI review, UI baselines).
Capability accounting
Ambit reads this stack and answers what it can actually do — which capabilities are reached, what is one dependency away, what is decaying, and what breaks if a given piece disappears. It keeps authority separate from capability, so can and may stay different questions, and records the frontier over time. Over its MCP server, the agents working in this repo can ask about their own environment — what they can reach, what needs approval, what a change would break — instead of rediscovering it every session.
What Ambit is →Local model routing
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.
Behavioral agent evaluation
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 evaluation of what happens after a system is wrong — how far the error propagates and whether the correction reaches everything it touched — with typed case and state schemas, a deterministic scorer, and fixtures for both the recovered and unsafe-persistence paths.
The evaluation plan is committed before results, so scoring can't be tuned after the fact. The protocol is written and the scorer is tested; the source publishes with the results.
Shipping outside the resume
stims is a browser music visualizer running on WebGL, live at toil.fyi — audio-reactive software built around user control of the sensory experience, in active development since October 2024. It runs alongside a self-hosted Docker stack on a Pi5 (media, CI, AI, monitoring). Neither is a demo: the visualizer has to hold up across browsers and GPUs, and the stack has to keep running on one small machine.
toil.fyi →Why this matters
The method on the rest of this site — make claims verifiable, track what backs them, design correction in — is what this toolchain runs on. Every claim above has a public repo behind it.