Work
My software career and AI work.
I bring what I've learned as an engineer, architect, and delivery lead to my AI projects. The examples below explain the decisions I made and link to the code and records so you can check the work.
Decisions in three projects
Software engineering · savviety-instinct
Testing the assumptions behind the code
A code-analysis tool needs accurate measurements. If the tests and implementation share the same assumptions, both can miss the same bug.
I checked the algorithms against independent implementations, property-based invariants, and adversarial parser fixtures. That's how I approach code written with AI: decide what correct means, then try to find where the code gets it wrong.
These tests found three bugs the original expectations missed. One external checker had the same blind spot as my code; a second checker disagreed and exposed it. The repo documents the defects and the checks that caught them.
Read savviety-instinct on GitHub
Architecture · kb
Keeping note capture working when the server is down
I need to be able to save notes when the search server or model service is down. Capturing a note shouldn't depend on the services needed to retrieve it later.
The capture commands write Markdown locally. A separate server indexes the notes in Qdrant, embeds and reranks them with Voyage AI, and answers questions with citations through an OpenAI-compatible model server such as oMLX. Saving a note doesn't need a network connection.
The tool works as a personal knowledge base today. The repo includes dependency health checks and a smoke-test runbook. MCP integration is documented as future work.
Read kb on GitHub
Delivery · opening-dojo
Building a chess trainer with AI agents
The chess trainer needed to work as a coherent application, with tests to check its behavior. To coordinate the agents, I also needed a clear scope and a definition of what each task had to deliver.
I designed the process and directed the work, starting with requirements and a plan. Agents wrote the implementation, which went through several rounds of review. I set the direction and decided what had to be true before I would accept the result.
The repo has 86 tests in CI. It also includes the product requirements document (PRD), execution plan, review records, links between requirements and tests, and a postmortem. You can read the delivery records alongside the code.
Read opening-dojo on GitHub