Build

I build systems, and I sweat how they hold up.

Research tells me what's worth building; engineering decides whether it survives contact with reality. This is how I work, what I optimize for, and the technical ground I stand on.

Default stack
Python · PyTorch · TypeScript
Works well
Solo & on a team
Bias
Ship, measure, iterate

Principles I build by

Six rules of thumb
01

Make it work, then make it honest

A working prototype beats a perfect plan. But before it ships, it has to be honest about what it doesn't know.

02

The interface is the system

Whoever uses the output is part of the design. If they can't act on it, the model didn't ship — it just ran.

03

Measure before you optimize

No baseline, no progress. I write the evaluation before I fall in love with an approach.

04

Small, reversible steps

I'd rather ship ten changes I can roll back than one I can't. Velocity comes from safety, not recklessness.

05

Write it down

A decision no one can reconstruct is a bug waiting to happen. I document the why, not just the what.

06

Strong opinions, held loosely

I commit hard to a direction and abandon it the moment the data disagrees. Ego is expensive.

How I work

From question to shipped

01

Frame the real problem

Talk to whoever will use it. Most of the work is figuring out what's actually being asked before writing a line of code.

02

Build the dumbest thing that could work

A baseline I can beat is worth more than a sophisticated model I can't explain. Start simple, on purpose.

03

Instrument everything

If I can't see what the system is doing, I can't trust it. Logging and evaluation come before the clever part.

04

Ship, watch, iterate

Real feedback beats imagined edge cases. I get it in front of someone early and let reality set the priorities.

Current focus

Active now
Building

A legible agent prototype, end to end

Plans, retrieves, acts — and exposes every step for inspection.

Hardening

Evaluation harness for explanations

Scoring explanation quality without an expert in every loop.

Learning

Production-grade LLM tooling

Orchestration patterns that stay debuggable at scale.

Technical depth

Languages
PythonTypeScript / JSSQLR
ML & Data
PyTorchscikit-learnpandas / NumPyHugging Face
Systems & Agents
LLM toolingRAG / retrievalLangGraphREST APIs
Workflow
Git / GitHubDockerJupyterLinux / shell

Failures & iterations

The version no one frames

Every system I'm proud of has an earlier version I'm not. Here's what broke, and what I changed.

What broke

My first explainability output was technically correct and completely unreadable.

What I changed

Reframed interpretability around the clinician's time budget, not the model's internals. The right unit was the decision, not the weights.

What broke

A forecasting model that looked great on the metric and useless to operators.

What I changed

Switched from point accuracy to calibrated uncertainty. A metric is a hypothesis — I'd optimized the wrong one.

What broke

An early agent that was impressive in a demo and impossible to debug.

What I changed

Rebuilt it to expose every step. Traded a little autonomy for total legibility — and it got more useful, not less.

See it in practice — the shipped systems and experiments.

View projects → The research side