01
Complete
Fundamentals
C, memory, data structures, algorithms. CS50x, then continued in C on my own.
AI journey
Models are the visible part. Serving, data pipelines, evaluation and behaviour under load are infrastructure — and that is the foundation I am building, from the infrastructure side rather than the model side. What follows separates what exists from what is still intent.
01
Complete
C, memory, data structures, algorithms. CS50x, then continued in C on my own.
02
In progress
APIs, data modelling, authentication, and typed service code. One stack understood properly rather than five sampled.
03
In progress
asyncio in anger: bounded concurrency, rate limiting, retries with jitter and timeouts, behind Protocol-defined interfaces. Shipping in site-auditor and in the FastAPI service behind Postmark.
04
Planned
Serving, evaluation, data pipelines and the infrastructure models actually run on — the backend problem, with a harder correctness story. Started from the infrastructure side: upstream work on a CNCF edge-AI benchmarking framework.
In progress
CNCF · distributed synergy AI benchmarking
Two fixes in review on the framework CNCF uses to benchmark edge–cloud collaborative learning: a dataset-config parser that silently swallowed unknown keys, and an error message that named a filename the loader does not look for. Both are infrastructure defects rather than model work — which is the layer of AI systems I am aiming at.
Shipped
Smart India Hackathon 2026 · team lead
Owned the backend for an ML-backed email threat detection platform: async FastAPI request handling, the PostgreSQL schema holding the evidence behind each verdict, and the boundary between the API and the model. The model was not mine. Everything it needed in order to be useful was.
In progress
Self-directed
Bounded concurrency, rate limiting, retries with jitter and Protocol-defined interfaces. Inference serving and data pipelines are the same problem with more expensive units of work, so this is the prerequisite rather than a detour.
In progress
Harvard University · edX
Search, knowledge representation, optimisation, learning and neural networks. In progress — listed here as in progress, not as a credential.
Not started
Planned · after the backend track
Building a language model from scratch, then the systems course on how one is actually trained and served. Deliberately sequenced after backend employability rather than in parallel with it: two half-finished tracks are worth less than one finished one.
A model that returns the wrong answer is a research problem. A serving layer that returns the right answer to the wrong tenant, or silently drops a third of a batch, is an engineering failure — and it is the kind of failure I have already spent four years learning to design against in a physical system.
So the sequence is deliberate. Fundamentals first, because you cannot reason about cost without them. Then backend depth, because that is where correctness is enforced. Then concurrency and distribution, because that is where correctness gets hard. ML systems last, because they need all three.
The honest version of where that leaves me today: I am a backend engineer with 4 merged contributions to Python infrastructure and open work on a CNCF AI-benchmarking framework. Not an ML engineer. The work above is the route between the two, and I would rather it be read as a route than as a claim.