I care about AI systems that survive production
Not demos. Systems — with the evaluation, observability, and failure handling that let a team trust them with real users.
How I think about engineering
Production AI is mostly software engineering
The model is one component. Reliability comes from routing, retries, timeouts, schema validation, evaluation gates, and observability — the boring parts that decide whether a demo survives contact with real traffic.
Evaluate before you ship
Every LLM system I build has a harness measuring correctness, retrieval quality, hallucination risk, and schema adherence. If a change can’t be measured, it can’t be trusted into production.
Design for failure paths first
Fallback model routing, graceful degradation to snapshots, human-review checkpoints on high-stakes actions. The happy path is easy; the interesting engineering is everything around it.
Depth over breadth of buzzwords
I’d rather deeply understand how retrieval, agents, and infra actually behave under load than collect framework logos. Systems intuition compounds; hype doesn’t.
The path here
IIIT Delhi — CS (Artificial Intelligence)
Built foundations across ML, NLP, systems, and algorithms, sharpened by competitive programming. Leaned toward applied AI and shipping over pure theory.
Software Engineer, JaiwebSoft
Shipped production backend services on GCP — FastAPI/Django on Cloud Run, event-driven Pub/Sub pipelines, tuned Cloud SQL schemas, and hardened production config.
Senior AI/ML Engineer, EcoRatings
Own production LLM systems end-to-end: Dockerized FastAPI on AWS ECS Fargate, citation-grounded RAG, LangGraph agents with human review, and evaluation harnesses that gate every release.
Where I’m headed
I want to keep building the connective tissue of production AI — agent runtimes, retrieval systems, and evaluation infrastructure — at teams shipping AI products that thousands of people actually depend on. Long term, I care about making AI systems that are reliable, inspectable, and honest about their limits.