What I do
Most of my work follows the same shape. Start with a repetitive operational task a team is doing by hand — sorting a Gmail inbox, responding to Google reviews, screening candidates, producing ad creative. Design the pipeline that automates it end to end: the integration at the source, the background jobs that process work asynchronously, the LLM layer that makes the judgment calls, and the dashboard that keeps an operator in the loop. Then do the unglamorous engineering that decides whether it survives in production — token refresh, rate-limit-safe concurrency, cost pre-filtering, batched writes, structured logging.
I build full-stack: TypeScript/Next.js and Python on the front, Postgres/Prisma and background-job queues underneath, and OpenAI, Anthropic, or Google models in the pipeline depending on the job. I care more about the architecture decisions than the framework names — why a Postgres-backed queue instead of a separate broker, when to run parallel versus throttled versus batch generation, where a deterministic rule should short-circuit the model entirely.
How I think about the work
The habit I trust most is restraint. On my CAD-intelligence startup, I deleted a working but more-sophisticated deterministic pipeline once I could show it didn't generalize — a system I can defend beats one that only looks finished. On an email classifier, I evaluated the cheaper batch API and rejected it because 24-hour latency was wrong for near-real-time inbox sorting. Documenting those trade-offs, and admitting where a system still degrades, is the part of the job I take most seriously.
I also keep numbers honest. Where I cite a benchmark, it's a documented internal figure, and I say so. I don't publish metrics I can't stand behind.
Principles
- I build around workflows, not model calls — mapping the user action, owned data, external API state, failure modes, and recovery path before the model is ever involved.
- Deterministic logic handles the obvious cases; the model is reserved for real ambiguity, and the hand-off between them stays inspectable.
- I engineer for throughput and cost: the cheapest model call is the one you avoid, so filtering and batching come before generation.
- I keep numbers honest — every benchmark cites its source, and I say plainly where a system still degrades.
