Ashwin
Gupta
Role
AI Systems Engineer
Company
Coforge
Jun 2024 – Present
Honest where it matters. Available when it's hard.
Mechanical engineering by training - which meant learning to ask why a system fails before asking how to build it. AI hit in second year like a realisation, not a subject: software that understood language was a new class of thing, and I knew it would matter before anyone around me thought it would. The IISc ML lead role confirmed the direction - physics-constrained optimisation on eVTOL design under Dr. Harursampath, five projects in eight months, at the edge of what was understood.
Production changed the picture fast. At Gida and then Coforge, the same pattern emerged: the GenAI core - prompts, basic RAG, API calls - is learnable in three months. Everyone builds it. The real gap is what surrounds the model: the routing logic, the concurrency architecture, the observability that tells you what actually broke and when. That's the part nobody wants to own. That's where I went.
At Coforge on the HSBC Conversational Analytics project, I was the youngest on the team and three months in when I became the de facto integration lead - having solved in one week a problem another technology partner hadn't resolved in eight months at the same client. GIL'd threading replaced with CPU-pinned parallel instances, asyncio + uvloop across the full pipeline, cross-stack observability built before the second incident happened. 7× session capacity. $1.3M annualised savings. MTTR from ~1hr to ~10mins.
Inference as a System
Most teams ship inference as a function call. The real questions - p95 latency, 10× load, what happens when a backend goes down - are architecture questions. I answer them before the first model goes live.
Execution Under Constraints
Systems that perform in demos often don't survive production. Real constraints - latency budgets, VRAM ceilings, cost per token - are known at design time, not discovered at launch. I build the constraint model first.
Physics-Informed Scientific ML
Data-driven physics models aren't data problems - they're structure problems. Ignoring governing equations forces the model to rediscover physics from data it may never have enough of. Embedding PDEs into the objective is what makes sparse data sufficient.
What I don't do
- I don't ship AI wrappers dressed as products. Core API calls with a nice UI aren't systems.
- I don't build for its own sake. The system has to earn what it costs to run.
- I don't take off-the-shelf work. If the implementation is a Google search away, I'm not the right person.
Profiled under load. Not just imported.
