B.E. Computer Engineering · Thapar Institute of Engineering & Technology · Patiala

Software, built with structure, context, and execution.

I'm a computer-science student who ships practical software. I work with a disciplined AI-assisted workflow, self-hosted cloud infrastructure, shared context across tools, and human judgment on quality and security.

View my work → See how I build ↓
Self-hostedOwn cloud VMs
FinalistNational hackathon
5×NVIDIA DLI certs
01 / Identity

A builder who cares about the whole system, from first commit to a running server.

I started programming because I wanted to understand how things actually work, then kept building until the process itself became the thing I enjoyed most.

Most of what I know, I learned by building and breaking real things: shipping features, tracing bugs to their root, standing up servers, and cleaning up my own mistakes. Somewhere along the way the interesting part stopped being individual snippets of code and became the system around the work, how context flows, how decisions get recorded, how something moves from an idea to a running service.

I think in workflows. I keep a centralized context so my tools don't repeat each other, I document decisions as I make them, and I treat security and correctness as steps I don't skip. I use AI to move faster, but I own the final code, its quality, its security, and whether it actually holds up.

What I can say plainly: I know how to organize real engineering work, deploy it, and keep it running, and I get sharper with every project.

02 / Selected work

A few things worth showing, not everything I've built.

Fewer projects, more depth. Each is here for the judgment and engineering it took, not to pad a list. Open one to read the short case study.

The problem

Most simple combat agents are scripted or reward-blind: once you find a pattern they stop adapting and become memorization. Mahoraga is an environment built to make adaptation, reward shaping, and agent behavior inspectable turn by turn, not a black box.

What made it interesting

A FastAPI backend exposing reset / step / model-status served a 4-bit-quantized Qwen2.5-3B LoRA agent with a rule-based fallback, deployed to Hugging Face Spaces via a multi-stage Docker build. The agent was fine-tuned with an iterative reward-weighted SFT loop (Unsloth + TRL) using rejection sampling and expert-trajectory seeding over five training rounds.

PythonFastAPIDockerQwen2.5-3BLoRA · Unsloth · TRLGymnasiumReactHugging Face Spaces

National in-person finalist, backed by a compact, testable environment with 33 unit tests over its mechanics and reward logic.

View on GitHub

The problem

The knowledge to answer "why did pump P-204A fail twice this month?" is scattered across manuals, work orders, inspection reports, SOPs, and incident logs. Finding it means digging through all of them by hand, and a wrong answer on a plant floor is expensive.

What made it interesting

A FastAPI backend doing GraphRAG: pgvector semantic search over ingested documents plus a NetworkX knowledge graph with multi-hop asset → document → failure links. Three grounded agents (root-cause, compliance-gap, lessons-learned), a no-source-no-answer guardrail, and retrieved text treated as untrusted input to defend against prompt injection. Every response is structured JSON: answer, confidence, citations, missing evidence, and next actions. Embeddings run locally; the LLM is swappable between a free hosted tier and local Ollama.

FastAPIPostgreSQL · pgvectorNetworkXPyMuPDF · OCRfastembedGroq · OllamaRailway

Measured with RAGAS: 100% top-5 retrieval hit-rate, 0.82 answer faithfulness, ~3.9s to answer versus ~12 minutes of manual search. Built at a hackathon by two; I led the backend and applied-AI core.

View on GitHub Live demo

What it does

A full community toolkit: music, leveling, moderation, and admin tooling, maintained continuously in production rather than shipped once and forgotten. Long enough in service that the interesting work became keeping it fast and stable under real load.

What made it interesting

A Lavalink / wavelink music pipeline, and a migration of core database access from synchronous psycopg2 to async pooling (aiopg / asyncpg) to stop the event loop from blocking. Leveling renders rank cards on the fly with Pillow, and a hot cog load / unload / reload interface allows updates without downtime.

Pythonpy-cordPostgreSQLLavalink · wavelinkasyncpgPillow

Six years in production across 25+ cogs and 70+ commands, still serving its community today.

View on GitHub
03 / Experience & credentials

Where I have worked, and what I have earned.

Experience
Intern · ELC Summer ProgramJun–Jul 2025
Thapar Institute of Engineering & Technology · Patiala
  • Engineered a prototype to capture real-time traffic data from IoT sensors and cameras.
  • Applied SAC reinforcement learning for adaptive traffic-signal control, improving throughput ~75% and doubling average vehicle speed in rush-hour simulations.
  • Cut average trip time ~30% versus fixed-timer baselines across 4 SUMO scenarios, with a web dashboard for live KPI monitoring.
SAC · RLIoT sensorsComputer visionSUMOLive dashboard
B.E. Computer Engineering · Thapar Institute · 2023–2027 · CGPA 8.01/10 (till Sem VI)
Credentials · NVIDIA DLI
Fundamentals of Accelerated Computing with CUDA PythonNVIDIA · Apr 2026
Verify
Getting Started with AI on Jetson NanoNVIDIA · Feb 2026
Verify
Getting Started with Accelerated Computing in Modern CUDA CNVIDIA · Feb 2026
Verify
Generative AI with Diffusion ModelsNVIDIA · Dec 2025
Verify
Getting Started with Deep LearningNVIDIA · Sep 2025
Verify
5 certifications · NVIDIA Deep Learning Institute
04 / How I build

A development system, not a pile of AI tools.

Ignoring AI in 2026 is a mistake. Leaning on it without research or judgment is a bigger one. So I do both, I understand the problem myself, then use AI to move fast on the parts that shouldn't be slow.

01

I do the thinking first. I dig into the problem, read the docs, and form a direction myself. I don't outsource understanding, that's the part that's actually mine.

02

Then AI does the heavy lifting. With sharp prompts and full project context, I use it to accelerate the build, not to decide what to build or to hand me code I can't read.

03

Every tool shares one brain. Claude, Antigravity, and Codex all read the same context and write to the same log, so nothing repeats and nothing gets lost between them.

Two shared files in .ai-sync/, read and written by every tool
context.mdRolling log of every action, decision, and fix, across tools.
Shared history
handoff.mdActive handoff: current task, what's in progress, next steps.
Live state
Tool-specific instruction files
ClaudePrimary
CLAUDE.md

My main driver: coding, architecture, and reasoning across the whole system. Most of the build runs through here.

Antigravity
GEMINI.md

My Gemini-powered agentic IDE for frontend and UI. I reach for it on interface work, visual iteration, and a fresh second angle.

Codex
AGENTS.md

Scoped implementation and quick edits: an extra set of hands and a cross-check on focused tasks.

The pipeline · click any stage

A shared decision log. Every action, fix, and issue gets written down, so any tool, or me next week, can pick up exactly where things left off.

One tool can request another's opinion; the answer lands in the same log. No repeated work, no wasted tokens, no lost reasoning between tools.

Before anything is published I review the diff for exposed secrets and obvious risks. Secrets live in gitignored env files, never in the repo.

The final gate is me reading the code, confirming it does what it should, then committing and deploying. The tools accelerate; the judgment stays mine.

I use AI to cut repetition and raise throughput, but I keep ownership of the final code, its security, and its quality.

05 / Infrastructure

I deploy and run what I build.

Not one-click-and-forget. My projects run on Ubuntu VMs I provision and manage myself, with the application and database deliberately kept on separate hosts.

The app is hosted on an Oracle Cloud Ubuntu VM. The database is a self-hosted PostgreSQL instance on its own Ubuntu VM, currently on Google Cloud, separated on purpose, so application and data have independent lifecycles, networking, and failure domains.

Running my own machines means I actually deal with the parts a managed platform hides: SSH, firewall rules, updates, service management, connection strings, and backups. It's more work, and that's the point, it's where the real systems understanding comes from.

I'd rather understand a system end-to-end than push to a platform and forget it exists.

Local developmentLaptop · Git
Build
GitHubVersion control · public & private
Source
Deploys to ↓
Oracle Cloud · Ubuntu VMApplication host
App
Google Cloud · Ubuntu VMPostgreSQL · separate host
Data
06 / Engineering stack

Tools I actually reach for.

Grouped by what they're for, not listed as a badge wall. Each cluster is a part of how the work gets done.

01
Primary language

Python

Where most of my backend work lives. From there I move across the stack, systems-level in C++, and full-stack web in the JavaScript world.

PythonC++JavaScript
02
Lead tool

Claude

Three assistants, one shared brain. Claude leads the build; Antigravity covers frontend; Codex fills in scoped work, all coordinated through shared context and handoff files so nothing repeats.

ClaudeAntigravityCodexcontext.md & handoff.md/sync commands
03
Runs on

Ubuntu + PostgreSQL

Software that actually runs somewhere, on VMs I provision and manage myself. Application and database deliberately split across two clouds.

UbuntuOracle Cloud VMGoogle Cloud VMPostgreSQLGitHubCloud deployment
04
Non-negotiable

Security review

The habits that keep the work trustworthy over time, checked before anything ships, not assumed on the way out.

Security checksManual secret reviewVersion controlStructured handoffsDebuggingDocumentationIterative improvement
07 / Cross-agent sync, live

Watch the handoff happen.

A small extra. A live re-enactment of the cross-tool handoff described above, not a screen recording. Real files, real steps, one shared context.

01 · PromptPaste the brief

The full portfolio brief goes into Claude Opus 4.8, in plan mode.

plan mode
02 · PlanPlan first

Claude plans the whole build, and I approve it, before a line is written.

plan approved
03 · Write filesBuild + log

It writes the site and seeds the shared .ai-sync files both tools read.

context.md · handoff.md
04 · HandoffSwitch tools

From the taskbar I open Antigravity on the very same repo.

same context
05 · ContinuePick up clean

Antigravity reads handoff.md, picks up mid-task, and fixes the nav alignment bug.

nothing lost
08 / Build philosophy

What I care about when I build.

01

Centralize context

One source of truth every tool reads, so nothing gets re-derived or repeated.

02

Document decisions

Write down the why as it happens. A clear log is worth more than perfect memory.

03

Amplify, don't outsource

AI speeds up output; it doesn't replace understanding what the code does.

04

Verify before pushing

Security and correctness get checked at the gate, never assumed on the way out.

05

Own the full system

From local code to a running server, I'd rather understand the whole path.

06

Clean over clever

Prefer quiet, correct execution to noisy complexity that impresses no one useful.

Development journey
2020

First things that ran

Picked up programming to understand how software actually works, and started the Discord bot that is still in production today.

2023

Engineering school

Started B.E. Computer Engineering at Thapar, and began shipping projects end to end, learning as much from what broke as from what worked.

2024

AI tools, used with intent

Started using AI assistants deliberately, coordinating them instead of prompting at random.

2025 · early

Shared context & logs

Introduced centralized context and a shared log so tools hand off cleanly and decisions stay recorded.

2025 · late

Self-hosting

Moved from localhost to real infrastructure, provisioning and running services on my own cloud VMs.

2026 · now

Complete software systems

Building more complete systems, with the process, infrastructure, and review discipline to back them.

09 / Contact

Let's build something useful.

Open to internships, collaboration, and meaningful engineering work. If you're looking for someone who treats building as a system, not just typing code, let's talk.

GitHub LinkedIn Email Résumé