_{Chennai, India · Available for full-time roles}

LinkedIn  ·  Portfolio  ·  Email  ·  GitHub

Most of what gets called "AI engineering" is really data engineering with a language model bolted on. That's the part I like — the unglamorous work of taking a pile of real, messy documents and turning them into something a model can reason over correctly. I'm currently building that at Aieton Labs, where insurance policy documents go in as scanned PDFs and come out as grounded, structured answers.

I came into AI through full-stack development, not around it, which shapes how I build: I care as much about the pipeline shipping to production as I do about the model inside it. Four years of Computer Science at Anna University, a CGPA of 8.1, and a habit of finishing what I start.

Three problems keep showing up in my work, in different clothes each time:

Grounding. Language models are fluent and frequently wrong. My job is closing that gap — retrieval pipelines that hand the model the right five paragraphs instead of hoping it remembers something similar from training.

Extraction. Businesses run on documents that were never meant to be read by software — policy forms, claim reports, scanned contracts. I write the prompts and pipelines that pull structured fields out of that chaos reliably enough to trust in production.

Autonomy. Some workflows shouldn't need a human in the loop for every step. I design agents that can decide which tool to call and when, so a multi-step query resolves on its own.

A RAG system is only as good as its weakest stage. This is the shape I default to, and the one currently running in production at Aieton Labs:

01  INGEST     raw PDFs, forms, scanned policy documents
02  CHUNK      context-aware splitting, not fixed-size guessing
03  EMBED      vectorized representations for semantic search
04  RETRIEVE   top-k relevant context, ranked and filtered
05  GENERATE   LLM response grounded in retrieved source, not memory

Every stage above has failed silently on me at least once — a bad chunking strategy or an ungrounded prompt will still produce a confident-sounding answer. I'd rather spend time on evaluation and validation at each step than trust the output at the end.

The same discipline carries into the agent work: an agent that calls the wrong tool is worse than no agent at all, so tool-routing gets tested like code, not vibes.

FixiFox — a multi-model AI debugger

Problem. Developers lose time bouncing between tools — a linter here, a security scanner there, a separate window for an explanation of why the bug happened.

Approach. One interface, seven LLMs. FixiFox routes a given piece of code to the model best suited for the task — bug detection, generation, security analysis, or language conversion — inside a Monaco-powered editor with session history and authenticated user state.

Outcome. 80% bug-identification accuracy, and a 60% cut in debugging time in testing.

Python Streamlit Groq API Monaco Editor SQLite  ·  Repository

Real-time drowsiness detection

Problem. Driver fatigue is hard to self-report and easy to miss until it's dangerous.

Approach. Facial landmark tracking via OpenCV and Dlib, running continuously and unattended, triggering an audio alert and an emailed snapshot the moment drowsiness patterns appear — no dashboard required, no human watching a screen.

Outcome. 90% detection accuracy in real-time testing conditions.

Python OpenCV Dlib SMTP  ·  Repository

Earthquake prediction from seismic data

Problem. Early warning systems are only useful if the pattern recognition behind them is trustworthy.

Approach. Applied classical ML — pandas-driven feature analysis and scikit-learn models — to seismic datasets, treating the data-analysis phase as its own deliverable rather than rushing to a model.

Status. Phase one complete; model optimization ongoing.

Python Pandas Scikit-learn  ·  Repository

I optimize for the version that ships, then improve it — a working pipeline with rough edges beats a perfect design still in a document. I default to the simplest architecture that satisfies the requirement, and add complexity only when the simple version demonstrably fails. And I treat evaluation as part of the build, not a step after it: an AI feature without a way to measure whether it's actually working isn't finished, it's a demo.

—

Let's talk

If you're solving a problem where the data is messy, the stakes are real, and "it works on the demo" isn't good enough — I'd like to hear about it.