I published three peer-reviewed papers in exercise physiology before I wrote my first line of production code. For a while, that felt like a liability. Now I think it's the whole point.
The long way around
I grew up obsessed with sport. Not just playing — understanding it. Why do athletes fade in the final stage of a race? What happens physiologically when a team's performance collapses in the fourth quarter? These weren't idle questions. They were the ones I chased through a sports science degree, then a master's programme, then into a research lab at UBC.
The research world is slow. Ideas take years to become experiments, experiments take months to become data, data takes more months to become papers. I loved the rigour. I hated the pace. But I learned something invaluable: how to frame problems clearly, how to design experiments that give you real signal, and how to communicate complexity without losing the thread.
Those skills transfer more than I expected.
The pivot that wasn't really a pivot
I didn't leave sports science for AI. I followed curiosity into it. A few years ago, I started noticing that the most interesting problems in performance science were computation problems. How do you model an athlete's readiness across a season? How do you personalise training load recommendations at scale? How do you make sense of ten thousand data points from a GPS vest?
I started building tools to answer those questions. First in Python — messy scripts that worked but wouldn't impress anyone. Then, when LLMs became genuinely capable, something shifted. The barrier to building dropped dramatically. I could describe what I wanted to build, and the feedback loop tightened from weeks to hours.
That's when I became obsessed with AI-native development. Not AI as a topic, but AI as a way of building.
What a research background actually teaches you
There's a pattern in how I approach problems that I didn't notice until recently. It goes: form a hypothesis → design the smallest possible test → look at real data → update your model. In science this is called the hypothetico-deductive method. In software, it's just good engineering.
The research years also gave me a calibrated sense of uncertainty. I'm comfortable saying "I don't know" and then figuring it out. I'm suspicious of solutions that are too clean. I know the difference between a result that's statistically significant and one that's actually meaningful.
These turn out to be rare traits in a field where everyone is moving fast and confidence is easy to fake.
What I'm building now
Right now I'm an AI ops lead — shipping AI products, managing AI systems in production, thinking about how to operationalise AI at the organisational level. I also build independently: web apps, tools, automations. In the last month alone I shipped 15 projects, from a snow forecast app to a real-estate explorer to a cycling durability analyser based on my own published research.
The through-line across all of it is the same: I care about whether things actually work. Not just whether they demo well. Whether a cyclist can upload their real ride file and get a meaningful number back. Whether a budgeter can import a real bank CSV and see where their money actually went.
The sports science background taught me to ask: does this intervention produce a real effect in a real person? The AI engineering work is the same question with different variables.
Where I'm headed
I want to work on AI products that matter — tools that help people understand complex systems, make better decisions, or do things they couldn't do before. The intersection of health, performance, and AI is where I'm most interested, but I'm genuinely drawn to any domain where the problems are hard and the stakes are real.
The unusual path turned out to be a feature. Sports science made me a better builder because it made me a better thinker first. I'm still figuring out exactly where this leads. That part feels right.