Experiment, build, understand: how I pick what to work on

Published: at 03:00 AM

People sometimes ask me how the stuff I do fits together. A math-AI paper, a wearable for unhoused people, a debate website, a voice journaling app, teaching myself quantum computing, weekly painting classes. On a resume it looks scattered. From the inside it does not feel scattered at all, and I want to try to write down why, because it is also the plan for this blog.

The short version: I pick things I can experiment on, build, and then actually understand. And the question I keep asking is whether a thing really works, not whether it looks like it works.

The moment that made it click

The clearest example is my paper. I built a monitor that watched a language model’s hidden state while it solved math problems, and rolled the model back when the state drifted too far. I scored it at first by asking the model whether its own reasoning had stayed coherent. On Mistral, that score said 82 to 95 percent “recovery.” I was pretty happy.

Then I checked the final answers against the answer key. The real rate of wrong answers turning right was 5 to 20 percent. And the model gave high coherence scores to runs where I had done nothing at all.1

Bar chart comparing self-judged coherence with actual correction rates on Mistral
Red: how often the model judged its own reasoning as sound. Blue: how often a wrong answer actually turned right. The red bars are high even for the baseline, where nothing was done. Figure from my paper on residual-stream monitors.

That gap between the red bars and the blue bars is the most important thing I learned this summer. A lenient evaluation would have fooled me. It would have handed me a positive result for a method that did no better than intervening at a random spot. I wrote the whole story up in the paper post, and the paper itself is a negative result that says so in the title.

It turns out this is a known problem. Researchers have found that language models used as judges tend to favor their own outputs,2 and that LLM judges have other biases too, like preferring longer answers.3 I did not know any of that when I started. I found out the hard way, by building the thing and discovering that its reassuring score was misleading.

Marilyn Strathern’s version of Goodhart’s law puts it well: when a measure becomes a target, it stops being a good measure.4 The self-judged coherence score was a measure I was very tempted to turn into a target. The answer key was the thing I actually cared about.

Building is how I check

Richard Feynman left a line on his blackboard when he died in 1988: “What I cannot create, I do not understand.”5 I like it because it is a test you can run on yourself. If I cannot build a version of the thing, I probably only understand the description of it.

Hackathons are where I run that test the most. Here is what each one actually taught me, as opposed to what the demo showed.

HAVEN. At Milpitas Hacks I built HAVEN, a cheap ESP32 watch that shows shelter information over a mesh network with no internet, and detects falls. The demo looked great. But I was careful in the write-up to say that none of it had been tested with real users, and that a laptop stood in for the shelter beacon. A fall detector that works on a table is a different claim from one that works on someone’s wrist at 2 AM. Soldering the board also taught me something software never has: sometimes the bug is a loose wire.

Trajectory. At BISV Hacks we built Trajectory, a learning platform that draws concepts as a knowledge graph. We did not place. The part I kept was the graph itself. Once you draw compound interest next to exponential growth, you stop seeing subjects as separate boxes. Building the graph changed how I study, which no slide deck about “connected learning” ever did.

DebateSim. With Alex Liao and the team, I co-founded DebateSim, where you debate real bills against an AI. It won second place at SVCAF AI4Legislation 2025. The hard part was never making the AI sound like a debater. Language models sound like debaters by default. The hard part was making it argue from what the bill actually says, across bills that run past 40,000 characters.

DFM Voice. At the VoiceOS hackathon we turned Dear Future Me from a website with forms into an iPhone app you just talk to. What I learned there is that voice changes what people say. Typing makes me edit as I go. Talking often lets more of the unfinished thought through. You only find that out by actually using the thing, not by reading about voice interfaces.

In each case the demo only answered part of the question. The interesting part is the moment where the real behavior and the impressive behavior split apart.

Learning something is a stress test too

I co-run Programming Club at my school, where I teach Python and cybersecurity. On my own, I have been learning quantum computing, and Grover’s algorithm was the one that humbled me.

Grover’s algorithm searches an unsorted list of N items in about sqrt(N) steps, where a classical search needs around N/2 on average.6 You can memorize that sentence in five seconds. For a while that is all I had. I could recite the circuit and I could not explain why it works, which left a gap I wanted to close.

What finally made it make sense to me was the geometry.

Diagram of Grover's algorithm as a rotation: the state vector s is reflected about s-prime and then about s, rotating it toward the target state omega by angle theta
Grover's algorithm as a rotation. Each step is two reflections, and two reflections make a rotation toward the answer. Image: Danski14, CC BY-SA 3.0, via Wikimedia Commons.

The state starts almost flat, nearly all “wrong answer.” Each step flips it across one line and then across another, and two flips make a small rotation toward the right answer. Repeat about sqrt(N) times and you are pointing almost straight at it. Overshoot, and you rotate past it. That last part is the one people remember, because it is so unlike how classical search behaves.

Explaining it to myself, out loud, works like an evaluation with an answer key. If I get stuck halfway through, I did not understand it yet. No amount of confident wording changes that.

Painting, of all things

I take weekly studio classes, and some of what I make is in the gallery. This sounds unrelated, and I used to think it was. Painting gives me another way to practice the same loop.

You look at something. You put down what you think you see. Then you step back and compare, and almost always the shadow is the wrong color or the proportions are off. The painting looked right while I was making it. It does not look right next to the real thing. Painting trains you to distrust your first impression, which is exactly the skill I needed when that coherence score was telling me what I wanted to hear.

The rule, written down

For now, these are the questions I use to pick what to work on.

  1. Can I experiment on it? There has to be something I can poke and get a real response from. An answer key, a user, a circuit, a canvas.
  2. Can I build a version of it? Even a bad one. Building is how I find out which parts I only thought I understood.
  3. Can I tell if it really works? For a method meant to improve a result, I want to compare it with doing nothing and with a simple baseline. If I cannot set up that check, I am probably about to fool myself.

The third one matters most to me. I do not think “does it look like it works” is a bad question. It is just a different question, and it is very easy to answer it and think you answered the other one.

What this blog is going to cover

I want to write about the things I can get my hands on: small neural networks, the parts inside language models, agents that use tools, and quantum algorithms I can work through in a simulator. The questions will probably overlap. Trying to understand one system often exposes something I hadn’t noticed about another.

The posts should let you follow that process without needing every detail at once. I’ll explain the part that made an idea click, show an example when it helps, and leave room for questions I haven’t answered. You can find more about me on the about page and the longer projects on the research page.

Sources

Footnotes

  1. Arnav Kakani and Mrinal Agarwal, “Detecting and Correcting Reasoning Failures: A Controlled Negative Result for a Residual-Stream Monitor,” MATH-AI workshop, NeurIPS 2026. Write-up: /posts/math-ai-residual-stream-monitor ↩

  2. Arjun Panickssery, Samuel R. Bowman, and Shi Feng, “LLM Evaluators Recognize and Favor Their Own Generations,” arXiv:2404.13076, 2024, https://arxiv.org/abs/2404.13076 ↩

  3. Lianmin Zheng et al., “Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena,” NeurIPS 2023 Datasets and Benchmarks, arXiv:2306.05685, https://arxiv.org/abs/2306.05685 ↩

  4. Marilyn Strathern, “‘Improving ratings’: audit in the British University system,” European Review 5(3), 1997, pp. 305-321, https://doi.org/10.1002/(SICI)1234-981X(199707)5:3%3C305::AID-EURO184%3E3.0.CO;2-4 ↩

  5. “Richard Feynman’s blackboard at time of his death,” 1988, Caltech Archives, Images Collection 1.10-29, https://digital.archives.caltech.edu/collections/Images/1.10-29/ ↩

  6. Lov K. Grover, “A fast quantum mechanical algorithm for database search,” Proceedings of the 28th Annual ACM Symposium on Theory of Computing (STOC), 1996, pp. 212-219, arXiv:quant-ph/9605043, https://arxiv.org/abs/quant-ph/9605043 ↩