Machine learning
Less the leaderboard version, more the question of how a model holds up once the data stops cooperating.
About Me
I am studying a BSc in Artificial Intelligence at King’s College London. Most of what I actually understand has come from building things and then being surprised by how they behave. I keep landing on the same kind of problem — software that has to make sense of messy real-world signals, whether that’s brain activity, market data, or a renovation project with too many moving parts.
Mostly by building, then following what got interesting
I started with software and product engineering — building things like Renovate, Cuey and Rackem. Shipping products pulled my attention away from algorithms in isolation and toward everything around them: architecture, reliability, deployment, and the trade-offs you only notice once someone depends on what you’ve made.
The research side started at UC Berkeley, on a brain–computer interface project decoding imagined left- and right-hand movement from EEG using CSP and SVMs. What kept me interested wasn’t pushing classification accuracy up — it was the underlying problem of inferring what a person intends from noisy biological signals, and eventually turning that into physical action.
Later, leading a small engineering team on a production portfolio-analysis platform at King’s Quant Society put me in front of a different kind of uncertainty: financial data, and systems other people rely on. The thread through all of it is that I like problems where software has to cope with messy real-world information rather than run in a clean, controlled environment.
Recurring themes
Intelligent physical systems
Software that has to act in the world — robotics, assistive devices — where a wrong output is more than a bad metric.
Brain–computer interfaces
Reading intention out of noisy biological signals, and turning it into something that moves.
Software & product engineering
Architecture, reliability, and the engineering trade-offs that only surface once people are using the thing.
Systems under uncertainty
Sensor noise, financial data, human behaviour — building things that stay sensible when the inputs aren’t clean.
The whole loop, not one part of it
Problem
Understanding
Experimentation
Implementation
Testing
Iteration
I like moving through the entire loop rather than settling into one stage of it: framing the problem properly, getting to the bottom of what’s actually going on, running experiments, building the real version, testing it against actual constraints, then going round again. Most of the useful work happens on the second or third pass.
Software that has to be right about the world
I want to keep working on more capable AI and ML systems that interact with and reason about the physical world. I am particularly interested in intelligent physical or assistive systems, where being right about something outside the software is the whole point.