4 pointsby sfkamath4 hours ago3 comments
  • sfkamath4 hours 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.

  • Martinzokov2 hours ago
    i'd use this as a way to find code smells where many packages depend on a single one for example
    • sfkamathan hour ago
      interesting idea, thanks
  • nvd773 hours ago
    Very practical!