This is a curated collection of software that I've written that I think is worth sharing. It ranges from deployed personal infrastructure to unfinished architectural experiments. In my personal work, I care about small systems that one person can understand, direct control over important data and infrastructure, and software that remains runnable for the long haul.
The hard part of software is usually legibility and maintenance, not cleverness or framework selection. I do my best to: 1) write as little code as possible; 2) import as little code as possible; and 3) rely on mature and tested code and protocols when I do rely on it.
I try to stay focused on the problem or experiment at hand, and err on the side of "this will still work or compile if I try to use or modify it in 10 years".
Current Systems and Agent Work
Projects and explorations around self-hosted AI tooling and the application infrastructure that makes it useful. Some are functional systems in regular use; others are deliberately early architectural experiments.
A lightweight, self-hosted private network that one person can reasonably understand.
cord began before my AI work as a way to learn WireGuard and peer-to-peer networking by rebuilding some of the ideas behind innernet in Go. It now includes server and client daemons, peer onboarding, SQLite-backed desired state, direct peer-to-peer traffic, and peer-discovered endpoints. I have used it across machines on my home network, a public Debian server, and cloud VPSs.
Self-hosted AI tooling and remote agent environments made the project newly relevant. My compute, development sandboxes, agents, and deployment targets increasingly live across different physical networks, but I want them to behave like one private computing environment.
Direction and open questions
The working network is not yet the whole idea. The larger question is access topology: which machines and agents should be able to discover or reach one another, and how those permissions should be expressed as the network grows. Group-based visibility is the current direction, but it should be understood as ongoing design work rather than a finished authorization system.
A local, permissioned cache of private data for agents, beginning with email.
confidant runs as a local daemon that incrementally synchronizes email into a searchable SQLite database and exposes it through access-controlled CLI, HTTP, and MCP interfaces. This keeps live account credentials away from agents and makes it possible to use private mail context without sending the underlying data through a cloud model.
The first part of the experiment works end to end. I have used Qwen and Gemma models on a Strix Halo server through Jan, OpenChamber, and Bionic to search and read the synchronized mailbox, answer questions across messages, and generate summaries.
Direction and open questions
Email was the concrete starting point, but the architecture naturally raises a larger question: what would it take to maintain one local, permissioned cache of the private data that agents could make useful? Calendar, contacts, and financial data are plausible next sources. I also want to test the access model across multiple data sources and agent keys rather than treating the current single-user deployment as proof of a complete permission system.
A cross-harness system for making generated Go code look and behave like the code I would write myself.
The project grew from a personal Go style guide I began maintaining once agentic coding became genuinely useful. It has evolved into progressively disclosed engineering guidance covering application architecture, services, persistence, APIs, command-line tools, servers, and web interfaces. I use it across all of my current Go projects with both self-hosted and frontier models.
The practical result is fewer rounds of correction, easier context transfer, and much stronger architectural consistency. When generated code already follows familiar conventions, actual mistakes and strange decisions stand out instead of being buried beneath stylistic noise.
Direction and open questions
I have also built a feedback loop that extracts lessons from project sessions, evaluates them against the existing guidance, and incorporates approved changes into later work. I am interested in how this can move beyond static instructions toward structured, adaptable contexts that agents can select or eventually assemble for the work in front of them.
Two attempts to understand where deterministic orchestration should end and agent discretion should begin.
composer was the earlier experiment. It represents human and AI knowledge work as a durable graph of steps, artifacts, branches, retries, and audit history. It is not an end-to-end usable product; its value was in working through how these workflows might be represented and executed reliably.
copilot is the newer, agentic version of the question. It has a small functional loop that runs against self-hosted models and lets them choose from a limited set of built-in actions. The architecture treats tools, skills, and bounded sub-agents as variations of the same idea: actions available to a cognition delegate, whose expressed intents are executed by the harness.
Direction and open questions
These projects are deliberately exploratory. I am still working through how actions should be designed, how capabilities should be granted, where durable state belongs, and whether agents might eventually construct parts of their own harnesses at runtime. The code is a way to make those philosophical questions concrete enough to test.
Application Prototypes
Graphical UI applications and prototypes that I'm actively working on.
A personal nutrition and weight-tracking tool designed through daily use.
I have been slowly building and expanding coach over the course of 2026, and use it every day. The experiment is as much about the development process as the application itself: how quickly can a personal tool evolve when noticing friction, changing the implementation, deploying it, and living with the result are all part of one continuous loop? It is currently on version 19 after considerable iteration to its information design and interaction model.
coach is a compact, single-binary Go application with a mobile-first server-rendered interface, HTMX interactions, SQLite storage, and server-generated charts. It tracks meals, calorie plans, body measurements, and trends without requiring a frontend build system or external services.
Short mobile walkthrough using generated example data.
A spatial work surface for drafting and reorganizing documents, keeping linear text underneath.
columns explores a document editor where one Markdown source can be split into movable blocks across a pannable two-dimensional canvas, then returned to a conventional sequential document view. Annotations live as separate data layers over character ranges, so editorial notes and spatial arrangement do not have to become part of the document itself.
The initial (and open) design question is how text interfaces can evolve to support more complex editing patterns enabled by language models. Blocks, selections, spatial relationships, and annotation layers could become structured inputs to AI systems rather than forcing every editing intent through a chat box or an undifferentiated document prompt.
Short walkthrough of canvas organization, block movement, document view, and annotations.
Utilities and Small Experiments
Smaller systems, libraries, and experiments that support my other work or pursue a tightly bounded technical question.
A collection of narrow packages for recurring application concerns such as command trees, environments, API clients, metrics, and reporting. The packages work together with Go Agent Skills so agents can reuse established implementations instead of repeatedly inventing them.
A compact identity service for small, server-rendered applications.
consent began as a tightly bounded exercise in understanding OAuth by rebuilding the portion I needed for small browser-based applications. It now includes authentication, token and session management, roles and organization access, an API and CLI, a server-rendered administration interface, and reusable Go packages for application integration.
The service is deployed on the public internet and has been integrated into small personal applications. The goal is not to replace general-purpose identity platforms; it is to provide understandable infrastructure for a collection of small, community-scale tools without creating a service that needs its own team to operate.
An experiment in defining and extracting structured data from ordinary HTML through reusable CSS-selector-based schemas, with minimal extra markup for page authors.
A small rendering language for composing plain-text source files into a render tree. I use it to share document structures, query page collections, and produce intermediate SAM across my websites.
My implementation of Semantic Authoring Markdown, an alternative syntax for writing semantic XML and HTML by hand. collect renders into SAM, which then produces the final pages on this site.
A script and kernel patch for loading the Radeon VBIOS on a 2006 MacBook Pro under modern Linux. It automated the recurring work needed to keep an otherwise unsupported machine useful.
A dependency-free command-line parser supporting subcommands, operands, short and long options, and generated help. I built it to get the features I needed without bringing a large dependency tree into small Rust programs.
Programming Language Research
Coalescent Computer was a 2022–2023 research project about content-addressed programs, symbols, and computing environments. The complete project has its own research site.
An experimental content-addressed, concatenative assembly language. co assembles programs to the COINS instruction set and manages a local symbol library whose names resolve to immutable program fragments.
A stack-based virtual machine for COINS programs, with an extensible virtual-device protocol over Unix sockets. Its primary purpose is executing programs written in co while keeping devices outside the core runtime.
The shared Coalescent Instruction Set library and living specification. It defines a compact bytecode that preserves enough assembly semantics for valid programs to move losslessly between source and bytecode representations.