4 comments

  • sfkamath 2 days ago ago

    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.

  • Martinzokov 2 days ago ago

    i'd use this as a way to find code smells where many packages depend on a single one for example

    • sfkamath 2 days ago ago

      interesting idea, thanks

  • nvd77 2 days ago ago

    Very practical!