Vekhyat Jain I build what interests me.

About

I follow my curiosity and let it lead. When something catches my attention, I get to know it by building: an app, a small utility, an automation, an experiment, or a thing I simply wanted to try.

Some of it turns into tools I keep using. Some of it stays an experiment, and there the reward was the idea itself, or that moment when I finally understood how something works underneath.

I’m drawn to the mathematics and systems under software, the parts you don’t usually see. I also build because making things is fun. Not everything needs a business case to be worth doing.

When I’m not building, I’m usually listening to something, with a coffee I brewed myself close by.

Where my curiosity goes

Machine learning and deep learning

This is the deepest basin on the map, and the direction I most want to go deeper in. What I wonder about is how a model learns at all: how weights, data, and a loss function end up with representations that recognize patterns, generate things, and make predictions.

What draws me is the mathematics underneath, and watching it slowly turn into systems that work. I’m learning it from the foundations up: reading, building small things, and taking them apart again. My part of PresentProof, the face check, puts trained models to work inside a real system, where the theory has to hold up.

Every idea you drop follows the slope downhill with momentum and a little noise, a lot like how a network’s weights move during training.

Optimizer playground

Each idea you drop is a small run of gradient descent, and these three sliders are its settings. Change them, drop a few ideas, and compare the trails. Every new idea keeps the settings it was dropped with.

The learning rate is the size of each step: too small and an idea creeps, too large and it overshoots the bottom and swings back and forth around it. Momentum is a memory of past steps that carries an idea across the flatter stretches, and with little of it an idea crawls. Noise stands in for the randomness of stochastic gradients, which come from a small batch of data rather than all of it; with none, an idea dropped from the same spot takes the same path every time, and nothing shakes it out of a shallow dip.

I’m still learning how these three pull against each other. Same hill, many ways down.

Agentic systems

I’m interested in agents that do more than answer: systems that use tools, context, and feedback to carry a task through to the end.

The part I find most interesting is coordination. When several agents split up a piece of work, how do they hand it off, report back, and know when they’re finished? agent-hub grew out of that question.

Automation

Automation sits right next door. I like connecting tools and processes so useful work happens with less repetition. A small script that quietly removes a daily chore counts, to me, as much as a larger system.

Automation and agents overlap a lot, which is why their two basins sit so close together on the map.

Audio

Outside of code, I’m deeply into audio: headphones, in-ear monitors, and all the gear around them. I can read a frequency response graph, and now and then I tune my own gear.

Audio sits right on top of things I care about anyway: signals, measurement, and perception. A graph tells you what a driver does. What you hear also depends on your own ears. My IEM listening test lives in that gap between what’s measured and what’s heard.

Turn the sound on and the map starts to hum. As an idea rolls, its pitch follows its height, and each basin plays its own note when an idea settles.

Turn sound on My gear, my tuning, and a small ear-training game

Coffee

I brew my own coffee every day, mostly pour-over and AeroPress. Grind, ratio, water temperature, time: dialling in a brew is a small optimization problem I get to solve again every morning.

It’s a small basin on the map, but I end up there every single day.

More on how I brew

The smaller basins

Plenty of things pull at me without becoming the main direction.

Theory of computation

The limits of what can be computed at all, and how efficiently.

Programming languages

How languages are designed, and why each one has its own feel.

Linux and the desktop

I run Arch Linux with Omarchy and Hyprland, and spend real time making it my own. Swipe Switcher began there.

On how I build

I usually start with a question rather than a plan. Something seems interesting, and the quickest way to understand it is to build a small version and see where it breaks.

Then I write things down. My projects keep notes on the decisions I made and why, including the ones I later reversed. Ingradient has more than twenty of them.

I try to be clear about what has been tested and what hasn’t. Not every project ends as a polished product. Some are finished, some are paused, and some were only ever meant to teach me something.

The toolkit

What I work with day to day, and what I’m learning next.

Languages

Python is my main language, the one I reach for first. I also write C and C++.

Tools

Git and GitHub, and the Linux command line.

My machine

Arch Linux with Omarchy and Hyprland.

Going deeper

Machine learning and deep learning, built up from the mathematics.

Learning next

Strengthening my React, and taking my first steps in Rust.

Things I left along the way

Each cairn on the map is a project, a small pile of stones marking where I’ve been. These five have their full story. The rest live on GitHub.

• agent-hub

  A command-line tool that lets one coding agent start others as helpers, hand them tasks, and collect their reports.

  Working and open source. Linux.

• Ingradient

  An app that reads packaged-food labels and explains their ingredients in plain words, with sources.

  In development. Android.

• PresentProof

  A team-built attendance system that makes proxy attendance hard, so being present has to mean actually being there. My part is the face check.

  Team project. Working prototype.

• Swipe Switcher

  A three-finger swipe between windows for Omarchy, with live previews that follow your fingers.

  Working and open source. Omarchy plugin.

• IEM listening test

  A listening test that estimates an in-ear monitor’s frequency response from the point where you can just hear each band.

  Working experiment. Runs offline in a browser.

Smaller things along the way: Quota, a desktop view of coding-tool usage limits; and an interactive Git guide.