<?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://foojay.io/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://foojay.io/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://foojay.io/today/runtime-code-analysis-in-the-age-of-vibe-coding/</link><pubDate>Tue, 17 Feb 2026 14:00:00 +0000</pubDate><guid>https://foojay.io/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;—where large amounts of code are introduced or refactored in short bursts, often with the help of LLMs—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;&#10;&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>