Mithin Sagar
Skip to content
02About

Engineer first,curious always.

I’m a Computer Science undergraduate at VIT Chennai, specialising in AI and machine learning. Most of what I build starts as a question I couldn’t answer by reading — so I build the thing that answers it.
Location
Chennai, India
Programme
B.Tech CSE (AI & ML)
Class of
2027
Portrait of Mithin Sagar
Mithin Sagar SAI / ML Engineer
The short version

I build machine learning systems that can be checked. The model is the easy half; the hard half is making its answer inspectable by someone who did not train it. 

That habit came from a real failure. During an internship at IGCAR I fine-tuned a YOLOv8 detector for weld inspection and watched it score 99.1% on training data and 74.3% on held-out. The interesting work was not the training run — it was diagnosing the overfit, revising the dataset and splits, and explaining the trade-off to scientific staff who needed a decision, not a metric.

Since then almost everything I build has the same shape. A deterministic core that owns the number and always completes. A retrieval or language-model layer that can only describe the result, never move it. And a benchmark that fails loudly when a claim in the README stops being true.

Outside the terminal I lead student teams and shoot live events. Both of those turn out to be the same skill as engineering: reduce the ambiguity, shorten the feedback loop, and make it obvious to the next person what is going on.

Based in
Chennai, India
Studying
B.Tech CSE — AI & ML, VIT Chennai
Graduating
May 2027
Focus
Explainable, measurable AI systems
Also
Photography, live events, team leadership
Open to
Internships and AI/ML roles
How I work

Four rules Idon’t break.

Not a manifesto. Just the things that kept turning out to matter.
  1. 01

    The score is never the product

    A model that returns a number asks to be trusted. A system that returns the evidence behind the number can be checked. I build the second kind.

  2. 02

    Determinism where it counts

    The part that produces the answer should be pure — no network, no clock, no randomness. The language model gets to write prose about the result, not change it.

  3. 03

    Measure it or don’t claim it

    Ground truth manifests, held-out splits, calibration curves. If a number cannot be reproduced from the repository, it does not go in the README.

  4. 04

    Failure should have an address

    One stage, one responsibility, one auditable handoff. When something breaks I want to know which component owned it before I open a file.

Skills & tools

What I reach for.

Download résumé

01Languages

  • Java
  • Python
  • C
  • JavaScript
  • TypeScript
  • SQL

02Generative AI

  • LLM APIs
  • Prompt engineering
  • Retrieval-Augmented Generation
  • Agentic workflows
  • LangGraph
  • FAISS
  • Embeddings

03Machine Learning

  • scikit-learn
  • PyTorch
  • pandas
  • NumPy
  • Cross-validation
  • Model calibration

04Web & Backend

  • React
  • Next.js
  • Node.js
  • FastAPI
  • Flask
  • REST APIs
  • PostgreSQL
  • MongoDB

05Tools & Practices

  • Git / GitHub
  • GitHub Actions
  • Docker
  • pytest
  • Vitest
  • OOP
  • Agile / Scrum
Next

Let’s build somethingmeaningful.

Open to internships and AI/ML roles, research collaborations, or a conversation about something you are trying to make work. I reply to everything.

EmailGitHubLinkedInInstagramRésumé