Vibe Coding Camp

I just completed Design Lab's July-August cohort of their Vibe Coding Camp, which — despite the name — turned out to be way less about vibes and way more about actually shipping. Here for it!

The whole stack was five tools and one afternoon of setup. Claude Code did the actual writing, running, and error-fixing. The Figma MCP pulled real design context — structure, spacing, tokens — straight out of the file. GitHub kept version history so nothing was ever truly lost. Supabase handled real data behind the prototype. And Vercel turned it into a URL I could send to anyone. No engineering background required — once I had accounts for all of the various tools, I just asked Claude to walk me through the installs.

What surprised me is that most of the work happens before anything gets built. You spend the first stretch just talking it through — user goals, interaction requirements, states, edge cases — and you walk away with a spec, not a vibe. Nothing exists yet, so it's free to be wrong.

The other thing: your Figma file stops being a deliverable and starts being an input. The MCP only pulls what you've actually built properly — frames with auto-layout, real color and spacing variables, named layers, componentized elements. Raw hex and "Frame 32594" don't make the trip. Design hygiene went from nice-to-have to functional requirement real fast.

So, what next? I decided to take this new knowledge up against some real-world challenges I've been solving for in my day-to-day.

Here's one that's been sitting on my desk in various forms for quite a while: short-form content is genuinely hard for us to do well, even though we built a player (it launched on X1 with the Milan Cortina Winter Olympics), because the rights situation is what it is — there just isn't much to work with. But women's sports content is far more available. Same feature, entirely different content pool, and suddenly the whole thing is viable.

That's a fine argument to make in a deck, but it's a much better argument to make with something that actually runs. So I built it — pixel-perfect to our Figma spec, interactions and all, with real video streaming through it.

And what did I actually learn?

I stopped iterating in pictures. Every change went into a running thing instead of a frame. States, transitions, empty cases, the ugly in-between moments — they either work or they don't, and you find out in about ten seconds instead of three sprints later.

Which means it's testable way earlier. You can put something real in front of actual people before engineering has committed a single sprint. "Does this work for you" is a fundamentally different question than "do you understand what design is looking for, from this Figma file?"

The handoff becomes a repo, not a document. Instead of a spec, a redline file, and a long Slack thread clarifying what I meant, engineering gets a GitHub repo. Real code, real commit history, readable and reviewable. There's nothing left to translate — the intent is in the thing.

And it's a reference, not a mandate. Nobody's shipping my prototype. It's not production code, it hasn't been near an accessibility audit or a security review, and I'd never pretend otherwise. But "here's a working version of what I mean — keep what's useful, throw out the rest, build it properly" is a far better starting point than a document describing behavior in English and hoping it lands.

Where that leaves the two disciplines is the actual open question. If design can hand over something that already runs, does that unlock real speed — faster iteration, earlier testing, fewer rounds of translation? Does it mean we get real user feedback sooner, and build more meaningful products with it?

Things I intend to at least start to answer soon enough. 🙂