Big Idea

The argument in one line.

Designing screens visually with an AI agent in Paper before specing and coding gives you a human-controlled source of truth that avoids the vibe-coded look and keeps coding agents consistent.

Who This Is For

Read if. Skip if.

READ IF YOU ARE…

A solo builder shipping a product with AI who wants their UI to stop looking like generic vibe-coded output.
A developer used to designing in HTML and CSS in the browser who wants to try a dedicated design canvas driven by an agent.
Someone running large AI-built projects who needs a repeatable path from design to spec to roadmap to code.

SKIP IF…

You want a hands-on Paper tutorial; the video shows one prompt and mostly tours finished work.
You're building a small app where a full design phase would cost more than it saves.

TL;DR

The full version, fast.

Brian Casel argues that apps designed by AI in the browser share a vibe-coded look because humans never sweat the details. For his Mac video app Cues, he spent a week or two directing Claude through Paper's MCP to mock up nearly every screen, organized into a locked UI page, a design system page and archived explorations. He then had Claude extract a design system, convert the mockups into markdown specs, and write a six-milestone roadmap. He builds one milestone at a time and reviews each in the real app, adding details like hover states, keyboard shortcuts and a Command-K menu.

Free for members

Chat with this breakdown — free.

Sign in and you get 23 free chat messages on us — ask for the hook, quote a framework, find the exact transcript moment, generate a markdown action plan. Bring your own key when you want unlimited.

Create a free account →

Chapters

Where the time goes.

00:00 – 03:20

01 · Why design before code

Introduces Cues, the vibe-coded look problem, and the plan to design in Paper through Claude.

03:20 – 06:40

02 · Tour of the Paper project

Pages for locked UI, design system and early concepts that were thrown away.

06:40 – 11:40

03 · How the design work happened with Claude

Prompting like directing a junior designer, plus earlier concept cycles and the 30%-built app.

11:40 – 15:00

04 · Live demo: mocking up the export screens

One prompt makes Claude read the specs and build seven export screens in Paper, then self-verify.

15:00 – 18:00

05 · Keeping design decisions consistent

The blue, red, violet and green color system propagated across mockups.

18:00 – 19:20

06 · Codifying the design system

Claude extracts buttons, inputs and toggles into one source of truth, with light and dark modes.

19:20 – 20:54

07 · From mockups to specs and roadmap

Markdown spec files by cycle, then a six-milestone roadmap built one phase at a time.

20:54 – 23:20

08 · Mockup versus the built app

Dashboard comparison, hover states, keyboard use, Command-K menu, bring-your-own-agent terminal and the recorder window.

23:20 – 24:21

09 · Wrap-up and links

Early access at cues.studio, Builder Methods Pro and a pointer to his project-organization video.

Atomic Insights

Lines worth screenshotting.

Letting AI design directly in the browser is a big reason so many apps share the same vibe-coded look.
Directing Claude in Paper feels like managing a junior designer: you prompt, it executes on the canvas, and you iterate for days.
A long design phase pays off because one decision, like what green means, can be propagated across every mockup with a single instruction.
Claude screenshots its own work in Paper to verify it before reporting back, which makes design iteration far less hands-on.
A color system can carry meaning: blue for content clips, red for audio, violet for adjustments and green for layout.
Extracting a design system page gives coding agents one official way to build each button, menu and toggle.
Starting from visual designs changes spec-driven development: the mockups settle functional decisions before any written spec exists.
Giving an agent both the visual reference and the written spec beats giving it either one alone.
Even strong models lose the thread if you hand them the whole roadmap, so build one milestone at a time and review between them.
Some details only become obvious in the running app, such as hover states, keyboard navigation and a Command-K menu.
Shipping an MCP with a local app lets users bring their own agent to do anything the interface can do.
Keep abandoned concepts in an archive page with descriptive names so the reasoning behind decisions stays recoverable.

Takeaway

Design first, then spec, then build in milestones

WHAT TO LEARN

Human-directed visual design with an AI agent creates a source of truth that carries through design system, specs and milestone builds.

Designing in the browser through AI tends to produce a generic vibe-coded look, so keep a human directing the visual details in a dedicated design tool.
Direct the agent like a junior designer: give specific feedback on each version and let it execute on the canvas over days.
Keep final screens, a design system and discarded concepts on separate pages so the source of truth stays clear.
Assign meaning to colors and then ask the agent to propagate each decision across every mockup so nothing drifts.
Extract buttons, inputs and toggles into a design system page so coding agents reuse one official version of each component.
Convert finished mockups into written markdown specs so agents get both a visual and a technical reference.
Split the build into milestones and review each in the running app, because agents lose the thread when given the full roadmap at once.
Expect to add details only visible in the real app, such as hover states, keyboard shortcuts and search, and expose an MCP so users can bring their own agent.

Glossary

Terms worth knowing.

Paper: A Figma-like design tool with artboards and pages that exposes an MCP so an AI agent can create and edit designs on the canvas.
MCP: Model Context Protocol, a standard that lets an AI agent such as Claude connect to and operate external tools like a design app.
Vibe-coded look: The generic, similar appearance of apps where AI chose the visual design with little human refinement.
Design system: A single source of truth for reusable components such as buttons, inputs and toggles so the app stays consistent.
Spec-driven development: Writing detailed specification documents first and having agents build from them.
Cycle: Brian's term for a folder-organized chunk of a large project worked through in its own conversation with Claude.
Milestone: One phase of a roadmap that an agent builds fully before stopping for human review.

Resources

Things they pointed at.

00:00toolPaper

00:00toolClaude

01:00productCues ↗

23:47productBuilder Methods Pro ↗

Quotables

Lines you could clip.

01:10

“This is how we can finally break away from that vibe coded look and get back to crafting high quality UI and UX.”

clear claim, no setup→ TikTok hook↗ Tweet quote

19:50

“I could throw all of that at the model and it'll probably build most of it, but it's going to lose its way.”

contrarian advice on agent scope→ newsletter pull-quote↗ Tweet quote

The Script

Word for word.

Read-along

Don't just watch it. Burn it in.

See every word as it's spoken — crank it to 2× and still catch all of it. The same dual-channel trick behind Amazon's Kindle + Audible.

I'm designing a new app right now, and this time I'm taking a very different approach. I'm creating detailed design mockups of almost every screen, or I should say Claude is helping me do that, in a design tool called Paper. Now, this video is not sponsored, but I do want to show you how I'm using Claude and the Paper MCP and how these have completely changed the way that I design, spec, and then build a new app.

And I think that this is how we can finally break away from that vibe coded look and get back to crafting high quality UI and UX now that the design tools have finally caught up to what AI has been able to do in code for quite some time. So in this video, I'll walk you through my whole process. I'll take you inside my design file and I'll show you how I'm using Claude to iterate and dial in the exact experience that I want for my users.

My new app, by the way, is called Cues. It's a Mac app for making videos. So it lets you plan a video as a set of cue cards, and then it takes you through recording and editing in as little time as possible.

And of course you can bring your own agent and have it help you every step of the way. So if you're making any kind of video and you want early access, you can get on the list by going to cues .studio. Now this app has a lot of interconnected screens, so I knew I would have to spend a lot of time getting the interface details just right.

Now for most of my career, I've been designing in the browser with HTML and CSS, even before AI entered the picture. But then as AI models got so good at coding, we leaned even more heavily into that idea of having AI just design our apps directly in the browser. And I think that's how so many of these apps have that vibe -coded look now.

Claude Design aimed to reintroduce design back into the process, but in my opinion, that only continued that trend of leaving too much of the design work to AI without letting us, the human in the loop, actually sweat the details. So for this app, I wanted to take my vision for a video creation tool and really start with a blank slate and work out exactly how every screen and every interaction should look and feel and function.

So in my previous products, I would have just gone from idea to spec to code base. But this time I knew that I wanted to start with a deep design phase to get those details right. And that's what I'll show you today.

And if we haven't met yet, I'm Brian Castle. I run Builder Methods Pro. That's a community of fellow builders shipping real products with AI.

Actually, next week, we're having our next live Q &A and sharing session where members and I share what we're building and get feedback and get unstuck. So these are happening every month for members and recordings are always available. So if you want to join us, you can go to BuilderMethods .com slash pro.

So let's dive right in here. I'm looking at my project in paper. If you're not familiar with paper, it's pretty similar to Figma.

It has the same sort of layout, you know, lots of art boards and you can design stuff. But to be honest, I haven't actually designed anything here by hand. Everything that I'm going to show you has been.

executed in paper using Claude with Papers MCP. They have a really good MCP connection so you can bring any agent to do the design work for you based on your prompting and direction. And that's exactly what I did here.

So this is my project in paper. It's really extensive. I've got lots and lots of screens here where I just went through and worked out exactly how I want every part of the app to work.

to look and feel, kind of worked out all the different views for how we work out a video with a timeline and script -based editing, lots and lots of detail and design cues that need to flow from one screen to the next. Of course, you can bring your own agent. So I designed this built -in terminal on the right side, and that helps you kind of plan out your cues.

It can do the editing for you. I even worked out all the keyboard shortcuts and how that interface is going to work and how you can customize those. So, you know, just really sweating every detail about how all of this stuff fits together.

Now, the way that I've organized my project here in paper is if you see over here on the left side. They have this thing called pages. And what we're looking at is the first one called UI locked.

And that means that these are all the UI screens that I have iterated on quite a bit and then locked and decided like this is what we're going to use as our source of truth. This is what we are building off of. Below that, I've got a page called Design System.

So I had Claude go through and sort of extract all of the individual components, like the buttons and the menus and the toggle switches and all these little components that we use throughout the entire app. And that's how we ensure everything is consistent and helps the user stay oriented no matter which part of the app they're in.

I'm going to talk more about the design system later in this video. And then I've got these two pages down here. And this is where I sort of like did some exploratory stuff and threw away some previous versions.

So if I look at early concepts not using, I like to be very descriptive in these pages. These were some of the very first concepts where I was kind of figuring out, okay, I want like sort of a system of cue cards and you sort of read them off of a prompter. This was obviously like too busy on the page.

I started to kind of work it out a few different ways. I experimented with having you. your agent panel pop up from the bottom versus off to the side.

And then I started getting into like, how can I organize the timeline in a way that makes sense? And of course we wanna have like script -based editing. So I was kind of playing around with different configurations on how all that kind of stuff fits together.

Later on, this idea developed a bit further, blocking off your video into sections or cues. That idea didn't quite stick. So as you can see, I went through lots and lots of iterations on this.

Now, again, I didn't actually go in and hand design every piece of... Text and box and line and button that you see on these in fact, I didn't do that at all in paper And that's what I love about using paper because they had this really great MCP and you can follow their instructions on how to install the paper MCP It's like two seconds.

And so over in Claude, which I have connected to paper using the MCP. This is one of the earlier Claude sessions that I was having a couple of weeks ago as I was having it do the design work in paper so um so you know here was one of my earlier prompts where i said okay we're continuing to iterate and figure out the best ui ux for the timeline interface version 12 has this layered approach and you know it We're also playing around with this idea of queue containers.

And I said, let's try a version that keeps the queue containers, but also keeps that top bar to display. So I'm going back and forth just like I would if I were directing a junior designer on my team. And as you can see, Claude is taking screenshots and it's doing work in paper here and just went down and continued this process for multiple days.

Maybe a week or two is what I spent on this. Just really going through and trying different ideas. out with Claude and every time I'm basically prompting and Claude is then going into paper and executing.

Now, going back further in time, way before I even opened paper, I started to work out the initial concept for this new app that I would be calling Qs. And I went through conversations with Claude, what I call cycles, and I covered how I use cycles and how I organize my large projects. I covered that in a previous video on the channel.

So I had multiple cycles where I was working out different early prototypes, what the business plan for this new product would be, what my strategic planning would be. So in this particular conversation, which happened about a month ago, it produced a couple of different outputs. And so these are just like concept boards.

These are not actual designs. This was just created by Claude, just like kind of artifacts to help me think through some like rough concepts for how a video creation tool might come together with the particular ideas and my own workflow for creating videos. Just kind of like there's so many different ideas that need to come together.

I find that collaborating with Claude in this way really helps. And I was kind of thinking through what the user journey would be, like how they would go from setup to, you know, doing like a raw take for an idea, then going into planning, recording and finishing and how that all might fit together. So, you know, like that's just like a very early.

early sketching and kind of discussing in concept. So that was about a month ago. About two weeks ago, I was working out the design in paper.

And now let's fast forward to today where I have an active thread. I'm going to say launch the app. So I'm going to have Claude actually launch a local version of the Mac application, which is currently in progress.

I'm about, I don't know, 30 % of the way of turning these designs into an actual application. So here it is. And, you know, again, this is not a finished app.

It's really only about 30 % built. But this is sort of like the dashboard area where I can organize my ideas and then the active projects. Now, why don't we actually show you how I design with Claude and paper and show you this in action.

So let's go back to my paper project. And I'm going to go to my UI locked page. As I said, most of the pages or views in the application are mostly already designed here.

But I think that there's one. part of the application that I have not yet mocked up with Claude. So why don't we do that here and I'll show you how this works.

It's really pretty simple. So I'm gonna go into Claude, I'm gonna go into my build cues and I'm just gonna give it a prompt and say, I don't think that we have mocked up the export of a final video screens yet. Check what we have in our written specs for that and then go ahead and mock those up in paper.

add these to the UI locked page in paper. You know, out of those early concepts in these cycle folders, I really started to kind of like document all these specs. And so right now, Claude is looking back at all those previous conversations.

I had many of them, you know, which produced many different artifacts. And it's going to go into paper and then mock those up. Okay, so here we go.

I can see it's actually working. I'm not doing anything right now in paper, but you can, I don't know if you can see it. There's this sort of animation that's happening at the top right corner of the artboard in paper.

That means that something like an agent is working on this and these little dots mean that like action is happening. So I'm going to wait another minute or two. I love this.

I love actually watching the screen come together live just right before my eyes, you know. It's just adding little details. If you're a designer and you used to work in Figma or any app and you used to create these mock -ups by hand, just think about all the hours that that used to take.

As we move over to this next board, we've got a few more screens. I like the button to show in Finder. That'll be nice and handy.

And it's still just sort of tweaking some final details here. Let's see what's happening over in Claude. All it says is like it's using paper and it's going through this checklist.

So it's going to give me a report in just a second. Okay, so it finished up the export views. It ended up being about seven different views.

So we start with ready and then we move into rendering and exporting. It's now finished. And here is where we can sort of decide to export again.

Of course, we can watch it through. And we've got more options over there. So that's looking good.

And then back over in Claude, you can see that Claude took screenshots of its own work to verify that it did the job correctly. It's sort of doing some self -verification before all that happened before it finished. So then when it verified that it's looking good, it gave me this final view and it gave me some details on exactly what it created.

And, you know, sort of it's... little design decisions that it made along the way. Now, of course, what I would normally do is go in here and really think about every one of these details and think through, does this fit with my overall goals for this application and for how I want users to be able to export their videos?

That's time that I'll spend probably later today as I think about that before I go ahead and build it. You know, the real value of a long design phase like this isn't just that it lets me think through all the details. It's that whenever I make a small design decision, like let's say I decide the color green means a certain thing in the app, then I can have that change reflected back through all of the other mock -ups where that shows up.

And then we're building off the same source of truth and we're not drifting away, right? So back in the days of designing by hand in Figma, that type of detailed design work. would have taken days to go back through and update all the little symbols and find all the spots in the project where a button shows up.

Now with Claude and the paper MCP, making that change on one screen is so easy. And then I can just tell Claude, go find all the other places where that also needs to be updated and realigned. So let me show you an example of how that type of thing happened in this project.

So in this video creation app, after you've recorded a bunch of takes for each of the cues in your video, you have your transcript, then you get into this timeline editor. And as you can see, it's kind of busy and complex. So I was thinking about how can I make this simpler and help orient the user in terms of like, what are they currently editing?

What did they select? And I tried to play with some color here. So the blue clips on the timeline are actual content.

So like camera record. or screen recordings or motion graphics. The red clips are audio and then these violet clips are like adjustments.

So you can do like zoom in, zoom outs, color corrections, things like that. So in this view, what I'm looking at is I have a camera recording selected here at the bottom and that opens up this editing panel where I'm editing that particular clip and This panel is sort of colored blue.

All the options, the header and everything are blue. But if I jump over to this view where I have selected this little violet clip here, this is like a zoom, like a punch in. So I selected that and now the editing panel for that particular clip where I can manage the zoom effect is.

is violet. So violet means it's an adjustment clip like something is happening to the content, whereas blue is the content itself. The third color there is green, and that's what defines the layout.

And this is what's going to really speed up the process of creating a video where like each section of your video just automatically snaps into a particular layout, whether it's like camera plus screen or full screen or motion graphic. And, you know, there's going to be lots of other like smart options that you can apply to all the content that fits into that section of the video.

And since we're editing that layout section here, we see green here. So that's like a detail that it took me a while to decide on that color system. And once I did, I asked Claude to go back through and find all the different places where.

We have these clips in the timeline and the editing panels and just make sure that all of that stuff is consistent because now that we're in the building phase and I have Claude building off of the content here, I want to make sure that my coding agent, no matter which mock -up it's looking at, it's using accurate colors, accurate details throughout the whole process.

Now, once the design was far enough along, it was time to codify the design system. So I've talked about design systems on this channel before, and it's basically a way to ensure that all the buttons and the menus and the components that we use stay consistent and don't drift from one part of the app to another. So we don't want our agents to reinvent how to design a button every time we need one.

And that's where establishing a design system really helps. So once I had all these design details sort of worked out, I had Claude go ahead and add this design system page right here. It sort of just extracted all of the individual buttons and the inputs and the toggle switches and these little, you know, components that we use throughout the application.

So just sort of to make one single source of truth for like every time we are making these things or showing them in the application, this is the official way that they should be designed. That's what a design system is. So we've got like light and dark modes.

So once I had all the UI screens figured out in paper and we set up the design system, I then had Claude turn my mock -ups into a written spec. Now I've been talking about spec driven development on this channel for two years now. And I've tried to show you that specs can be written and organized any way that you want and how you create your specs that should evolve as your craft evolves and as the models get better.

Now, this project was one of those times where my... spec -driven process really changed a lot because this time I started with that visual design mock -ups phase where we decided on a lot of the functional details. So my next step was to codify all those decisions into written spec documents so that agents have both the visual reference and the written technical reference when it comes to building out this app.

All right, so I'm back in Cloud Desktop now, and I'm in the same session that I've been working through as I build out the actual Mac application. Here are the files, and I always like to organize my projects into cycles. Again, I covered that in a recent video on how I manage these really large projects.

So this one is this build spec cycle. I broke down the spec into many individual markdown files. I should say, I didn't do that.

Claude did that, right? So Claude took all of the decisions that we had made in paper and like all the little things that we had like discussed and then mocked up in paper, turned that into these written technical specs covering like all the edit areas, the presets, the settings, you know, just like kind of. Jotting down exactly how I want every feature and piece of functionality to work.

And this is definitely one of the more complex, more of like a prosumer or almost like a pro creator type app. So, you know, it has lots of little bits and decisions and functional details that need to be sort of decided on. And I did go through all that stuff during the design process.

And now we have it all written out. Okay, so we have all that stuff kind of written out in. files and files of spec documents, but what's Claude going to do with that?

I can't just dump all that onto Claude and expect it to just build everything smoothly, right? So I wanted to build it out into a roadmap. So after these spec documents were hammered out, I had Claude...

write up a roadmap and break it up into multiple phases. So each milestone is a phase. This is milestone zero, one, two.

So as of right now, I've already built out milestone zero and one. And then we have, let's see, four, five. There's gonna be six milestones on this one.

And this is something I like to repeat. Yeah, I could throw this entire roadmap, all of the milestones, all these specs, the designs. I could throw all of that at Cloud Opus or Fable or Codex.

And yeah, it'll probably build most, if not all of it, but it's going to lose its way. It's going to get confused and things are going to break along the way. So I still like to go milestone by milestone and have it build out one piece of.

functionality at a time and then stop. And then I come in for review and I do that refinement. So for example, we've already built out the foundation and the dashboard.

And that's a chance where I get to actually look at the application to see how it's coming along. And once I see it in the functional app, sometimes there are additional tweaks, whether it's to the UI or the functionality that I want to make here before we move on into the rest of the build. So here we're looking at the dashboard.

Let's see what that looked like in the mockup. So the dashboard is up here. So this was the mockup in paper.

This is the actual application for how it turned out. It's pretty similar. I did add a little bit more detail to these thumbnails.

One of the things that we didn't quite mock up in paper were these hover states. And also I worked out that I want everything to be very keyboard friendly. So that kind of stuff I added once I was here in the application.

Another thing that was not in the original mock -ups, but I definitely wanted to add it, was a search. So we have this icon up here, but I added the Command -K menu so that you can take any action that you want. And of course, I can use the keyboard to pop out the terminal and that lets me run cloud code.

It lets me bring my own agent to queues and have my own agent help me with the editing and help me plan out queues and help me plan out scripts for my videos. So that's a pattern that I really like these days, especially for local Mac applications, you know, to have an MCP for the application. which allows users to bring their own agent, and then that agent can basically do all the same things that a user can do in the user interface.

I really like that pattern, and that's definitely what I'm gonna be going with here in this product. Oh, and one more thing that I spent more time designing once it was in the actual application is the actual recording interface itself. So if I go back into the mockup, that was something I actually didn't spend a whole lot of time on in the mockup.

So the recorder, is this little like pop out window. It's like a separate window from the application.

So if I go into this project and I go into record, here is the actual recording interface. And you can see it actually gives you the ability to run multiple takes and I can start a new recording here. And I can turn these guides on and off if I want to.

That's an example where I didn't really get too deep into the weeds on that when I was in. paper. So I spent a lot of time working out these details and making this nice and easy to use.

And it's still a work in progress. I'm showing this to you in real time. It's about 30 % built at this point.

Now, if you want to follow along and get early access to this new app for creating videos, you can get on that list by going to cues .studio. And if you're building your own products with AI, come share them with us inside of Builder Methods Pro. Our next live Q &A and sharing session is happening next week, and members always get access to all the past recordings.

So you can join us by going to BuilderMethods .com slash pro. Now, you may have noticed that I'm not using plan mode for these big projects anymore. So if you want to see inside how I'm organizing these large projects with agents, check out my recent video where I show my current system.

So follow along by hitting subscribe to the channel and then I'll see you over there next. Keep building.

The Hook

The bait, then the rug-pull.

Brian Casel skips the idea-to-spec-to-code shortcut and spends weeks designing every screen of his Mac video app in Paper, with Claude doing the drawing. The video walks through that whole pipeline, from mockups to the running app.

CTA Breakdown