<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Suneet Kamath on foojay.io - Friends of OpenJDK</title><link>https://foojayio.github.io/website/today/author/suneet-kamath/</link><description>Articles written by Suneet Kamath on foojay.io - Friends of OpenJDK</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Tue, 17 Feb 2026 14:00:00 +0000</lastBuildDate><atom:link href="https://foojayio.github.io/website/today/author/suneet-kamath/index.xml" rel="self" type="application/rss+xml"/><item><title>Runtime Code Analysis in the Age of Vibe Coding</title><link>https://foojayio.github.io/website/today/runtime-code-analysis-in-the-age-of-vibe-coding/</link><pubDate>Tue, 17 Feb 2026 14:00:00 +0000</pubDate><guid>https://foojayio.github.io/website/today/runtime-code-analysis-in-the-age-of-vibe-coding/</guid><description>&lt;p&gt;In the era of &lt;strong&gt;vibe coding&lt;/strong&gt;&amp;mdash;where large amounts of code are introduced or refactored in short bursts, often with the help of LLMs&amp;mdash;you need immediate feedback on how new logic actually executes. Not comprehensive analysis. Not nanosecond-precise timing. Just a quick confirmation that your loops aren&amp;rsquo;t spinning 10,000x more than they should.&lt;/p&gt;
&lt;p&gt;However, traditional profilers can feel like overkill for quick validation. In addition, they present results at method/stack granularity and require context-switching to interpret. They also introduce overhead, ranging from negligible (e.g., JFR/sampling) to noticeable (call tracing/instrumentation). As a result, they are less convenient as always-on feedback during rapid iteration.&lt;/p&gt;</description></item></channel></rss>