Final-year Information Science Engineering student at Atria Institute of Technology, Bangalore.
Most of what I build makes a decision at runtime: when to compile, what to drop, where to allocate, which schedule to try next. A decision is only as good as the thing you compare it to, so each of these projects also ships an oracle that can see the future, and reports the fraction of the available win that was actually collected. Including the runs where the answer is "none".
Published in Advancement in Image Processing and Pattern Recognition (2026). 1st place, Cicada Agentic AI Hackathon. Smart India Hackathon 2025 national round, led system architecture.
| project | the decision | the yardstick |
|---|---|---|
| hotpath | when a regex is worth compiling to machine code | a hindsight optimal schedule |
| ballast | which requests to fail under overload | fixed limits, tuned well and tuned badly |
| envelope | whether a network is provably robust, with no third answer | an attacker searching the same ball |
| counterexample | which schedule breaks a consensus algorithm | 3,000 adversarial runs against correct Raft |
| halflife-gc | where an object should be born | a collector that already knows when it dies |
A regex engine with three tiers (backtracking, DFA, and machine code emitted at runtime) and a policy that promotes patterns between them based on what they have cost so far. Thompson construction, subset construction, Moore minimisation, byte class compression, then an x86-64 assembler and an independently written disassembler that checks it round trip.
The point is not the JIT. The point is the schedule. A perfect knowledge oracle computes, by prefix sums, the optimal moment to promote every pattern in a workload, and every policy is scored as a multiple of that.
| policy | cost relative to the optimum, 12 workloads |
|---|---|
| adaptive (guarded) | 1.38× |
| always compile | 12.80× |
| promote on call count | 45.06× |
| never compile | 132.73× |
464 tests. The front end is checked differentially against CPython's re on 43 patterns and 526 subjects, not against expectations I wrote myself.
An API gateway for the question overload actually poses: not whether to fail requests, but which. Adaptive concurrency from round trip latency against a decaying floor, priority shedding with a LIFO tail, deadline propagation with dead on arrival drops, retry budgets rather than retry counts. No third-party dependencies.
The headline is a negative result:
Adaptive concurrency did not beat a well tuned fixed limit. It matched it, everywhere. What it did was turn a badly tuned limit from a catastrophe into a non-event: at 12× overload with the limit set too high, 3 of 735 critical requests survived. With adaptive control, 735 of 735 did.
It is insurance, not an optimisation.
When the backend's capacity itself swings 8 to 64 to 8 workers mid run, no constant survives: the controller tracked it from 17 up to 106 and served 91% more than the limit that had been correct a moment earlier. The load generator is open loop, so latency is measured from each request's intended send time and coordinated omission cannot flatter the results.
A complete robustness verifier for ReLU networks. Every query returns a proof or a counterexample, never "unknown". DeepPoly linear relaxation with back substitution, intersected with interval propagation, then branch and bound over ReLU phases with influence guided splitting, infeasible branch pruning, and an exact affine form at fully split leaves.
| queries decided | 600 / 600, zero unknown |
| soundness failures under sampling audit | 0 |
| certified radius vs. the radius an attacker actually breaks | 0.0923 vs 0.0928, a 0.64% gap |
The interesting part is a bug I chased through three wrong hypotheses. At the leaves the bound was exact on the sub region, and then evaluated over the whole box. Minimising it over the branch polytope instead took one hard radius from 32,972 branches, 44 seconds and 2 unknowns to 114 branches, 0.5 seconds and none.
A deterministic simulator that hunts for the exact schedule of delays, crashes and partitions that breaks Raft, then shrinks it until a person can read it. Every nondeterministic choice a run makes is drawn from a plain list of integers, so a failure is a pure function of that list: it reproduces on any machine, forever, and it shrinks mechanically because zero means "nothing unusual happened".
Before any bug finding number means anything, the checkers have to be trusted, so the first experiment points all three searches at the unmodified implementation: 3,000 adversarial schedules, zero false positives. Then eight seeded defects, five of which fall over almost immediately, and three that need an interleaving random search reaches roughly never.
The stated finding is again a negative one: coverage guided search does not beat random here, and the learned bandit does not beat coverage. At two seeds it looked like a clean win for the bandit. Widening to five turned the effect into noise, which is why the table has five.
A garbage collector that predicts how long an object will live before it allocates it. A small language, a bytecode VM, four collectors, and a lifetime predictor that runs inside the allocator on every allocation. The whole experiment lives in one method, Generational.choose_space(), so any difference in the numbers is attributable to prediction quality and nothing else.
Scored on held out runs against an oracle that reads true lifetimes off a recorded trace, so "saved 4%" becomes "recovered this much of what was there to recover":
| workload | headroom recovered |
|---|---|
particles |
100% |
binarytrees |
104% |
lru_cache |
76% |
graph_bfs |
11% |
doc_pipeline |
−168%, it made things worse |
Three wins, one shrug and one clear loss, and the loss gets its own section.
- smart-mirror · real time orchestration backend fusing vision, speech, memory and third party integrations behind a shared event bus, with expensive work sampled rather than run every frame so the camera loop stays smooth.
- skin-lesion-classifier · MobileNetV2 transfer learning across 7 lesion classes on HAM10000, served over FastAPI with a Next.js front end.
- riches-garden-ganeshothsava · a production site shipped for a real committee, and used by one.
Languages Python, Go, TypeScript, JavaScript, Java, SQL, a little x86-64 ML PyTorch, TensorFlow, scikit-learn, OpenCV, numpy Systems Go concurrency, bytecode VMs, JIT code generation, abstract interpretation, deterministic simulation Web React, Next.js, Node.js, FastAPI, PostgreSQL, MongoDB