About
I build systems that use large language models: retrieval pipelines, evaluation harnesses, fine-tuning workflows, and the inference infrastructure underneath them. Most of it runs on hardware I own, which means I've had to care about the parts people usually abstract away, like GPU topology, throughput under real load, and what actually happens when a container comes back after a cold boot.
Before that I spent years building production software: multi-tenant platforms, iOS applications, payment systems, and internal tools that real businesses ran their operations on. That background is the reason I'm useful on AI work rather than adjacent to it. A model that works in a notebook and a model that works in a product are totally different problems, and I've shipped the second kind.
Right now I'm working on inference infrastructure and evaluation — running local models on my own hardware, building harnesses that measure whether a system actually improved rather than if it feels like it did, and red teaming LLM deployments for the failure modes that only show up under adversarial pressure. Most of what I learn from that ends up in the writing section.
How I work
- I build things to find out
- I learn a system by making something with it, not by reading about it. Most of what I know came from building the thing and watching where it broke.
- I don't trust results I can't reproduce
- Anything that only worked once didn't work. I'd rather find out my own result was wrong than have someone else find out later.
- I go to the source
- Documentation tells you what something is supposed to do. The code tells you what it does.
- Simpler usually wins
- Most problems I've solved got solved by removing something rather than adding to it.
- I finish
- The last stretch of a project is the unglamorous part, and it's the part that decides whether you have a product or a demo.