Are your apps ugly because of bad

visuals or because the user flows make

no sense? Like, is it the ugly duckling

just waiting to spread its wings? Or are

you just trying to put lipstick on a

pig? Well, it doesn't matter because

today we're solving both with a tool

called pencil.dev. Now, I wish I had a

tool like this before I scaled my last

app because it would have saved a lot of

frustration,

lost users, lost time, and probably half

a million dollars worth of constant

rebuilding of things. So, we're going to

look at how the tool actually works and

what makes it unique. And then we're

going to run through two different

scenarios of how you can actually build

really nice stuff with this tool. So,

first let's look at like what the

current ecosystem of choices for this

stuff actually looks like. So, the first

category and this is where I really

started with everything is custom flows,

right? Your own homegrown prompts that

are meant to help you actually design

something from like the actual user

experience and what things are meant to

flow like and then what the actual UI

itself looks like. So in this category,

this is where you have like prompt

libraries, brand like design rules and

guidelines, and you're typically just

moving through this iterative loop of

trying to, you know, get something that

looks the part, looks the way you want

it to look, and you're doing it

manually. The second category are these

like vibe coding kind of tools with

design modes. So let's design mode now

they're called design canvas tools like

lovable and vzero and then you could

argue maybe even tools like cursor where

it's like a vibe coding style of

workflow but what you're really trying

to do is again generate like designs.

So, we've got custom flows, we've got

vibe coding flows, and then we have this

like stitch style category where

historically it was generating like

images. But traditionally with these

styles of tools, you're maybe giving

screenshots or describing what you want

and then it is going through and trying

to actually like generate you screens

and like what different approaches could

look like. But these tools aren't really

bulletproof when it comes to actually

building something that you would want

to like take forward into a production

sense. It's like kind of a pain in the

ass to do that. And then the last

category, we have more like traditional

design tools, like what an actual

product designer at like a tech company

would use. And these are going to be

tools like Figma. So you can design

inside of these tools. You can build out

like really nice wireframes, even

prototype screens. and then you can

export all of the design tokens that

you've made into a coding environment.

So the tool that we are going to be

looking at today is called pencil.dev.

And the thing that's really cool about

this is that it kind of takes the best

of a lot of those different worlds and

puts it into one application. But one of

the things that's really awesome about

this tool is it follows this paradigm of

design as code. And we're going to look

at exactly what that means later. But

the translation of it is that it is very

easy to build really great stuff and

then immediately move it into your

coding environment and build like a real

true pixel perfect representation of

that UI that you designed in the tool.

So, in a second, we're going to get in

and actually look at like building

something with this. But before we do

that, I want to give you a quick tour of

the UI so that you actually know like

what it is that we are dealing with. So,

the way that this app works is that it

is like a canvas. So, very similar to

what you would experience in something

like Figma. So on this left hand side

you can see that we have a chat and this

is going to work similar to almost any

modern chatbased agent interface that

you're used to using today. So you chat

things in and then it goes out and it

starts making screens and changing

screens and doing all of that stuff.

Then we have this layers tab. And so the

way to think about this is that any of

these screens that we might want to look

at. So for example, if we were looking

at this today's diary screen, we

basically have nested layers. So this

ask AI button down here for example, we

can see it down here when I select it.

These are just layers upon layers of

components and things that we're

designing that get nested and nested and

nested inside. So at its core, that is

basically what we're doing inside of

this app. We have all of these layers

that are getting placed on top of each

other. And then we have this agent chat

where we can come in here, we can choose

different models, and then we can give

it some sort of task that we wanted it

to do. So, just to show you like a

really quick example of that, if I was

to click into this screen right here

where I have this uh dense table of

recipes, if I wanted to come in here and

say add UI elements for representing

meals, which are combinations of

specific recipes or foods. So now this

thing is going to go off. It's going to

call different tools. It's going to read

variables. It's going to read our design

systems that we have in place inside of

the app and then it is going to design

us a variation of this screen based on

what we asked for. Now, in this case, I

selected the entire canvas, but I could

have selected, you know, any layer

inside of this and it to make certain

types of changes. So now a few seconds

later, we have exactly what we asked for

again in the style of our design system.

So we asked it to make this meals

dashboard and it took the style and

design of our recipe dashboard, created

the meal dashboard and added this little

icon in our sidebar. So that is

generally on a high level how that

works. Now the thing that's really cool

that I want to show you guys is this.pen

file. So this entire system when we talk

about design as code that comes together

in this thing called a pen file. So if

we were to go actually open up what this

whole thing looks like under the hood we

can see that everything is basically one

giant JSON object. So if we were to

start scrolling through I mean we can

see based on the sidebar length that

this is like a very large object and

every single thing that we see inside of

here is very specific. Right? So, it's

actually taking into context the layers,

what the different like children or sub

layers are inside of that, the actual

like sizing of the different elements,

the font families that are being used,

the icon families that are being used,

all of the colors, like everything that

we could possibly need about this file,

we can see it's it's all in here. And so

the reason this is great is that when we

go to use the MCP server later on to

actually build this thing out, there is

no ambiguity. Every single thing that we

could possibly need done is outlined in

like very explicit detail. So continuing

on this tour, if we click on this agents

button in the top right, the thing

that's really cool about this is that it

uses your actual coding agent. So in my

case, I have it connected directly to my

clawed code instance, but you could do

the same thing if you were using codeex.

And so right now, this tool is free,

which means you don't need to worry

about paying an extra fee for this. It's

actually baked in already to your clawed

code subscription. So all of the agent

chat and everything that is running here

in the sidebar, it's piggybacking off of

your actual agent subscription that you

already pay for. And so the last thing

that's really cool about this is we have

this birectional MCP server. So we can

actually do this design work from inside

of in this case the cloud code CLI and

then we can also take any work that

we're doing here and immediately access

it inside of our coding environment. So

pretty much anything that you see here

in this app from the actual layers, all

of the elements inside of the layers,

the different pre-built components that

they have, even the libraries, which

we'll look at in a second, all of this

stuff the agent can access. So the

general mental model where a lot of this

space of like vibe coding and context

engineering and agents in general,

they're moving to this world where

anything the human can do or touch, the

agent can also do that thing. And that's

where these tools start to become like

really super valuable. So this tool is

really powerful when you get a hang of

it. Let's go take a look at how we can

actually use this thing from scratch. So

I'm going to move in and create a

completely new project. And the first

thing that makes this really valuable is

that it has these builtin design

systems. So if we were to go up into the

top right and click on design systems,

we have a few different like starter

kits or systems that we can choose from.

So in this case, if I were to click shad

CN UI, all of my primary like system

components are now automatically

generated and built for me. So for

example, if I wanted to have like a

modal box with specific like buttons on

it, I already have that component

defined. So I don't need to worry about

going in and thinking about how the

props are going to pass between and like

all of those sorts of things. It's

already done for me for all of the main

components that I could need. So

sidebars, what different label text

might look like, what a loading bar

might look like, all of these things are

already going to be defined for me. So I

have a really strong starting point out

of the gate. Now the thing is we do want

to come in and customize these things.

Like we don't want it to just be, you

know, this very basic vanilla unstyled

Shad CN UI out of the box. And so the

next thing that I like about this tool

that's really cool, if we come down to

styles, there are a ton of pre-built

style guides inside of the app that we

can layer on top of that design system.

So let's say, for example, this inline

friendly, let's say we really liked this

one and we clicked it. That's going to

basically load the template into our

chat down here. And then we could come

through and we could actually click this

Shad CN design system components frame

or layer. So this entire thing and

everything inside of it. We can see down

here that it's now telling us this

object is selected. And we could say

something like update the design system

components based on the new style guide.

And so we can see now that this thing

this is actually an agent. We saw that

blue hovering kind of cursor. This is

actually a an agent that's going through

and it is basically doing the planning.

So, it's trying to get a sense of

everything that we have on this grid.

And so, now after this thing is done

running, we can see much different vibe

overall, right? So, the style has been

updated. It now has this warm linen

palette. The typography has been

updated. The roundness of some of these

buttons have been updated. So, we've now

basically combined like a component

system like Shad CN with our own actual

design styles on top of that system. Now

that we have this design system, we

could come in and we could select it and

we could come through here and ask it to

just build something out. So we'll do it

the easy way first, which is kind of

what you would do in a tool like Stitch

or even maybe a tool like Replet with

design mode. We're just going to say,

"Hey, go build me this kind of vague

thing." So we're going to say, "Use the

selected design system to build these

mobile app screens with multiple states

per screen." So I want to see what it

looks like with success states, with

error states, empty states, things like

that. Then we're going to explain the

app. So an agent native B TOC nutrition

tracking app. And I'm going to give some

basic features that I wanted to sort of

think about. And then I'm giving just

like one philosophical kind of direction

for the app, which is it's all about the

speed of things. So we want to minimize

the number of like taps or actions

needed to to do something. And so the

last thing I'm going to do, which is

pretty cool, is that we can select how

many parallel agents we want running. So

if I was to come down for example and

choose five, this means we're going to

have five different agents designing at

the same time. So this is like a really

nice speed upgrade that we're going to

see as soon as this thing kicks off. So

right now it's just doing the planning.

It's understanding the design system,

but then it's going to go out and it's

going to start building those screens.

So now that this thing is kicked off, we

can see that we have these different

agents that are all operating at the

same time. So, we have this Onyx agent

over here. We have this reef agent over

here. And so, I think there's at this

point three different agents that it has

spawned that are all building different

aspects of what we asked for. And the

thing that's really cool is they are

building this thing layer by layer. Now,

the thing to like pay attention to as

this is moving is that it is doing

everything with respect to the design

system that I had laid out earlier. So,

we're getting in this case like what

does this chat series of screens

actually look like? We can look at

conversations we had. Here's what it

looks like when we're in the process of

actually logging something and like what

the generative kind of UI might actually

look like, being able to confirm and

edit, right? We're showing like

different states that the UX is going to

exist in. And it's doing that across all

of these screens. So, this other agent

while that one was off running was doing

the whole dashboard side of things where

we can see like where we sit from like a

macro perspective with our calories, our

protein, carbs, our fats, like what

meals we've had today. Being able to

quick log something, seeing overviews

and trends, being able to like pop into

specific details maybe of a macro group

if I want to see what were my protein

sources. It's building out a weekly

summary screen, right? So, all of these

things are out designing everything I

asked for at the same time. Now, you

will notice occasionally it makes little

mistakes with respect to the design

system. It will often go back and fix

this because it has a built-in review

stage after it moves through all of

these things, but it is basically off

and running designing everything that we

asked for, which was at the end of the

day a relatively vague ask, right? So,

we have these really nice views of like

kind of an inspiration look of what the

active chat conversation could look

like. The only thing about this that's

kind of uh annoying me a little bit is

that some of the rounding of these

buttons isn't exactly what we had in our

design system, right? Because it's

considering it a badge, but I mean in

reality, this is kind of like a button.

So that's maybe like a take it or leave

it type of thing. We can see what our

daily dashboard overview looks like,

which again looking like really clean

overall. Here's what our like library of

recipes that we have and we've cooked

for oursel looks like, right? And

there's like some small things that I

think don't make 100% tons and tons of

sense. Like this kind of bothers me a

little bit. This gray background with

this text that isn't really contrasting

properly. So, there's like small little

things that we would want to come in and

tweak. But overall, uh, looking really

solid. But now, this only really solves

one of those problems that I mentioned

in the beginning of the video. And

that's is your app ugly and like doesn't

feel great to you because of the

visuals? like all you really needed was

a component system that was really well-

definfined and a nice like style on top

of it. Was that really all you needed?

Or is it the case that the flow of your

app from like a user's perspective

doesn't make sense? And so when you go

to use the thing, it's like, huh, this

isn't actually like feeling the way that

I think it should feel because that is a

different problem that comes back to the

actual planning of the user experience

and the user flows. So now I'm going to

show you a more robust version of what

we can do with something like this.

Because the inherent problem in what we

just did is that we allowed in this case

claude code which is what's working

under the hood. We allowed clawed code

to decide the different features

realistically and how they are going to

shape up to be. And the problem with

that is that every time we delegate that

type of decision, we're allowing the

language model to decide the overall

direction of our app. And the real

problem that is being solved and what

the solution to that is the biggest

failure in vibe coding is under

specified plans and consequentially is

that a word consequently the solution to

that problem and how it really shapes

up. So the step that you really want to

have before this is taking the time to

really hash out the user flows like that

core UX that is going to be the first

version of this thing. And a really good

example of what I mean by this if we

were to look at this series of dashboard

screens for like an MVP of this thing I

don't really care about drilling down

into protein. Like that's not really

valuable to me as the person that's

going to use this thing. Like I've

already logged those meals. I don't

really care about clicking on this

little protein card right here and then

being brought into this breakdown view

that was like, "Hey, that protein shake

had 25 grams." Like I I don't care about

that. So for me then, if I was to just

allow Cloud Code to start building from

here, like this is like a dead screen.

I'm going to build this thing and then

the functionality is there. I have to

spend all the time to make it. I have to

build the backend like API route so that

it can surface the data and I don't

care. I don't care about this actually

being there. So why did I build this

screen? Well, it's because I allowed the

language model to decide the screens. So

what do we do about that? So what we're

going to do here is we're going to pop

into my claw desktop. And what I've done

is I've pasted in a PRD. Now, I got this

PRD from one of the last videos I did on

this channel where I talked about the

GStack, like why combinator CEOs skill

that helps you really narrowly define

your wedge. So, like what is the MVP of

your product? Like what needs to be

there? I took that, made a basic PRD,

and now I have this prompt, which is my

UX design agent. And so, this thing's

about to ask me a few questions. And

then out the other side, we're going to

get a bunch of UX deliverables, which we

will talk about when we get them. Right.

So, in this case, this is going to be

like a kind of mobile onthe-go type of

thing. On the chat interface, how much

should it feel like a messaging app

versus a structured tool because this is

going to drive different UX decisions

that we choose to make. So, I I kind of

want a hybrid. Like, I don't want it to

be pure chat GPT. Like, I I want it to

feel like you're, you know, you're

having a conversation, but that you can

also like see meaningful information. I

do not want to like overweight the user

with different like logs and

confirmations and all this type of

stuff. It's like it should feel like

it's just it's there with you and it's

doing exactly what you ask and there's

not like there's not a ton of hoopla,

right? There's not a ton of going

on that you have to think about and

worry about. It's just it's doing its

thing and you have to trust that it's

doing it. So, this is like a good

example of why you want to do this type

of UX exercise. So if we were to think

of like the real world context of me

using this thing, what happens when it

tries to find a match from the food like

public food databases, but there's like

issues with the confidence in that it's

the actual food the user is asking for.

Like how do you handle that type of

situation in the context of your app? If

you don't think about this ahead of

time, like what that interaction pattern

looks like, you're going to have like

probably a really solution to it

and there's going to be a bad user

experience with your app. So, I kind of

like this idea of like a bottomup sheet

that you can kind of slide up and

address the issue. So, go with that one.

So, this question is about that insights

tab that I want to have like what should

that user experience and like

interaction with it actually look like?

So, I want to do the stacked cards and

the reason I want to do that is this

should feel like a thing that's always

working for you in the background. I

don't want it to be the case where the

user only gets insights if they ask for

them. If you were to think of a tool

like Open Claw, the reason people found

that so mindblowing beyond the hypeness

of it, it was that it was very

proactive. Like it would offer things to

you without you having to ask for them.

And so I think that type of paradigm

really makes people feel like they're

working with some sort of AI system when

it gets to this level of being like

proactive. That's something that's very

impressive to people. And so it would be

cool if we can start integrating those

types of patterns into what we are

building. Now, if you want to see these

prompts, by the way, and the prds and

everything and how I make them, there is

a free course in the description below

inside of my school group that you can

go check out where you can actually get

all the prompts and see how I use them

in detail. So, we're going to let this

thing finish doing its processing and

then we will look at the output and talk

about it. Okay, so out the other side,

what we got from this is a very detailed

UX design specification. And the reason

that I really like to do it this way is

that before we get to the point of

actually like saying like, okay, well,

what are the screens? We're thinking

about everything important that goes on

around those screens and how they

actually connect together and how it's

all one cohesive system of doing things.

So an example of that would be something

like what is your information

architecture? So for all the different

features like that we actually have how

are all of these things actually

organized around each other so that they

make sense. Then we move through like

what is the actual like the flows that a

user takes when they want to accomplish

something. So if a user wants to log

food via the chat like what does that

actually look like in practice? So they

open the app, they type in a message,

the back end of the system is going to

classify the intent, right? Then all of

these other things are going to happen

and the end of this is that the user

gets a message. So we're outlining all

of this in detail. What are the errors

that could crop up in that flow? What

are the different edge cases we need to

consider? And then it repeats for every

feature. So for the insights querying,

what does that look like? For exporting

from other tools and uploading them into

our tool, what does that look like? And

then we get down to the screen

specifications. And so even if you don't

want to do all the other stuff above,

you at least want to get to the level of

defining like what's going to actually

go into each of these screens and how

does that fit with what the problem I'm

solving is. Is it in scope of the MVP?

Does it make sense? Am I using the same

like conventions and ways of doing

things on screen one as I am on screen

three? We want to make sure that's all

super locked in. So in this case, this

is how I've structured those specs. So

we have the the screen, the purpose of

the screen, the entry and exit points

from the screen. So in the chat, like

how can I get to the chat? Like what are

the means by which I actually get there

as a user? What's like a lowfidelity

wireframe of this thing? So we have, you

know, a ambient macro bar that's like

pinned to the top of chats. And then we

have our kind of back and forth, you

know, conversation going on. And then

this is what the bottom of this could

look like. So we go through the content

hierarchy for any of those like

important things like that ambient macro

bar. Like what does that actually look

like? How does it function? What are the

different modes? What does the like

styling of the system messages coming

through actually? Uh like what is that

going to actually look like? How's it

going to function? Uh interactive

elements, which is valuable if we want

to mock up what different versions of

this screen look like. And then it

repeats, right? So then it's going to go

through to meals. So, as an example, we

can copy just this first screen, and we

can now hop back over into our pencil

system, create a new chat, and I'm going

to select this design component system,

and then I'm going to do the same thing

I did before, just with more detail. So,

based on the design system, which is

selected, I want you to build this

screen and its variations. I'm going to

hit go, and then this thing is going to

pop off, and it is going to create that

thing. Now, one of the things that's

really cool about this app is we don't

really have to wait, right? So, if I was

to go back up and just like copy this

top part, pop back into my chat, paste

that in there, and now if I came down

into our cloud conversation that we were

in, I could do the same thing for the

meals now. So, I could come through

here, the layout structure, right?

Content hierarchy is all there, the

different states, copy it, pop back

over, paste it in, let it go, and so now

these are going to be all working at the

same time. So we don't need to do these

things like synchronously in order and

wait and wait and wait and wait. We can

just kick these things all off in

parallel and basically build out all of

these screens simultaneously. Now the

thing that's really cool, like I said

earlier, there's a birectional MCP

server. And what that means is I'm doing

this in cloud code or sorry in cloud

desktop because it's very visual and

easier for you guys to look at on

YouTube. But if I was inside of like my

actual claw code environment and I had

these screens built out and they were

inside of some sort of like series of

folders, I could just use the MCP server

and tell it, hey, for each of these

screens inside of this folder, go build

them out in parallel. And all of these

screens, I think we have one, two,

three, four, five, however many there

are, all of those will be built out at

the same time inside of this tool. And

we can see probably spawned off too many

agents, but we've got a bunch of

different agents working across the two

different screens. And again, they're

building things out exactly to my spec.

So now that those first two screens and

the different states are done, we can

look at what they look like. I have

other ones now building out the rest in

the background. So every single one of

these from the the default to the, you

know, empty first time someone's ever

even using this thing through to the

hey, it's processing in the background.

Hey, there was an error. you know,

you're offline and this stuff can't

process. All of this stuff was

determined ahead of time. Same thing

with the meals. Like all of these

specifications were things that we built

out in this lowfi kind of way so that we

could make sure like does this actually

fit with the vibe and the flow that I'm

envisioning for this app. And we can

kind of see this ahead of time. Now, the

other step that I skipped here that you

would do in real time is to go back

through this thing and have an

adversarial back and forth with the

system. And again, I have prompts for

that inside of the free course where we

could say like, hey, this specific

screen isn't exactly what I need it to

be. And you have this kind of back and

forth with the the model to make sure

that they're actually building it in the

direction you want it done. And so this

is the process that again that results

in here's what it looks like in the

default kind of way. Here's what it

looks like when it's empty. Here's what

it looks like when it's loading and it

has this kind of skeleton in the

background. Here's what it looks like

when you search something and it can't

find it. Here's what it looks like when

you're trying to log something. Like all

of these screens are thought of ahead of

time so that we can make sure it's it's

what we actually want it to be. So now

one other thing that we can do is we can

create variations on these designs. So

if I was to open a new chat and select

this screen for example, I could come

through here and I could say show me

three variants of this type of design

and hit enter. And now it's going to go

out. It's going to take the context of

that screen and again it's using claw

code in the background in this case opus

4.6 and it's now going to just generate

me different variations of this specific

screen. And so now we can see like what

some different variations of this

insights tab might look like. I

personally like this one uh variant one

um the best. It's kind of like this but

a little bit more expanded and has a

little bit more data in it. But there we

go. We have some different options. So,

generally speaking, I think that first

approach, the kind of easier way where

we just prompted something in um this

made like a nice looking sequence of

screens and this can be useful for like

brainstorming like maybe you just want

to see it visually. You don't want to go

in and create a PRD and the UX

definitions. You just kind of want to

see some inspiration like I like what a

lot of these screens ended up looking

like. But if you have a very clear idea

or want to have a clear idea before you

step in and start building things, you

can use this other approach where we

generate an actual like UX system and

generate those screen definitions ahead

of time. But let's say we really like

something that we built and we want to

move it over now into our actual app.

Like we want to now build this thing

inside of Claude Code or Codeex or

whatever. If we go down into a project.

So in this case, I have a very basic

starter app. This is an expo app. It

doesn't have anything done in it yet.

This is completely fresh. I can come

down here now and I can ask it to help

build the plan to start making these

screens. All I'm going to tell it to do

is use the pencil MCP and build out

basically all of the screens. In this

case, I'll just have it build out four

of these. And we're going to kick it off

in plan mode and let it run. And so we

can see here that the MCP server for

pencil is being used. And so it is

gathering basically all of the different

elements. And again, these are like

nested um JSON objects. And so it's

going through and it's pulling all of

the different screens and their

definitions out of this active editor

state. So one of the things that's

really cool is Pencil actually generated

this like system prompt to use for all

of the design. And so it's specifying

essentially like the different

components that we have inside of the

app and how it's really all meant to be

used. So like what are the rules, what

is the ordering of certain things, what

are the dos and don'ts. And so it's

moving through for everything that we

have and it's telling it exactly how to

build this thing to spec. So there's a

lot of MCP tool calls here, but it's a

JSON object, so it it shouldn't be

taking up some like ridiculous amount of

tokens. We were to pop back real quick

into pencil. As this thing is running,

it is reading these screens in real

time. So, as it's moving through and

trying to build stuff, it's constantly

like hopping back and forth and making

sure that it's building things the way

we have asked it to. And so, now that

this process has run through, we can see

that we have these screens um that are

pretty closely designed based on what we

had inside of the pencil file. So, we

have this nice little like pill

navigation at the bottom. We have a

recipe view. some issues with like stuff

being, you know, cut off that we'll have

to go through and fix, but on the whole,

you know, little spacing issues and

things like that, but this is something

that we can actually uh work with. So,

this is just a basic example of building

out the navbar and a few screens, but

I'm going to be doing a full video here

on YouTube where we go from app concept

through to fully building the app out

completely. That's probably going to be

a 2, three, 4h hour video, but this

design stage will be part of that

process. So, make sure to subscribe or

be ready to go check for that if you're

interested in seeing how we can

integrate something like this into like

a full process that actually makes

sense. But that is it for this video. I

will see you in the next