Oct 2026 – present
Vibr
Product design and engineering · Beneficialmedia
Vibr is a browser-only design agent I designed and build at vibr.art. Describe a screen, pick a real design system from npm, and an agent plans it, builds it, checks that it renders, reviews it, and repairs what it finds. Designers bring their own model key, and nothing runs on a server.
Every design tool that generates screens has the same weakness: the output looks finished before anyone has checked it. A picture of a page can't tell you whether it renders, whether it's accessible, or whether it survives a language that reads right to left. Vibr is my answer to that, built in the open at vibr.art.
I designed Vibr and build it with Claude Code. It started as the same loop I use at work in Sandcastle, moved into the browser so anyone with a model key can use it, and grew from there one idea at a time.
The problem
Designers want to try an idea in their real design system, not a lookalike. Generated screens are often built from imitation components, and they arrive with no way to tell what's wrong with them. The goal was a draft made of real components from npm that has already been checked before a person looks at it.
How it works
Each request runs the same five steps, and the chat shows every one with its timing:
- Plan: a fast model decides what to build, or answers instead when the request isn't something to build.
- Build: the chosen model writes the screen, and the canvas draws it while the code is still streaming.
- Check: the draft renders in a sandboxed frame. If it throws, Vibr knows before the designer does.
- Review: an automated audit at phone, tablet and desktop widths with axe-core accessibility rules, color contrast, overflowing layouts, and styles that won't flip right to left.
- Repair: the model fixes what Check or Review found. On a large page, it rewrites only the lines around the problem.
It works with Claude, GPT and Gemini models, directly or through OpenRouter, with six design systems, nine chart and table libraries, or any package on npm.
Designing for the edit, not the first draft
The first draft is the easy part. Most of the work is the tenth change, so that's where I spent the design effort.
- Click to change one thing. Selecting an element asks the model to rewrite only that element. In a stress test on a 4,000-row page with a simulated model, an element edit finished in 5.4 seconds. The same change as a whole-page edit meant rewriting a 399 KB file and took 37.6 seconds.
- Shift+click to change several. Pick up to eight elements, numbered on the canvas, and describe one change for all of them.
- Keep what's on screen. Edits and version switches swap the code in place, so open menus, typed text and scroll position stay put.
- Pin feedback. Annotations sit on the canvas, and Fix with AI turns them into a request.
Start from what you already have
A blank prompt is a hard place to start, so Vibr takes what a designer already has.
- A sketch or a screenshot. Drop a picture on the prompt and the model builds it from the design system's components rather than pasting the picture in. In the real run below, a sketched menu wireframe became a working menu page, reviewed and repaired, in 45 seconds.
- Documents. PDFs, Word, PowerPoint, spreadsheets, CSV and Markdown attach to a request, or stay in the library to mention later with @doc. They're read in the browser, files with macros or zip bombs are refused, and only the text and a few pictures reach the model.
- A library to mention. Images from your computer or Unsplash, videos from Pixabay, themes, type ramps and icons, each one an @ mention in the prompt.
From Figma, with the links intact
Most designs start in Figma, so Vibr reads a Figma file too. A small plugin, Send to Vibr, reads what Figma knows about a design: variables, text styles, components, frames with their auto layout, photos, and the prototype links between frames. It saves one file. Vibr turns the variables into a contrast-checked theme and the text styles into type ramps, then builds each frame as its own screen, linked the way the prototype links them, with overlays built into the screen that opens them. A designer can send a whole file, a page, a section, a frame, or a single component to build on its own.
Figma's REST API shares variables only on Enterprise plans, and its MCP server only with listed apps, so the plugin reads the file inside Figma instead: it works on every plan and has no network access. Vibr treats the file as untrusted: every value is rebuilt and size-limited, pictures must be real images of a sane size and are redrawn, and the text passes the same content check as a typed request.
The goal is no drift from the intended design, and telling the model the exact values isn't enough: early runs came back with a white page instead of the frame's oat, a sans where the design has Fraunces, and tighter spacing than the frame's. So each Figma screen gets a design-fidelity check in Review. Vibr renders it at the frame's width and measures every text's font, size, weight, line height, letter spacing, color and position against the frame, each text's place measured from the text above it, plus the page background, padding, and the fills of cards and chips. It checks the outlines of cards, chips and fields, the heights of buttons, rows and chips, and opens each overlay to check that its surface is solid and on top. Repair fixes what differs, the same way it fixes accessibility problems. A theme can now also keep the design's own page background and card color instead of deriving them.
In the run below, the check caught the Checkout field's outline in a darker grey than the frame's, and Item's description wrapping to three lines where Figma wraps it to two. The browser sets Inter a hair wider than Figma, so a line that just fits in Figma's 342 pixels doesn't fit in the browser's. The plugin now sends each text's height, so the check knows Figma's line count, and Repair fixed the wrap by tightening that one text's letter spacing by 0.1 pixels, keeping the words. Every button, menu row and chip is within 3 pixels of the frame's height. One difference got through, on Order placed: after Repair, the check couldn't measure the page. Why it couldn't took longer to find than the fix. Send to Vibr is submitted to the Figma Community and in review.
When the screen goes dark
A Figma run builds one screen after another, and a designer starts it and walks away. That's when the check step failed. With the display asleep, the browser stops drawing, and a measuring frame added then is never given a size: it lays out 0 pixels wide, with every text found at the left edge. Vibr counted that as a measurement, so a screen could pass against a page that was never laid out. A minute later the Mac went to sleep too, and the run stopped until someone came back.
There were two easy answers, and both were wrong. Waiting until the page could be measured kept the check honest but left the run stalled on a dark screen. Passing the screen kept the run moving but claimed a check that never happened. The trade-off I chose is to finish the run and never pretend:
- Keep the screen on while a run builds. Vibr asks the browser for a screen wake lock, the way a video player does, and the browser grants it only while Vibr is the tab on screen.
- A frame with no size is not a measurement. Nor is one that got its size partway through measuring.
- Don't block, annotate. If a screen still can't be measured, the run goes on. Once Vibr is back on screen, it measures that screen against its frame and pins each difference to its element as open feedback, the same as a teammate's note. Fix feedback repairs them, and Resolve dismisses them.
The designer comes back to finished screens, with every difference from the frame marked where it is.
Vibr from your agent
Much of my own work now happens alongside a coding agent, so Vibr runs from one too. vibr-mcp is an MCP server, one line to add to Claude Code or any MCP client, that lets an agent list prototypes, build and revise screens through Vibr's whole loop, import a Figma file, read a theme as design tokens, and export a prototype into the project it's working in.
Vibr's design set the constraint: it has no backend. The library and the model key live in the designer's browser, so the server can't do the work itself; it asks a Vibr window to. The key never leaves that window.
The first version had vibr.art call the server on the designer's computer. Chrome asked people to allow local network access, and Safari refused outright: its console showed the request blocked as insecure content. Rather than tell Safari users to switch browsers, I turned the connection around. The server shows a small page of its own, which opens Vibr in its own window and hands it work through messages inside the browser. vibr.art never connects to the computer, so Safari has nothing to block and Chrome has nothing to ask. And since any page on a computer could try the same, the Vibr window asks first: nothing runs until the designer selects Allow.
Flows, not just screens
A button can open another saved screen: mention it with @screen and the model wires the link. Play clicks through the screens as one prototype, and an exported flow works the same way outside Vibr.
Large pages stay fast
Big pages are where agents get slow. The Plan step reads a folded outline of a long file, keeping two copies of each repeated block, and Repair rewrites only the lines around a problem. On a real 426-line page, Plan went from 17 seconds to 1, and Repair rewrote only lines 404 to 426.
Right to left from the start
Vibr's own interface ships in 12 languages, Arabic and Hebrew among them. The canvas has its own language picker: it sets the draft's language and direction, and translates only the visible text, with the designer's own model, cached per draft. Review flags styles that won't flip, and Repair moves them to logical properties. The point is to find right-to-left problems while the design is still cheap to change.
Designing for when the input is hostile
A tool that runs model output in the browser has to assume that any input could be an attack: a prompt, an uploaded file, a shared library, or the model's own code.
- Your key, your browser. Keys stay on the designer's device and go only to their model provider. There's no Vibr server in between. A key can be kept for one tab only, filled in by a password manager, or replaced by signing in with OpenRouter, which creates a key the designer can see, limit and revoke.
- Contained output. Drafts run in a sandboxed frame with a strict content policy. Links, forms and pop-ups stay inside the canvas and say so.
- Clean input. Hidden characters that can smuggle instructions are stripped from prompts, annotations and imported files.
- Nope, before any model sees it. Requests for content Vibr won't build are refused on the device, so no model is ever asked.
- Checked packages. Before a custom npm package loads, Vibr pins it to a version that has been out at least two weeks, refuses known malware, and flags advisories, deprecations and lookalike names.
Measuring without reading anyone's work
Vibr has no accounts and no server, so it can't see anyone's work, and it shouldn't. Usage counts are events I define myself: a draft finishing, the model and design system, how long it took in rough buckets. Never a prompt, code, a name, a file or a key. Error reports carry an error type and a short message with quotes, code, links and anything key-shaped taken out.
The first week's counts were humbling. About 50 visitors opened Vibr in a week, and the drafts that week looked like my own test runs. The likely wall was the key: you needed one before you could see anything. So a visitor can now open finished samples, a cafe site with its menu screen and an operations dashboard, and try everything that doesn't need a model, in Vibr's 12 languages, before adding a key. The key step also says what a draft usually costs with the model they picked. The counts now follow that path, from opening a sample to a first draft, so the next change comes from what people actually try.
Outcome
- Live on vibr.art, with documentation in 12 languages.
- In stress runs with a simulated model, tables with 100,000 rows render in under 3 seconds.
- In the runs above, a three-element edit took 16 seconds. A right-to-left fix went through a real review and repair in 57 seconds.
- A sketched wireframe became a reviewed, repaired page in 45 seconds, and Plan on a 426-line page dropped from 17 seconds to 1.
- Six Figma frames became five linked screens with the file's photos, theme, type and spacing, checked against the frames by measurement rather than by eye.
- vibr-mcp is on npm, and connects an agent to Vibr in Safari, Chrome, Edge and Firefox, tested on vibr.art.
Vibr is where I practice the parts of AI product design I care most about: showing the work, making the next edit cheap, and assuming the model will sometimes be wrong.
Three real runs
Claude Sonnet 5.5 and Material UI on beneficialmedia.com/vibr, October 30, 2026, sped up. Nothing in them is mocked. The canvas language picker sets the page's language and direction, and the designer's own model translates the visible text; the code doesn't change.
Real runs on production with Claude Sonnet 5.5
From a sketch
Claude Sonnet 5.5 through OpenRouter and Material UI on beneficialmedia.com/vibr, November 2, 2026. Frames from one real run, sped up; the timings in the chat are real.
A real run from a sketch
From Figma
Claude Sonnet 5.5 through OpenRouter and Material UI on a local production build of Vibr, November 3, 2026, with the design-fidelity check on. Frames from one real run, sped up; the Figma frames are the plugin's own export of the file.
A real run from a Figma file
Try it without a key
Production, November 2, 2026, a fresh browser with no key, sped up 1.25 times. Every click is real, and no model runs: the samples ship with Vibr.
The samples tour on production