<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: nero bowman</title>
    <description>The latest articles on DEV Community by nero bowman (@nero_bowman_874ad8c24862e).</description>
    <link>https://dev.to/nero_bowman_874ad8c24862e</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3797024%2F840050ee-929e-410f-8987-e0e43dfb903c.png</url>
      <title>DEV Community: nero bowman</title>
      <link>https://dev.to/nero_bowman_874ad8c24862e</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/nero_bowman_874ad8c24862e"/>
    <language>en</language>
    <item>
      <title>Showcase Tuning: A Visual Debugging Workflow for AI-Assisted Rendering Code</title>
      <dc:creator>nero bowman</dc:creator>
      <pubDate>Fri, 27 Feb 2026 20:03:14 +0000</pubDate>
      <link>https://dev.to/nero_bowman_874ad8c24862e/showcase-tuning-a-visual-debugging-workflow-for-ai-assisted-rendering-code-516k</link>
      <guid>https://dev.to/nero_bowman_874ad8c24862e/showcase-tuning-a-visual-debugging-workflow-for-ai-assisted-rendering-code-516k</guid>
      <description>&lt;p&gt;Rendering code has a testing problem that most developers quietly accept: &lt;br&gt;
you can write all the unit tests you want, but none of them tell you whether &lt;br&gt;
the output actually &lt;em&gt;looks right&lt;/em&gt;.&lt;/p&gt;

&lt;p&gt;Unit tests verify logic. They can't catch inverted normals, clipped sprites, &lt;br&gt;
washed-out colors, or a balloon shape that looks like a UFO.&lt;/p&gt;

&lt;p&gt;So I built a workflow called &lt;strong&gt;Showcase Tuning&lt;/strong&gt; to solve this - and packaged &lt;br&gt;
it as a Claude Code skill so AI can run the entire loop autonomously.&lt;/p&gt;


&lt;h2&gt;
  
  
  The Core Idea
&lt;/h2&gt;

&lt;p&gt;The workflow is a tight loop:&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;&lt;strong&gt;Write a harness → Run it → Look at what came out → Fix the renderer → Repeat&lt;/strong&gt;&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;The harness is a small, standalone program that calls your &lt;em&gt;actual&lt;/em&gt; rendering &lt;br&gt;
code with deterministic inputs and saves the output as a PNG. It's not a mock &lt;br&gt;
or reimplementation - it's a camera pointed at your real code.&lt;/p&gt;

&lt;p&gt;A few rules keep the loop honest:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;
&lt;strong&gt;Deterministic inputs&lt;/strong&gt; - fixed seeds and hardcoded data so every run 
is comparable&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;Fix the renderer, not the harness&lt;/strong&gt; - the harness is just a capture 
mechanism; defects live in the rendering code&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;Generate before reviewing&lt;/strong&gt; - never guess what the output looks like; 
always produce the image&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;One component at a time&lt;/strong&gt; - isolation keeps feedback tight and results 
unambiguous&lt;/li&gt;
&lt;/ul&gt;


&lt;h2&gt;
  
  
  A Real Example
&lt;/h2&gt;

&lt;p&gt;Here's what a session looks like. I used it to fix a hot air balloon renderer &lt;br&gt;
in an Android/Kotlin project.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Step 1 - Initial inspection&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Claude runs the harness for the first time. The balloon is a plain oval with &lt;br&gt;
only 2 of 5 color palettes rendering. Claude identifies 6 distinct issues: &lt;br&gt;
wrong shape, missing palettes, short ropes, no gore lines, plain basket, &lt;br&gt;
no skirt.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F5dv3i75jldq693y0jkrc.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F5dv3i75jldq693y0jkrc.png" alt="Step 1" width="800" height="311"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Step 2 - First round of fixes&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;All 5 palettes now render. Basket, gore lines, and ropes are present. But &lt;br&gt;
the envelope looks like a diamond - a symmetric sine profile is the culprit.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fbi7h051h6njj9x90f35n.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fbi7h051h6njj9x90f35n.png" alt="Step 2" width="800" height="310"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Step 3–4 - Diagnosing and redesigning the shape&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Claude traces the problem to &lt;code&gt;buildEnvelopePath&lt;/code&gt;, rewrites the profile curve. &lt;br&gt;
The shape improves but is still too squat.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fmodi88auz7mgn8gwkp5r.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fmodi88auz7mgn8gwkp5r.png" alt="Step 4" width="800" height="358"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Step 5–6 - Final refinements&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Height ratio adjusted. Basket positioning fixed - it was floating too far &lt;br&gt;
below the envelope. The skirt now flows into short ropes into the basket. &lt;br&gt;
All 5 palettes render correctly. Session complete.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Foalhslb6oungf0y7oafi.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Foalhslb6oungf0y7oafi.png" alt="Step 6" width="800" height="355"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;The whole thing - from a broken oval to a finished balloon - took a few &lt;br&gt;
minutes of iterative AI-driven debugging instead of hours of manual inspection.&lt;/p&gt;


&lt;h2&gt;
  
  
  The Claude Code Skill
&lt;/h2&gt;

&lt;p&gt;The repo includes a &lt;code&gt;SKILL.md&lt;/code&gt; file for &lt;a href="https://claude.ai/code" rel="noopener noreferrer"&gt;Claude Code&lt;/a&gt; &lt;br&gt;
that implements the full workflow as an agentic loop. You just describe what &lt;br&gt;
to focus on:&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;showcase tune the particle system
showcase the tile map renderer at night
showcase the character sprite with all animation frames
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;Claude reads the rendering code, writes the harness, runs it, inspects the &lt;br&gt;
images, traces defects to their source, fixes them, and re-runs until the &lt;br&gt;
output passes visual review.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Platform support&lt;/strong&gt; is built in - Android/JVM, Web/TypeScript, Python, &lt;br&gt;
Rust/C++.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Output&lt;/strong&gt; goes to a &lt;code&gt;Showcase/&lt;/code&gt; directory (auto-added to &lt;code&gt;.gitignore&lt;/code&gt;).&lt;/p&gt;




&lt;h2&gt;
  
  
  Why This Fills a Real Gap
&lt;/h2&gt;

&lt;p&gt;I checked existing Claude Code skills and tooling before building this - &lt;br&gt;
there's nothing that specifically targets the visual rendering debugging loop. &lt;br&gt;
Most AI coding workflows assume textual output: test passes/failures, console &lt;br&gt;
logs, type errors. Showcase tuning is built around the case where the artifact &lt;br&gt;
is an &lt;em&gt;image&lt;/em&gt; and "correct" means "looks right."&lt;/p&gt;




&lt;h2&gt;
  
  
  Get It
&lt;/h2&gt;

&lt;p&gt;👉 &lt;a href="https://github.com/nerobowman/Showcase-tuning" rel="noopener noreferrer"&gt;github.com/nerobowman/Showcase-tuning&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;The skill behavior lives entirely in &lt;code&gt;SKILL.md&lt;/code&gt; - easy to read, extend, &lt;br&gt;
and adapt to your stack. Contributions welcome.&lt;/p&gt;




&lt;p&gt;&lt;em&gt;Have you hit this problem with rendering code before? Curious how others &lt;br&gt;
have approached visual debugging with or without AI.&lt;/em&gt;&lt;/p&gt;

</description>
      <category>claudecode</category>
      <category>ai</category>
      <category>debugging</category>
      <category>devtools</category>
    </item>
  </channel>
</rss>
