I am a software engineer and architect. Much of my career has been consulting, which meant moving between clients, domains, and systems more often than a single product job would have required. My deepest implementation background is C# and .NET, though consulting rarely left me in one stack for long, and a good deal of the work has been in other languages and on other platforms.

I stay close to the implementation. Architecture is more useful to me when I can follow a decision into the code that has to honor it, since a boundary that looks clean in a diagram is not the same thing as a boundary that survives being built. Much of what I have been building recently involves applied AI: AI-assisted software engineering, the tooling around it, and the question of which parts of a workflow should be decided by a model and which should be decided by software. Some of that work is public. Some of it is local tooling such as Reeve, which I use to keep architectural decisions and review gates explicit while AI handles more of the implementation.

This page is a short overview of what I build. The rest of the site is a personal blog and covers other things.

Selected systems

aimesh

aimesh grew out of a habit rather than a plan. I did not want the model that produced an artifact to be the only model deciding whether the artifact was any good, so I started handing work to a second provider and comparing what came back. That part was easy. The harder part was everything I kept deciding by hand each time: which model actually ran, what a reviewer is allowed to modify, what happens when an adapter fails, and who gets to say that two reviewers agree.

aimesh is a Go implementation of those rules. It orchestrates review and exploration across multiple providers, keeps reviewers in isolated read-only copies of the workspace while the host retains write authority, reports model identity at the strength the available evidence supports rather than asserting it, and maps failures into a defined halt taxonomy instead of continuing down some other path. It exposes a CLI along with MCP and ACP interfaces, because the caller is increasingly an agent rather than me. An earlier Claude Code command of mine, cross-ai-review, covered a narrower version of the same problem and is where several of these rules first got written down.

aikit

aikit is a Rust CLI and MCP server for the mechanical parts of working in a repository: recording an anchor before a batch of work, reporting what changed since that anchor, assembling bounded review bundles, and validating and running repo-local scripts with a run record. It calls no AI providers, performs no network operations, and makes no autonomous decisions.

That restriction is the interesting part rather than a limitation I have not gotten around to lifting. When an agent needs to know which files a session touched, or a reviewer needs the actual change set instead of a remembered one, the answer should come from something deterministic. aikit is a tool an agent uses, not an agent.

outpost

outpost is a file-RPC bridge for executing work on hosts where the agent cannot natively run. A responder on the target host polls a shared directory for jobs, runs them locally, and writes the results back to the same directory, so any filesystem both sides can see is enough of a transport. There is no listening daemon, no open port, and no SSH session to arrange. It came out of a real constraint on a project where the environment I was building for could not run the agent I was building with.

Unsolve It

Unsolve It is a Fieldcraft Group product built with Phoenix, LiveView, Ecto, and Postgres. It is not an AI product. The only place a model is involved is moderation of display names and uploaded images, and how narrow that boundary is says more about the engineering than the feature does.

The two moderation paths deliberately behave differently under uncertainty. An uncertain display name is rejected, because the person is right there and can pick another one. An uncertain image is queued for human review instead, since discarding someone’s upload on a maybe is the worse outcome. A deterministic blocklist runs before the model rather than after it, the provider chain is swappable, and total provider failure has defined fail-closed behavior instead of whatever would have happened by accident. Moderation decisions, audit records, service health, and spend are all monitored.

Product details are on the Fieldcraft page, which currently lists it as not yet available.

Selected writing

A few posts that cover most of how I currently think about applied AI:

Elsewhere

Public code is at github.com/Tim-Butterfield, and my professional background is on LinkedIn.