01
Schemas first, prompts second.
The data shape decides what the model can do, what the UI can render, and where things will eventually break. Prompts are the easy part once the schema is honest.
I'm a product and systems engineer based in Bengaluru. I build the AI pipelines and real-time interfaces that make large-scale media usable. Currently at Tessact, where we process hundreds of hours of content every single day.
Most of my hours go to the parts of an AI product that never make it into the demo. The pages below are how I think about that work, a few honest lines about how I got here, and what's currently on my desk.
Deep React years. Performance-critical UIs at scale, chasing every dropped frame and re-render until the runtime stopped lying to me.
Pipelines, queues, infra. Started caring about queue depth more than bundle size, and discovered that distributed systems mostly fail in slow motion.
Tessact. Hundreds of hours of video a day, where the model is just one of many things in the pipeline that has to stay honest.
The data shape decides what the model can do, what the UI can render, and where things will eventually break. Prompts are the easy part once the schema is honest.
It will lie, time out, and contradict itself. The retrieval, validation, and fallback layers around it deserve the same care you'd give any flaky external service.
A 300ms wait is a UI choice as much as a backend one. What you put inside it (a skeleton, a stream, a partial result) is the difference between a product that feels alive and one that feels broken.
When the screen shape is clear, the API shape usually becomes obvious. I sketch the surface before touching the endpoint. It saves an embarrassing number of round-trips later on.
The novelty wears off in about a week. What stays is whether the thing is fast, predictable, and useful. The same standards that apply to any other piece of software worth using.
Five honest lines. The shape of how I work, what I came from, and how I think about getting better.
Most of my time goes to the parts that never make it into a demo. The retrieval that grounds an answer. The schema that keeps the model from lying. The interface that turns any of it into something a person can actually use. That's where the real difficulty sits, and it's where I've spent the last few years getting good.
Years of building performance-critical UI taught me how to keep complex state fast and honest. That instinct still drives the way I design backend pipelines today. Get the data shape right at the start, and most of the surrounding code falls out for free.
Most systems become clear once the data movement is clear, so I keep a stack of paper notebooks for exactly this reason. Bugs I catch on the page are bugs that never make it into production. The whiteboard is the most important tool in my stack.
I read fiction every week, no fixed genre. Twitter and YouTube keep me current with the field, but the ideas that actually move a project forward tend to arrive when I'm not actively chasing them.
I don't pretend to know everything. I just make sure I can figure things out quickly when I don't. Comfort with uncertainty has done more for my work than any specific stack ever has.
Anything where the model is one part of a larger system. Streaming interfaces, retrieval-grounded products, long-running media pipelines, the layers that keep an AI feature trustworthy once real traffic shows up. If any of that sounds like what you're building, I'd be glad to hear from you.