About
I'm David, an engineer who works where machine learning meets financial markets. My background sits at the crossroads of two disciplines that don't always speak the same language — modern AI systems built for scale and iteration speed, and quantitative finance built for rigor and risk management. Most of my career has been spent translating between the two: taking research-grade models and turning them into systems that hold up under real capital, real latency constraints, and real regulatory scrutiny.
I got into this work because I like problems where being approximately right isn't good enough — where a subtle bug in a backtest or a leaky feature pipeline can silently cost real money, and where the difference between a model that looks good in a notebook and one that survives production is almost always in the engineering, not the math.
What I work on
Modern AI Systems
I design and ship LLM-powered and classical ML pipelines end to end — from data ingestion and feature engineering through training, evaluation, and serving. I care a lot about the unglamorous parts: observability, reproducibility, and making sure a system's behavior in production matches what was validated offline.
Financial Machine Learning
Applying ML to markets means fighting a constant battle against leakage, non-stationarity, and overfitting to noise that looks like signal. I build tooling and workflows — point-in-time correct feature stores, walk-forward validation, realistic transaction cost modeling — that make it harder to fool yourself.
Quantitative Finance
I'm comfortable in the quant toolkit itself — portfolio construction, risk decomposition, backtesting engines, and the statistics underneath them — which means I can build ML systems that quants actually trust, because I understand what they're being asked to trust them with.
How I think about it
I'd rather ship something simple that's well understood than something clever that nobody on the team can debug at 2am. In both AI and finance, the failure modes that hurt you are rarely the ones you anticipated — so I try to build systems that fail loudly, log generously, and make it easy to trace a bad output back to the exact data and decision that produced it. Good engineering, to me, is mostly about making the invisible parts of a system visible.