Creative & Adaptable
I try to stay creative and adapt to whatever a problem actually needs, rather than force the same approach onto everything.
Welcome — this is my portfolio. Almost everything in this workshop is something real you can click into. Look around and pick up whatever catches your eye.
Scroll to pan the room · pick anything up
I'm Devasurya, currently in my fourth year of a Computer Science degree at Jain University.
I like making things — especially things that are actually useful or mean something. And because of that, I'm always thinking up ideas for products, services, or anything that seems interesting or worthwhile to me. I'm also very curious, and I'd rather understand how something works than just use it. That's probably what drew me into AI and using it.
I spend a lot of my time building projects and picking up new tools along the way — a few of them are on the bench in this workshop if you want to take a look. I also try and actively keep myself busy by learning new skills or picking up new projects. I'm currently working on an online cubing platform, as well as learning Japanese on the side.
Outside of tech, I listen to a lot of music, watch a lot of movies, and spend a fair amount of time gaming, driving, or playing football. I'm also into bouldering — but more on all of that on the shelf, if you're curious.
I try to stay creative and adapt to whatever a problem actually needs, rather than force the same approach onto everything.
If I don't fully understand something, I stop and figure it out before moving on — no matter how long that takes. I'd rather get there properly than fake it.
I think AI should make people more efficient, not replace the understanding underneath. Using it well still comes down to knowing the domain and directing it properly — the direction matters as much as the tool.
I'd rather ship something complete and working than leave it half-built. If I build something, I want it to run end to end, not just look good in a notebook or a demo.
TraceFlow takes a fault report from a factory machine and turns it into a full root-cause analysis — automatically, with no one sitting in the loop. Three small agents run in sequence: one gathers evidence, one writes the diagnosis, and one checks that every claim in the report is actually backed by what was gathered. You get a structured report back, not a raw log dump, and it runs as a proper background service with real authentication, per-tenant data isolation, and hard caps so nothing runs away with cost or time.
Click through each stage — problem, decision, mechanism, outcome →
When a factory machine throws an error, someone has to work out why — normally a technician reading logs and manuals by hand. TraceFlow takes that error report and investigates it the way a technician would, without anyone needing to wait around or do the digging themselves.
Rather than one big prompt trying to do everything, I split the job into three agents that hand off to each other: an Investigator that gathers evidence, a Diagnostician that writes the report, and a Verifier that checks the report's claims are actually grounded in what was gathered. Splitting it this way makes each piece easier to reason about — and easier to cap.
The Investigator pulls the machine's fault history from Postgres and searches technical manuals in ChromaDB using locally-run embeddings, so no external API call is needed just to search. It's capped at 6 evidence-gathering rounds, and the whole incident is capped at 15 LLM calls total, so nothing can run away with cost. The Verifier isn't checking whether the diagnosis is true — it checks that every claim actually traces back to the evidence, and it can flag attempts to slip instructions into the retrieved manuals.
I built an eval harness to actually check this instead of taking it on faith — 13 gold-labeled incidents, including a few adversarial ones. It found the right manual section 12 times out of 13, and passed 36 of 39 rubric checks on the written diagnoses, with every incident completing — nothing timed out or blew its budget. There's also a React + Vite frontend for submitting incidents and reading the reports, so it runs end to end, not just the backend half.
NEEDS: real request/response screenshots or a recorded incident walkthrough, to extend this centerpiece with an actual incident submission → investigating → verifying → RCA report reveal.
Drifty is two tools in one: a way to refine a prompt before you ship it, and a way to watch it after you have. Give it a goal and three different models each generate a candidate prompt in a different style, three judges rank them, and the top two get run against real example inputs so you can see the results side by side instead of just trusting a score. Once you've picked a winner, you can register it with a few checks, and Drifty re-runs it daily to catch it if it starts failing in production — firing a webhook the moment it crosses a threshold instead of leaving you to notice on your own.
Click through each stage — problem, decision, mechanism, outcome →
Getting a prompt to actually work well usually means guessing at phrasing and eyeballing the output. And even once a prompt works, nothing tells you if it quietly gets worse later — a model update, an edge case creeping in — and you don't find out until something downstream breaks.
I split it into two halves instead of one big loop: a synchronous refine step where you compare candidates side by side and pick one, and an asynchronous monitor step that runs the winner on a schedule and watches for it to drift. Three models generate, three separate judges rank — using forced ranking instead of numeric scores, which turned out to work a lot better with weaker free-tier models.
The queue is a hand-rolled Redis setup — two lists, BLPOP, refine
jobs given priority over monitor jobs. Fan-in across the three concurrent
generation jobs uses a single atomic Redis INCR counter, so
whichever worker's count hits 3 first moves the round forward, instead of
reading two separate counters and risking a race. The judge parser fails
closed too — if a ranking isn't a clean permutation of the candidates, it's
thrown out rather than guessed at.
It's been running against its own numbers, not projected ones: 15 refine rounds with zero failures, 86% judge agreement with whichever candidate ends up winning, and 28 automated monitor runs across 6 registered prompts — all for about $0.0008 total, mostly on Groq's free tier. It's not deployed publicly on purpose — the point was the engineering, not standing up another public endpoint — but it runs the whole path end to end locally via Docker Compose.
This project detects eye diseases from retinal images, and — just as important — shows why it made that call. Every prediction comes with a heatmap of what the model was actually looking at, not just a label. It covers four diagnostic categories, and the whole point was to treat explainability as something the model has to earn, not a nice extra tacked on afterward.
A model that's just accurate isn't enough for something medical. If it can't explain itself, there's no way for a doctor to catch it when it's confidently wrong.
I trained two different architectures on the same retinal images — a ResNet18 CNN and a Swin Transformer — and compared them side by side instead of picking one and hoping it was good enough. Both produce a Grad-CAM heatmap with every prediction.
I also checked whether the model's attention actually made sense — glaucoma predictions should focus on the optic disc, diabetic retinopathy should pick up scattered spots across the retina. That's a real check on whether the model is right for the right reasons, not just a nice-looking overlay.
The CNN hit 91.12% validation accuracy, the Swin Transformer hit 94.08%. The transformer did better because it picks up on broader patterns across the image instead of just local details. It's deployed live, not sitting in a notebook.
Trained on ~4,200 retinal images across four diagnostic categories (Kaggle's Eye Diseases Classification dataset).
NEEDS: real prediction + Grad-CAM heatmap image pairs for a few example cases, to extend this deep-dive with an actual raw-prediction vs. Grad-CAM overlay toggle.
AutoPrompt automatically improves prompts for an LLM instead of me tweaking them by hand. It runs on Groq's API using Llama-3.1-8B, and the idea is simple: instead of guessing which phrasing works best, let a separate process generate variations and actually test them. It grew out of wanting prompt engineering to be less trial-and-error and more of a measured process.
A separate model generates and tests candidate prompts against the task. Baseline and optimized versions run at the same time using asyncio, with rate limits managed through semaphores so nothing gets throttled or dropped. Both versions get scored against held-out test data, so the better prompt is picked on actual results, not a guess — and running everything concurrently is also what makes the whole pipeline noticeably faster than testing prompts one at a time.
This work also became a co-authored, accepted paper, which was a good lesson in the difference between a tool that works and a result that holds up to review.
This tool estimates a fair resale price for second-hand items. A scraper pulls real listings, an XGBoost model predicts the price, and the whole thing is wrapped in a proper backend and dashboard instead of living in a notebook. The goal was to build something a person could actually open and use to check what their stuff might sell for, not just a proof-of-concept script.
FastAPI serves the backend, a Streamlit dashboard is the frontend, and everything runs containerized with Docker — a complete path from raw listing data to a usable price estimate. The scraper handles data collection on its own, feeding real listings into the model instead of relying on a static dataset, so the predictions stay grounded in what's actually being sold.
NEEDS: real CI-score / SHAP output examples, to extend this piece with a live prediction-breakdown interaction like the brief originally envisioned.
This project compares a batch of different machine learning algorithms to see which one actually predicts diabetes best from patient health data — glucose levels, BMI, blood pressure, age, and a few other clinical measurements. Instead of picking one model and going with it, the idea was to run many side by side under the same conditions and let the results decide. It was a shared project with a teammate, and each of us tried a different way of preparing the data before classification.
My part used PCA for dimensionality reduction paired with a kernel SVM (RBF kernel), run against the standard eight-feature diabetes dataset — Pregnancies, Glucose, Blood Pressure, Skin Thickness, Insulin, BMI, Diabetes Pedigree Function, and Age — across a few different train-test splits. The rest of the project tested a much wider set of algorithms, from boosting methods to neural nets, on the same data, which made it a good way to see how much the preprocessing choice alone changes the outcome.
These are the skills I actually use — I've applied all of them in a real project, and I've got at least a working knowledge of everything else here.
Apart from work, I'm also into these.
Probably my main one — always looking to get into new music and finding new
artists. Right now that's a lot of Blood Orange,
Mac DeMarco, and Inner Wave.
I play regularly, mostly to keep the habit alive. Cleared most of the
FromSoftware games — Elden Ring, Bloodborne,
Sekiro, Dark Souls 3 — along with Persona 5,
OMORI, and Undertale. Currently working through
Blasphemous and Hades. Favorite's probably the
Infamous series.
Favorite anime's Steins;Gate. For movies, I'd go with
Jumper, Palm Springs, or The Sorcerer's
Apprentice.
Hiking, football, and bouldering. I ride my bike a lot too.
Pokémon cards — physical, and on TCG Pocket. I've played a good number of the games too.
Always looking for new things to get into.
If the workshop was worth the walk, hang your sigil on the shield. Every visitor gets one strike — pick a sigil, pick a metal, sign it with your initials.
0 MARKS ON THE SHIELD