Skip to content
Mohit Sharma

SYS / 001

Mohit Sharma

I build systems, then work out why they actually work.

Engineering lead. I spend most of my time where a design stops matching its diagram, and I write down what I find there.

Distributed systemsAI infrastructureBackendProduct engineering

SYS / 002

I work across backend systems, infrastructure and AI-powered products, mostly in the part of the job that does not make it into the design doc.

The interesting work tends to sit between not understanding something yet and knowing exactly why it behaves the way it does. This site is where that gets written down: not as tutorials, and not from any particular authority, but as the explanation I wish had existed while I was working it out.

SYS / 003

Currently exploring

  1. 01

    Agent engineering

    Tool design, control loops, and the failure modes that only appear once an agent runs unattended.

  2. 02

    LLM infrastructure

    Serving, batching and cost behaviour under real traffic rather than benchmark traffic.

  3. 03

    Retrieval and reranking

    Where recall actually leaks, and what a reranker buys that a better embedding does not.

  4. 04

    Evaluation

    Harnesses that fail honestly, and metrics that survive contact with a product decision.

  5. 05

    Distributed systems

    Consistency, backpressure and the long tail. Mostly the long tail.

SYS / 004

Selected work

All work
  • Cortex

    A multi-tenant retrieval platform: ingestion, chunking policy, hybrid search and a reranking stage that has to justify its own latency budget.

  • AI infrastructure

    Serving, retrieval, reranking and evaluation tooling for LLM-backed products, with the cost and latency behaviour that only shows up under real traffic.

    No write-up yet

  • HangarMart

    An aviation and fleet software platform: parts, maintenance and the scheduling constraints that come with keeping aircraft airworthy.

    No write-up yet

  • Trading systems

    Backtesting, market data ingestion and the quantitative engineering around them, where correctness is measured against a replayable past.

    No write-up yet

  • PyaarSay

    A therapy marketplace: matching, scheduling and the product engineering around a service where the failure modes are human rather than technical.

    No write-up yet

SYS / 005

Engineering notes

All notes

Things I had to understand properly before I could explain them.

  • 2026.09.18

    Why do we need rerankers after vector search?

    Vector search returns neighbours, not answers. A reranker is the only stage allowed to read the question and the document at the same time, and that turns out to be the whole difference.

    5 minRetrievalAI infrastructure

SYS / 006

How I work

  1. Question

    Something behaves in a way the model in my head does not predict.

  2. Investigate

    Read the source, the logs and the metrics. Distrust the summary.

  3. Experiment

    The smallest reproduction that isolates exactly one variable.

  4. Build

    Put it somewhere real, where the constraints are not hypothetical.

  5. Break

    Push it until it fails on purpose, while I am still watching.

  6. Understand

    The model that makes the failure look obvious in hindsight.

  7. Document

    Write it down while I still remember which part confused me.

Writing the last one down is usually what produces the next question.

SYS / 007

Now

Full snapshot

September 2026 · updated

Building
REPLACE: the system you are actually building, and the part of it that is hard.
Learning
REPLACE: something you are deliberately working out at the moment, and why.
Reading
REPLACE: a book or a paper you are actually in the middle of.
Thinking about
REPLACE: an open question you have not resolved. This section is the most interesting one when it is honest.

The rest of it

SYS / 008

Elsewhere

If any of this overlaps with what you are working on, I would genuinely like to hear about it.