Vibe coding for WebXR in 2026: I built a tool that turns a sentence into a VR experience

Tom Pavlin — Wed, 22 Jul 2026 14:04:16 +0000

Vibe coding ate web development in about a year. You describe an app, something like Cursor or Bolt writes it, you ship it. For flat 2D web apps this is just normal now.

VR got skipped. If you wanted to build something for a headset you still had two real options: learn Unity or Three.js properly, or use a no-code builder that traps everything you make inside its own engine and never hands you an actual app you can open anywhere.

I wanted a third option, so I built it. Turbl lets you describe a VR scene in one sentence and get a real WebXR app back, running in your browser, openable on a Meta Quest with a link. It's React Three Fiber under the hood. No code, no store, no install.

Why nothing else scratched the itch

By 2026 there were a handful of AI tools poking at 3D and games. Most of them build on their own closed engine, so whatever you make lives on their platform and you can't take the real app anywhere. The ones aimed at actual developers could scaffold a bit of Three.js, but weren't built around VR, or around the one loop I cared about: type a sentence, put the headset on, walk around inside the thing, send someone a link.

That loop is the entire reason WebXR (VR on the open web) is interesting in the first place. No app store gatekeeping, no 200 MB download, no sideloading through some sketchy tool. You open a URL and you're inside it. I couldn't find anything that treated that as the whole point, so Turbl does.

How it works

It's less mysterious than the demos make it look.

You send a prompt. A coding agent spins up in a throwaway sandbox and writes the actual source: React Three Fiber components, the xr setup, whatever meshes and lights and logic the scene needs. It builds that down to a single self-contained HTML file.

The one clever bit is weight. The heavy shared libraries (React, Three, R3F) load once from a cached runtime instead of getting baked into every single game, so a finished scene is a few kB of its own code instead of a 7 MB blob. That's the difference between "open link, you're in" and staring at a ten second white screen.

What you end up with is a plain WebXR app. The same React Three Fiber stack a person would write by hand, nothing sealed in a black box. It runs in any WebXR browser, which in practice means the Quest browser or desktop Chrome.

What I've made with it

Easiest way to show what it does is to show what it made.

I typed this, typos and all:

create a gallery so i can walk around

I gave it no dimensions and no art direction. What came back was a walkable room, framed pictures on the walls at eye height, and a sculpture in the middle you can orbit.

The spatial choices are the part I didn't expect, because I didn't ask for any of them. The pictures aren't stuck up near the ceiling where you'd crane your neck. The room is big enough to actually walk "around." The sculpture is centered, the way a real gallery would place it. All of that came out of one sentence.

Not everything I build with it is that calm, though.

In this game you have to defend a hill from the monsters by throwing clay on them.

It's not magic

Worth being straight about this. VR is harder to vibe code than a web app for one dumb reason: you can't see the bug on a monitor. A scene looks completely fine on your laptop, then you put the headset on and a wall is at your ankles, so a "2 meter" wall is a real 2 meters around your body. Spawn point matters more than you'd think. And small text that's crisp on a screen turns to mush two meters away in a headset. Some prompts take a couple of tries. I'd rather say that than pretend it one-shots everything, because a lot of what I do on the tool itself is teaching it the stuff you only learn from wearing the headset too much.

Try it

If you want to see a finished one without signing up, here's a live scene you can open right now.

If you want to type your own sentence and see what falls out: turbl.dev.

If you make something cursed with it, I genuinely want to see it.

I Built a Tool to Export Claude Design Animations as MP4

Tom Pavlin — Fri, 24 Apr 2026 16:20:34 +0000

This is an animation I made in Claude Design:

Claude Design launched a week ago. People started creating stunning animations with a single prompt - but there's no way to download them. No export button. No "Save as video." The same frustration kept showing up on X, Reddit, Hacker News.

Most people's workaround? Screen recording. Which works — until you notice the color banding, dropped frames, and blurry gradients.

So I built a tool to fix it.

The Problem

Claude Design renders animations as live React code in the browser. It's not producing a video file — it's running a web app. There's no export pipeline. Screen recording is the default, but the result is visibly worse than what you see in the browser: color banding on gradients, dropped frames on fast animations, crushed transparency.

This isn't a settings problem. Screen recorders capture your display output — after GPU compositing, monitor color profiles, and real-time H.264 compression. The frame has been transformed multiple times before it lands in your file.

How I Built It

The stack: Playwright with headless Chromium, ffmpeg for encoding.

The interesting part is how you capture frames from a live animation without screen recording. You can't just screenshot at regular intervals — JavaScript's requestAnimationFrame keeps running and you'll miss frames or get timing drift.

The trick is to take control of the animation clock. Instead of letting time flow naturally, the backend freezes it and advances it manually — frame by frame.

For Claude Design's React-based animations, this means walking the React fiber tree to find the <Stage> component, grabbing its internal time hook, and calling it directly with exact timestamps: 0ms, 16.6ms, 33.3ms, and so on for 60fps. The animation jumps to that precise moment, the browser paints it, and Playwright screenshots it. No racing against real-time. Every frame is deterministic.

The screenshots stream as raw PNGs into ffmpeg, which encodes them to H.264.

A few things that were trickier than expected:

Detecting animation duration — there's no standard way to ask "how long is this animation?" The tool probes the page's React component tree and extracts the duration from the Stage component's props.
Two RAF cycles — after setting the time, you need to wait two requestAnimationFrame cycles before screenshotting. One for the DOM update, one for the compositor to actually paint. Screenshot too early and you get the previous frame.
Canvas/WebGL animations — not all Claude Design outputs use React Stage. Some use raw canvas. For those, the tool replaces window.requestAnimationFrame with a stub and calls the page's render function directly at each timestamp.

And here is my tool: claude2video.com

Would love to hear what you think.

DEV Community: Tom Pavlin