14 August 2026
Why I Didn't Embed AI in My Layout Inspector
dx-grid-inspector reads real DOM tokens and hands you a prompt to paste into your own agent. No embedded model, on purpose.
Views —
Loading…
14 August 2026
dx-grid-inspector reads real DOM tokens and hands you a prompt to paste into your own agent. No embedded model, on purpose.
Loading…
Every dev tool wants a chat panel bolted to the side now. Mine doesn't have one.
dx-grid-inspector is a small React 19 harness for inspecting layout nodes and calibrating spatial tokens — padding, radius, surface colour, border. It could pipe that data straight into an embedded model and hand back finished CSS. I built the opposite: read the tokens, format a prompt, put it on your clipboard, and stop there.
That gap is not a missing feature. It is the feature.
Wrap a host surface in DxHostOverlay, click inspect, pick a real element. tokenExport.ts reads the computed styles off that element — radius, padding, background, border — into a typed DesignProperties object. Apply changes straight back to the DOM and watch them live.
Then there's DxGridVoice: describe the layout you want in plain language, hit copy, and it formats an agent prompt from your current tokens plus that description.
const prompt = formatTokensAsAgentPrompt(properties, {
nodeName,
layoutDescription: description,
})
await copyTextToClipboard(prompt)
No fetch call, no key, no model selection dropdown. You paste that prompt into whatever you already run — Cursor, a terminal agent, Claude, whichever one won this week. It comes back with tokens. You paste those back into the HUD.
There's also a Harness mode for calibrating tokens against mock nodes before you ever touch a real host page, and an Overlay mode for wrapping actual UI. Same exporter, same clipboard hop, two different places to stand while you use it.
Read → describe → clipboard out → agent → clipboard in → apply. Five explicit steps, and you can stop at any one of them without losing anything.
That's the whole pattern. I call it the DX Spatial Grid pattern internally, mostly so I stop typing "the clipboard thing" into commit messages.
An embedded model in a dev tool means I own a key, a rate limit, and a vendor. It means the tool breaks the day that vendor changes a response shape, and it means you're trusting a side-project HUD with whatever you paste into it.
The clipboard boundary makes none of that true:
That last point is the real one. Most of the thinking already happens in Cursor, against the real repo, with real context loaded. Routing it through a second, weaker chat window bolted onto a demo tool is a downgrade dressed up as a convenience.
I'm not against embedded AI on principle. It just has to earn the trust boundary first.
That happens when the loop runs often enough that a manual paste is genuinely the bottleneck — live-as-you-type suggestions inside an editor, not a once-per-component token pull. It happens when the surface is already the user's primary, trusted workspace, the way Cursor is for me. A standalone inspection harness isn't that yet. Bolting a chat panel onto it wouldn't make it more trustworthy — it would just make it more opaque.
dx-grid-inspector is public and MIT-licensed, with a live demo and an INTEGRATION.md if you want to copy the overlay and token exporter into your own app. No npm package yet — copy the three files, keep the filenames, done.
This is also the walkthrough I run on client calls: open the overlay on a real page, inspect a card, generate a prompt, show the whole clipboard loop in real time. It reads better live than it does in a screenshot. The clipboard-only pattern itself is one of the things I check for under Keel AX when a team's agents keep guessing at spacing.
If your tool is reaching for an embedded model to save one paste, check whether that paste was ever actually the problem.