DEV Community: dhq_boiler

I built an AI-collaborative UML editor that puts 💩 on smelly code

dhq_boiler — Tue, 18 Aug 2026 11:09:32 +0000

TL;DR — I really just wanted to put 💩 icons on UML class diagrams. Along the way it turned into Kata, a two-way class diagram editor for C# / C++/CLI solutions that (1) detects 22 out of Fowler's 24 code smells and pins a 💩 badge to the exact type or member, (2) lets you fire Fowler-catalog refactorings straight from the diagram and writes them back into the source, and (3) forwards "I don't know how to fix this" to Claude Code / Codex CLI and previews the returned unified diff before applying.

Site: https://kata.dhq-boiler.dev/ · Repo: https://github.com/dhq-boiler/Kata

Why I built it

I know the Refactoring book. I've read Refactoring the way most of us have — I can name Extract Method, I can spot a big switch statement, and I nod when someone says "feature envy". But knowing the catalog and actually running through it on a real codebase are two different sports.

The gap for me was step zero: finding code smells at all. Once you know a method reeks, half the fight is over. The catalog tells you what to do next. But there's no "smelly bit" indicator on a real project — you just stare at 200,000 lines and hope a bad smell walks up and introduces itself.

So the pitch was really that literal:

If I could see a 💩 icon sitting on top of the classes that need attention, the rest of the workflow would fall into place.

That's it. The editor grew around that one need.

The core workflow

Human — opens the class diagram, scans for 💩 badges (the tool does this part).
AI — applies the refactoring recipe (Claude Code or Codex, whichever you already pay for).
Human — reviews the diff and clicks Apply.

The important bit is that humans stay in the review seat. AI never writes to disk without you seeing the exact diff first.

What the tool actually does

1. `.sln` / `.slnx` → live class diagram

Open a solution, get a real class diagram back. Symbol resolution is done through Roslyn for C# and through a hand-written semantic layer (Kata.Cpp) for C++/CLI, so mixed-language WPF-plus-native-library projects render correctly.

2. Ctrl+Click navigation (cross-language)

Click any type or member to jump to its definition. C# ↔ C++/CLI navigation works both ways — chase a P/Invoke or a ref class from either side.

3. Fowler refactorings, driven from the diagram

Right-click a class → pick a refactoring → Kata rewrites the source. The current set covers Extract Method / Extract Interface / Extract Class, the whole Rename family (type / member / field / parameter), Move Method / Move Field, Extract Hierarchy, and more.

The same operations are exposed as MCP tools, so an external agent (Claude Code, Codex, or anything speaking MCP) can drive Kata programmatically the same way a human does from the UI.

4. Code-smell analyzer + 💩 badges

22 of Fowler's 24 smells are implemented as deterministic detectors that run over the semantic model. Results show up in two places:

top-right of a type node for type-level smells (God Class, Data Class, Feature Envy…)
end of a member row for member-level smells (Long Method, Long Parameter List, Divergent Change…)

Tiered badges — the more severe ones get a rainbow halo — so a screen full of nodes reads at a glance.

5. AI-generated diffs, with preview

Two AI paths, both piggy-backed on your existing subscription:

claude -p "<prompt>" — Claude Code CLI (headless mode)
codex exec "<prompt>" — Codex CLI

Kata builds the prompt from (the smell, the enclosing type / member source, the catalog recipe for that smell, and a strict "return a unified diff" instruction), runs it, parses the returned diff, and drops you into a preview dialog. Nothing hits disk until you approve.

Two design choices that matter here:

No API key management. You're not billed by Kata — it uses whatever Claude / ChatGPT plan you already have.
Deterministic first, AI second. For a growing set of categories (currently 20 rewriters across three tiers) Kata has an in-tool Roslyn rewriter that produces the exact same diff without hitting the network. For the harder cases (data-flow, cross-file design changes) it falls back to the AI path.

There's also a behavior-change caution pane in the diff preview when a fix is technically correct but semantically shifts something — e.g. OrderBy(...).FirstOrDefault() → MinBy(...) throws on empty sequences where the original returned default(T). That's the kind of "the diff is right, please just be aware" moment that a plain patch view swallows.

Architecture, briefly

Source is SSOT. Kata is a mirror of the codebase. Only pure UI state (node positions, zoom, filter selections) lives in a side file.
Intent-driven. Every user action becomes a strongly-typed Intent (RenameIntent, ExtractMethodIntent, PerfFixIntent, …). Language-specific adapters translate intents into source edits. Both the UI and the MCP surface fire the same intents through the same handlers.
MCP externalized. Kata.Mcp runs over Streamable HTTP + stateless, so a Kata.App user and one or more AI agents can all talk to the same live model without sessions fighting each other.
Language-neutral core. Kata.Core has no dependency on any language adapter. Adding a new language means implementing ILanguageAdapter plus a smell detector set, not editing the core. C# is the mature adapter today; Java is next up (JDT-Core-based load benchmarked at 4.6 s for a large real project).

Perf note: rendering a live class diagram of a big solution used to hitch hard because Nodify wants to materialize every visual up front. VirtualizingNodifyCanvas (a "realize-all, measure-only-viewport" trick) took that hitch from ~845 ms to invisible without breaking Nodify's null-unsafe container assumptions.

Trying it out

Requirements: .NET 10 SDK on Windows (WPF).

git clone https://github.com/dhq-boiler/Kata
cd Kata
dotnet build Kata.slnx
dotnet run --project src\Kata.App\Kata.App.csproj

After the app launches, use File → Open Solution to point at any .sln / .slnx. The rendered graph is your live model — everything you click on will call back into the source.

If you prefer an installer, the site links to signed Setup.exe / portable zip builds with auto-updates via Velopack.

Licensing

Community build — PolyForm Noncommercial 1.0.0. Free for personal use, learning, research, hobby projects.
Commercial use — needs a Pro license (Lemon Squeezy, one-time buyout or per-seat).
AI cost — you own the Claude / Codex subscription. Kata never bills you for tokens. The monthly quota you'll see in the Community build isn't a cost gate, it's a "please try Pro for heavy workloads" gate.

Roadmap

Near-term:

Team Collab — team-lead workflows: author a refactor instruction packet, hand it to the team with impact focus visualization and diff previews, get consistent execution across contributors.
More language adapters — Java is next (in progress), then Kotlin and TypeScript.
Beyond class diagrams — sequence diagrams and state diagrams, mostly to reuse the same intent-driven refactoring plumbing on a wider slice of the codebase view.

Feedback wanted

Bug reports, especially reproduction samples for C++/CLI mixed solutions, are welcome — that's the corner where semantic resolution has the most sharp edges.

Site: https://kata.dhq-boiler.dev/
Community repo: https://github.com/dhq-boiler/Kata
Pro: https://kata.dhq-boiler.dev/pro

If you try it and it puts 💩 on the exact class you were already avoiding, I want to hear about that too.

I Gave Claude Access to Windows Calculator via MCP — Then Watched It Catch Its Own Hallucination

dhq_boiler — Wed, 03 Jun 2026 09:19:48 +0000

TL;DR — I built an MCP server that lets Claude drive Windows desktop apps (UI Automation + screen capture + OCR + Visual Studio debugger). In a black-box test of Windows Calculator, the agent falsely flagged a "display bug" based on the AccessibleName string. When I told it to look again, it captured the real screen, compared its earlier claim against the pixels, and retracted its own finding. The retraction was the moment I knew this was worth shipping.

The moment

The agent was 30 minutes into autonomously poking at Windows Calculator. It had verified divide-by-zero, the old √4 − 2 precision bug, 0^0, overflow, error recovery. All green.

Then it stopped. New message:

"Sensei, the history shows √(4) マイナス ( 2= 0. There's an unclosed opening paren ( right after the minus sign. The result 0 is correct, but the expression display looks wrong. Possible display bug."

I looked at my actual calculator window. The history line read √(4) - 2 = 0. No stray paren. Nothing wrong.

So I typed back two words:

"Look again."

What happened next is the reason I'm writing this post.

What is this thing

JidoDebugger is an MCP server I've been building. It gives AI agents like Claude Code, Cursor, Codex, and Copilot the ability to drive Windows desktop applications — not just read about them, but actually click buttons, type into fields, capture the screen, run OCR, attach the Visual Studio debugger, set breakpoints, evaluate expressions, and write the results back to disk as xUnit/NUnit/MSTest skeletons.

Two modes:

Black-box — you give the agent a window title. It attaches via UIA, surveys the element tree, and starts poking. No source code required. Useful for testing third-party apps, regression-checking your shipped product, or — as in this post — testing Windows Calculator.
White-box — you point it at your solution. It cross-references UI elements with source code, sets breakpoints at the offending callback, steps through, dumps locals, and writes a repro.zip.

The 45-ish MCP tools roughly cluster as: UIA driving, screen capture & OCR, finding/recording, crash watching, accessibility audit, Visual Studio debugger control.

This post is about the black-box mode and one specific session.

The black-box session, condensed

I'll show the actual tool calls. They're verbatim from the session log — the agent decided what to call, I just watched.

Attach

start calc.exe
uia_attach_title { windowTitle: "電卓" }
  → sessionId u1
uia_survey { sessionId: "u1", maxResults: 200 }
  → 64 elements. num0Button..num9Button / squareRootButton /
    powerButton / powerOf10Button / factorialButton /
    CalculatorResults / CalculatorExpression

Two automation IDs matter:

CalculatorResults — the main display
CalculatorExpression — the expression line above it

Note: this session was run against Japanese Windows, so the UIA Name strings below contain Japanese fragments like 表示は ... です ("the display is ...") and マイナス ("minus"). The hallucination-vs-pixels divergence is locale-independent — it just happens that the punchline string in this run is Japanese.

Test 1: Divide by zero

uia_press_key { sessionId: "u1", keyName: "Escape" }
uia_type_text { sessionId: "u1", text: "1/0" }
uia_press_key { sessionId: "u1", keyName: "Enter" }
uia_find_elements { sessionId: "u1", automationId: "CalculatorResults" }
  → Name: "Cannot divide by zero"

✅ Handled.

Test 2: The old `√4 − 2` precision bug

Years ago, the calculator's floating-point engine would return something like -1.068281969439142e-19 instead of 0 for √4 − 2. Modern Calculator uses an arbitrary-precision engine. Let's confirm.

uia_press_key { sessionId: "u1", keyName: "Escape" }
uia_type_text { sessionId: "u1", text: "4" }
uia_invoke    { sessionId: "u1", automationId: "squareRootButton" }
uia_type_text { sessionId: "u1", text: "-2" }
uia_press_key { sessionId: "u1", keyName: "Enter" }
uia_find_elements { sessionId: "u1", automationId: "CalculatorResults" }
  → Name: "Display is 0"

✅ Fixed.

Test 3: `0^0`

uia_type_text { sessionId: "u1", text: "0" }
uia_invoke    { sessionId: "u1", automationId: "powerButton" }
uia_type_text { sessionId: "u1", text: "0" }
uia_press_key { sessionId: "u1", keyName: "Enter" }
  → "Display is 1"

✅ Conventional 0^0 = 1.

Tests 4–5: Overflow + error recovery

Both behaved correctly. Skipping the listings for brevity (10^100000 → "Invalid input", and pressing +5= from the error state cleanly resets to 5).

So far, the agent had run five test cases against a black box, autonomously chosen the inputs based on its knowledge of historical calculator bugs, and reported no defects. Fine. This is the boring part.

Then it looked at the history pane.

The hallucination

uia_find_elements { sessionId: "u1", controlType: "ListItem", maxResults: 30 }
  → "√(4) マイナス ( 2= 0"

uia_find_elements { sessionId: "u1", automationId: "CalculatorExpression" }
  → Name: "式は √(4) マイナス ( 2= です"

The agent's reasoning, paraphrased from its own message:

The expression's Name property contains the substring マイナス ( 2.
That's "minus, open-paren, two" — an unclosed paren after a minus sign.
The calculator's expression display is therefore malformed.

This is the kind of finding that sounds right. The string literally contains ( in a place where the expression √(4) - 2 = has no (. If you trust the tool output, you write a bug report.

I didn't trust the tool output. I'd been looking at my actual calculator window the whole time. The history said √(4) - 2 = 0 with no stray paren. Whatever the agent was looking at, it wasn't the same thing my eyes were seeing.

So I said: "Look again."

The self-correction

The agent's response, paraphrased:

"You're right — I should not have reported based on the UIA Name alone. UIA Name strings are normalized for screen readers and can diverge from the rendered pixels, especially when symbols are involved. Let me verify against the real screen."

What it did:

uia_press_key { sessionId: "u1", keyName: "Escape" }
uia_type_text { sessionId: "u1", text: "4" }
uia_invoke    { sessionId: "u1", automationId: "squareRootButton" }
uia_invoke    { sessionId: "u1", automationId: "minusButton" }

# Attach a *second* session, this time for Windows Graphics Capture
attach_to_title { windowTitle: "電卓" }
  → sessionId s1  (kind: gui)

capture { sessionId: "s1", maxWidth: 800, format: "png" }
ocr     { sessionId: "s1", language: "ja-JP" }
  → OCR reads "(4" cleanly, but symbols are ambiguous at this resolution

OCR wasn't decisive. So it cranked the resolution, saved the PNG, and read the image file with its own multimodal vision:

uia_type_text { sessionId: "u1", text: "2" }
uia_press_key { sessionId: "u1", keyName: "Enter" }

capture { sessionId: "s1", format: "png" }   # full-res
# (Save base64 to calc_expr.png on disk)
Read { file_path: "calc_expr.png" }
  → Both the main expression line and the history show
    "√(4) - 2 ="  with no extra paren anywhere.

Here is the actual capture (re-run today to verify the divergence still reproduces on Windows 10.0.26100.8521):

The expression line at the top of the result area reads √(4) - 2 =. The history pane on the right reads √(4) - 2 = 0. There is no orphan ( after the minus. The UIA Name string was lying — or, more charitably, the UIA Name was answering a different question (how should a screen reader pronounce this?) than the one the agent thought it was answering (what is on screen?).

Then the agent sent this:

"Sensei, this was entirely my mistake. The real screen shows √(4) - 2 =, no stray paren anywhere. The ( in CalculatorExpression.Name is the screen-reader-normalized token stream, not the visual display. I should not have reported the UIA Name as if it were a rendering. Retracting the finding."

I sat with that for a minute. The agent had:

Generated a false-positive based on incomplete information.
Received a one-line nudge that didn't even tell it what was wrong.
Designed and executed a second verification path using a different modality (pixel capture instead of accessibility metadata).
Confirmed the pixels disagreed with its earlier claim.
Retracted its own finding without me having to argue it down.

That's the loop I've been trying to make possible. It happened by itself.

Why this matters (and why I built it)

There's a category of bug that QA people know intimately: the UI says one thing, the accessibility tree says another, and the test only checks one of them. Visual regressions hide behind passing UIA assertions all the time. Conversely, UIA tests written against AccessibleName can fire false positives when the rendering is fine but the underlying string changed.

A human tester knows to look at the screen when something feels off. An AI agent reading only one channel (UIA) doesn't, unless you give it the other channel and a reason to use it.

JidoDebugger's bet: give the agent both channels, and the discrepancies become discoverable.

uia_find_elements / uia_invoke / uia_type_text — the accessibility-tree side.
capture (Windows Graphics Capture) + ocr + having the agent Read the resulting PNG with its own vision — the pixel side.

The interesting failures live in the gap between them. Most existing E2E tools only cover one side.

JidoDebugger Monitor — every MCP tool call the agent makes streams here in real time. You can watch it capture, uia_invoke, record_finding, all without leaving the window.

Same logic extends to the debugger:

record_finding writes findings to a normalized JSON store.
If you're in white-box mode, the agent can set a breakpoint at the suspect callback, hit it, inspect locals, and attach the call stack to the finding.
At the end, it emits an xUnit/NUnit/MSTest skeleton you can drop into CI.

BugViewer surfaces every record_finding call. The agent writes the finding text, severity, repro steps, and (in white-box mode) the call stack — you triage from this single pane instead of reading scrollback.

The dogfood story: my own WPF PDF editor got rejected by the Microsoft Store for a rendering bug ("place a mark at the top, it appears at the bottom"). I gave JidoDebugger to Claude and said "go find it." One session later it had a repro.zip, a stack trace pointing at a missing ScreenToPdf inverse transform on 180°-rotated pages, and a finding record. I haven't manually reproduced a UI bug since.

Try it

jidodebugger.dhq-boiler.dev

Pre-launch beta, free for the first 500 users, no time limit.
Email signup → license file → installer → one CLI command to register with Claude Code / Cursor / Codex / Copilot / Claude Desktop. About 10 minutes end to end.
Bug reports go straight back to me via the submit_feedback MCP tool — you literally just tell your AI "file this as feedback" and it routes it.

If you have a WPF / WinForms / WinUI app and you've been writing E2E tests by hand, this is for you. If you've been wondering what MCP can actually do beyond read-only queries, this is also for you.

What I learned writing this

Two things, separate from the product.

The retraction is the feature. I almost wrote this post about the cool tool calls and the UIA stack. The thing readers actually care about is the loop: AI claims → human nudges → AI verifies via a second channel → AI retracts. That's the trust-building move, and it's the only reason I'd hand off testing to an agent at all.
AccessibleName ≠ pixels. This is well known to accessibility engineers and almost nobody else. If you're building any kind of AI-driven UI tooling, treat the accessibility tree as one source of truth, not the source. Always have a way to fall back to pixels.

Comments / corrections / war stories welcome.