I vibe-coded jvm-hotpath to analyse my vibe-coded output.
jvm-hotpath is a JVM agent that instruments Java code and records line-level execution counts. The differentiator is the UX: it generates a single HTML report that updates continuously while your app is running. No server/dashboard — it uses JSONP + polling, so you can open it from file:// and watch hotspots move as you click around. It’s meant for local dev, and there’s a stopwatch-style lap/reset so you can zero counts, do one action, and immediately see the hot path for just that interaction.
Why this helps with “vibe coding”: when code is changing faster than your understanding (LLM-assisted or just a new/unfamiliar codebase), the hard bit is answering “what actually ran when I did this?”. This gives a quick runtime map of the paths you really exercised — and it’s also a handy way to learn a codebase by driving the app and watching what lights up.
Questions I’m curious about:
• What’s the closest thing you’ve seen to this in the JVM world?
• Where would this save you the most time: learning a new codebase, validating AI-assisted changes, refactoring safely, or chasing weird behaviour?
Project: https://github.com/sfkamath/jvm-hotpath
Documentation (README): https://github.com/sfkamath/jvm-hotpath/blob/main/README.md
Motivation: https://github.com/sfkamath/jvm-hotpath/blob/main/docs/Motiv...
Foojay article: https://foojay.io/today/runtime-code-analysis-in-the-age-of-...
Long-time HN reader, first time posting — happy to take feedback.
