Making the boring infrastructure dependable so the interesting stuff can survive contact with reality.

Former USAF Civil Engineer and rehabilitation counselor. These days I spend a probably unreasonable amount of time building software, tools, simulations, and whatever other rabbit hole seems interesting enough to wander into.

Most of my work lives somewhere around developer tooling, AI-assisted engineering, game systems, audio/DSP, and figuring out how to make complicated things less fragile.

A tool-discipline system for AI coding agents.

The basic idea is pretty simple: let the AI move fast, but don't let "it seems to work" become the engineering standard. Scope gets constrained, important checks stay deterministic, and the computer does the boring verification work whenever possible.

A persistent living-world simulation and game engine with autonomous characters, procedural skills and systems, weather, disasters, crafting, magic, and eventually multiplayer.

One of the stranger goals is letting a player take over an NPC, play that character for a while, then log out and hand the character back to the simulation without the world stopping to wait for them.

Mastering, psychoacoustic analysis, encoding, restoration, verification, and assorted ways of turning perfectly good computers into space heaters.

Some of the public work:

• CUETools 2026 - CD ripping, verification, repair, conversion, and reproducible Windows releases.
• CUETools for Linux - bringing the same verification and repair workflow to a native Linux desktop application.
• LAME v4 - exploring measurable MP3 quality improvements, bit-exact multithreading, and modernizing the build infrastructure.

Plan broadly. Build narrowly. Test reality.

I like ambitious systems, but I don't like ambitious commits.

Small changes are easier to inspect, easier to test, easier to undo, and much less likely to hide three unrelated problems under one impressive-looking result.

I use AI heavily. It does not get diplomatic immunity.

Generated code still has to build. Tests still have to pass. Runtime behavior still has to be checked. Side effects still matter. And if nobody can explain how the thing works six months later, "the AI wrote it" isn't much of a maintenance strategy.

Civil engineering burned this into me early.

A correct drawing or passing calculation doesn't automatically mean the structure is safe. You still need to know whether the instruments were calibrated, whether the assumptions match reality, what loads were actually considered, what the tolerances are, and whether what got built in the field resembles what everybody thought they were building.

Later, rehabilitation counseling taught me basically the same lesson with much squishier equipment. 😝

An assessment can be useful. A treatment plan can be useful. A theory can be useful. None of them replaces listening to the person in front of you, understanding the context, checking your assumptions, or noticing whether what you're doing is actually helping.

Software isn't special.

A green build is evidence. A passing test is evidence. A successful exit code is evidence. A very confident AI telling you everything is fixed is also evidence, although possibly evidence of something else entirely.

None of those, by themselves, prove that the real-world outcome is correct.

That's what I mean by tool discipline. Know what the tool actually measured. Know what it didn't. Constrain the blast radius. Preserve things you don't own. Make important assumptions visible. Then check the result somewhere outside the tool that produced it.

AI mostly changes the speed and scale of the problem.

One bad assumption can now become 40 files, 6,000 lines of code, and a cheerful summary explaining how successfully everything was completed.

I'd rather build systems that let AI do more while making that kind of failure harder to hide.