Hi, I'm Abhishek.

I actually started out building web apps, mostly because you can see what you built right away. But a couple of internships in, I noticed the part I actually cared about had quietly moved somewhere else. Not the page itself, but the schema underneath it, and how many round trips it took just to fill in a form.

So these days I spend most of my time on two things: data in motion, and trust boundaries. Basically the two places where a system is most likely to be confidently wrong without anyone noticing. A dashboard that renders perfectly off a stale aggregate. A tool server that swears it only needs to read one file.

The habit I keep trying to build is measuring things instead of assuming them. Anyone can write "real-time" in a readme. It's a lot harder to say what your watermark actually is, what happens when a packet shows up four minutes late, or what your number looks like when you go back and actually check it.

Two internships, remote, sole developer on both. Both shipped to a live domain — which is a different kind of pressure than a repo nobody deploys.

_{python · langgraph · claude api · docker · pydantic · repo →}

A LangGraph pipeline (20 nodes) that reads a failing GitHub Actions run, works out why, and then — the part that matters — reproduces the failure in a network-isolated Docker container and proposes a fix only after it passes there with no other test breaking. A static audit gate refuses patches that make a test pass by cheating: deleted or skipped tests, weakened asserts, deleted or swallowed errors.

Measured on 40 real bugs from BugsInPy with a small model (claude-haiku-4-5, $0.65 for the whole run): 32/40 diagnosed correctly, all 16 out-of-scope bugs declined, 4 of 24 fixable bugs fixed. Every fix it calls verified is judged afterwards by held-out tests the model never saw — and 1 of those 4 was still wrong (4 of 9 in the run before, which is what drove the audit rules). That number is the one I care about: an agent that confidently proposes a broken fix is worse than one that says it doesn't know. results and method →

_{kafka · spark · duckdb · delta lake · next.js · live → · repo →}

Telemetry from 42 simulated sub-meters streamed through Kafka into Spark 5-minute windows, with PostgreSQL for the hot path and Delta Lake for history.

The part worth defending is what happens after the aggregate lands. Anomalies are flagged by Isolation Forest crossed with a z-score, and 24-hour load is forecast at 11.5% MAPE — accurate enough to fire a peak-shaving alert before the peak, which is the only time such an alert is worth anything.

A 5-minute sliding window with a 1-minute slide and a 2-minute event-time watermark, because sensor packets do not arrive in the order they were measured and pretending otherwise gives you clean-looking numbers that are wrong. The storage split is the design: freshness is bought with batch size, history with partitioning, and neither pays for the other.

_{python · fastapi · seccomp-bpf · landlock · docker · PyPI → · repo → · evaluation →}

An MCP tool server describes its own capabilities. That description is a claim, not a fact, and the gateway treats it that way: declare, verify, confine.

Each server is profiled under strace in a --cap-drop ALL --read-only container, the observed syscalls are checked against what the server declared, and the verified result is compiled into a per-tool seccomp-BPF filter. Anything outside the declaration is denied at the kernel boundary, not by application code that can be talked out of it. Provenance gating on tool-call arguments and per-call manifest re-attestation close CVE-2025-54136.

The part I'd defend in an interview isn't the enforcement, it's the evaluation. A 7-corpus, 583-row harness that separates detection from containment, because a gateway that notices an attack and doesn't stop it deserves a different number than one that stops it. 84.6% runtime defence, 100% containment, 87.8% on MCPTox.

_{python · fastapi · xgboost · h3 · next.js · live → · repo →}

112K parking violations clustered into 1,196 H3 hotspots, each ranked with a 0–100 congestion-risk score, then forecast a week ahead with XGBoost at 0.80 Precision@10 across 53 police stations.

Most of the work was in the join, not the model. Violation records, geospatial cells and time-of-day buckets have to line up before anything downstream means much — and the discipline is resisting the urge to read a hotspot into what is really just a place with more reporting. SHAP reason chips sit next to each prediction so an officer can see why a cell ranked high, and greedy routing turns the ranking into patrol routes for N units. The finding I liked most wasn't a prediction at all: a 5.5% afternoon enforcement blind spot city-wide, visible only once the data was honest.

Top 5% at the Flipkart Gridlock hackathon.

_{next.js · llm api · vercel · live → · repo →}

An RTI filed at the wrong ministry doesn't get rejected — it gets transferred, and the statutory clock starts over. That single detail is the product: route the request correctly the first time, or the citizen silently loses a month.

So it routes grievances to the right ministry through an LLM against a curated directory, then rewrites the complaint as a record request — the form an office is legally obliged to answer, rather than the form it can file away. Appeals draft themselves when a deadline passes, and the deadline alert lands by email before it does.

_{pytorch · huggingface transformers · model card →}

DistilRoBERTa domain-adapted by masked-language-modelling over 61.5K phone reviews, then fine-tuned for 3-class sentiment — all of it on a single 4GB GPU, which shaped every decision about batch size and sequence length.

88.2% accuracy and 94.9% positive-class F1 on 8.4K held-out reviews, at roughly 50ms per review. The two-stage approach is the point: adapting the encoder to the vocabulary before touching the classification head is what a general-purpose sentiment model doesn't get you.

The most consistent thing I do — 306 active days, and the reason a cost-per-operation instinct shows up in everything above.

_{across LeetCode, GeeksforGeeks, Code360 (4x monthly topper) and CodeChef · rating and difficulty split fetched live · totals tracked on Codolio}

Merged upstream across Kubeflow and Karmada, and a Kubeflow org member since September 2026. Small in line count, mostly; the interesting part is that each one was a disagreement between two pieces of a system that each looked correct alone.

Smaller fixes, one line each:

• kubeflow/mcp-server · #237 and #296: blocked responses and confirm-gate previews no longer advertise a next step for an action that never ran · #236: runtime names validated in the platform runtime tools · #411 and #426: an unknown persona or a broken policy file now stops the server with a one-line error instead of a traceback
• Windows-only test failures · mcp-server #290: tests that slept 60 ms and trusted a 15.6 ms clock to measure it · #324: a test that built a fake home and read the real one · trainer #4191: a "stale manifests" failure that was CRLF at checkout
• karmada-io/dashboard · #700: TypeScript strictness across the member-cluster services · #702: a shebang on the wrong line, so the i18n CLI could not run

Also contributing through GSSoC, and a published inference model on HuggingFace Hub. See all merged PRs.

_{Integrated Dual Degree (B.Tech IT + MBA) · IIITM Gwalior · graduating 2028}

_{if something here looks wrong, it probably is. tell me}