Most software writing lives inside one layer. A frontend post, a database post, an LLM post. The work I keep coming back to happens between layers, where a decision in one place quietly changes the economics of another.
A GPS device ships with a protocol from 2011. The ingestion service normalizes it. The database stores positions at a resolution the product can afford. A rules engine decides which of those positions are interesting. Only then does a model get to reason about what happened. Move one boundary and the bill, the latency or the failure mode changes somewhere you were not looking.
That seam is where systems usually break, and it is the part I find most interesting. It is also why I am skeptical of architecture that starts with the model. A model is one component with a cost curve, a latency distribution and a failure mode. Treating it as the center of the system is how you get demos that cannot survive a Tuesday.
What I want to write about
- The engineering underneath agents: context budgets, evaluation, routing, and what to do when the model is confidently wrong.
- Real-time infrastructure that has to survive real fleets, not benchmark traffic.
- Developer tools that make the next feature easier than the last one.
- The unglamorous systems — billing, device lifecycle, accounting bridges — that turn a project into a business.
I do not have a publishing schedule. I have a list of things I keep explaining to people, and writing them down once is cheaper than explaining them twice.
If you want the short version of how I build: architecture before hype, AI where reasoning actually helps, and boring but debuggable over clever and unexplainable.