Accelerating UI Development with Storybook and AI Agents

Name: Building a Practical AI Assembly Line
Uploaded: 2026-04-20T16:00:06+00:00
Duration: 52 min 59 s
Channel: Boundary
Description: Summary and key takeaways on Building a Practical AI Assembly Line: Summary & Key Takeaways, covering The Problem with Traditional UI Development Running the

Boundary

Apr 20, 2026

•

52 min video

•

2 min read

YouTube video ID: adpUOpW85ns

Source: YouTube video by Boundary — Watch original video

PDF

Running the full LLM‑app stack for every UI tweak creates high friction. Developers must reload the entire application to see a single component change, which slows iteration. During planning and design, visual verification is often missing, so assumptions about component appearance can be wrong. “Figma is just a WYSIWYG editor that agents are not that good at like interacting with, but they're really good at writing React code,” notes the hosts.

The Storybook Solution

Storybook isolates components so developers can pass different props and see immediate visual results. It acts as a “unit test for visual stuff,” letting teams model edge cases such as loading, empty, or error states without triggering full app flows. By providing a sandbox, Storybook eliminates the translation gap between design tools and code, offering rapid visual feedback.

Architectural Patterns

The hosts split UI logic into two categories:

Pure components – stateless, prop‑driven display elements that focus solely on rendering.
Wired components – stateful wrappers that handle hooks, API calls, and business logic.

This separation lets teams restyle or replace pure components without touching the underlying wired logic. Organizing the code in a turbo mono‑repo (e.g., apps/ and packages/UI) enables shared libraries across multiple applications. “The teams that are willing to migrate to a mono repo are just going to get so much better results from agents,” they observe.

Agentic Integration

AI coding agents such as Claude can bootstrap Storybook stories for any component. Developers paste “bad states” or visual issues into the agent, which then generates a reproducible Storybook story. Visual iteration proceeds by reviewing screenshots, prompting the agent to refine the component until it “looks nice.” The loop looks like this:

Identify a UI issue or edge case.
Prompt the agent to create a Storybook story that reproduces the state.
Review the visual output in Storybook.
Iterate on the component code via the agent until the visual output meets requirements.
Integrate the finished component into the main application.

Agents excel at writing React code, making it possible to edit data directly in Storybook without reloading the whole app. “You don't have to run the whole app, you don't have to run everything. You're literally just editing data in this place and you're just telling the model here's what I'm doing,” one host explains.

Mechanisms & Explanations

Pure vs. Wired Separation
1. Identify a component that fetches data (Wired).
2. Extract its display logic into a stateless component that accepts props (Pure).
3. Move the Pure component into a shared library.
4. Create Storybook stories for the Pure component to test various prop combinations.
5. Keep the Wired component as a wrapper that handles data fetching and passes results as props.

Agentic Iteration Loop follows the five‑step process described above, turning visual feedback into concrete code improvements without full‑stack reloads.

Takeaways

Isolating UI components in Storybook removes the need to run the full application for each visual change, dramatically speeding up iteration.
Dividing components into pure (stateless) and wired (stateful) layers improves testability and lets developers restyle UI without touching business logic.
AI agents like Claude can generate Storybook stories from described edge cases, enabling rapid visual debugging and refinement.
A mono‑repo structure that houses shared UI packages facilitates component reuse across multiple apps and enhances agent productivity.
Visual iteration loops that combine Storybook screenshots with agent‑driven code updates allow developers to converge on a polished UI without full‑stack reloads.

Frequently Asked Questions

How does separating pure and wired components improve UI iteration?

Separating pure and wired components lets developers test and modify visual output without invoking stateful logic. Pure components receive props only, so Storybook can render every edge case instantly. Wired components remain as wrappers that handle data fetching, keeping business logic untouched during visual tweaks.

Who is Boundary on YouTube?

Boundary is a YouTube channel that publishes videos on a range of topics. Browse more summaries from this channel below.

Does this page include the full transcript of the video?

Yes, the full transcript for this video is available on this page. Click 'Show transcript' in the sidebar to read it.

Helpful resources related to this video

If you want to practice or explore the concepts discussed in the video, these commonly used tools may help.

Ergonomic Mechanical Keyboard For Programmers Recommended

A high-quality mechanical keyboard improves typing speed and comfort during long coding sessions, which is essential for developers iterating on UI components.

Amazon →

Ultrawide Monitor For Software Development

An ultrawide monitor provides the screen real estate needed to view Storybook, code editors, and AI chat windows side-by-side for faster iteration.

Amazon →

Clean Code A Handbook Of Agile Software Craftsmanship

This book provides foundational knowledge on component separation and clean architecture, which aligns with the 'pure vs. wired' component patterns discussed.

Amazon →

Vertical Laptop Stand For Desk Organization

A vertical stand helps organize a desk setup when using a laptop with external monitors, creating a cleaner workspace for focused development.

Amazon →

Links may be affiliate links. We only include resources that are genuinely relevant to the topic.

Summarize another video

Full Transcript YouTube

It's really, really helpful for like
iterating on our like mermaid renderer
because like you don't actually want to
go like generate a document that has
mermaid in it in every single case. So I
can just come in here and just put like
And it just works.
>> can edit the yeah, the mermaid thing.
This one is not very, very very large,
but yeah, you see what I mean? I see cuz
it again, it's pure render only. I like
this a lot. This really interesting
>> conversation of an message. Here's the
coding agent thing is like you can
literally see every single possible
thing that
>> And now I can see how your iteration
loop is much faster both for you and the
agent because like you don't have to run
the whole app, you don't have to run
everything. You're literally just
editing data in this place and you're
just telling the model here's what I'm
doing. And then you iterate. You can do
it incrementally, right? You can just do
like bootstrap storybook and you get
like a couple of those like hello world
stories just like with some buttons and
then you could say like cool, take this
component and add it to storybook and
like split it into wired versus pure or
if it's already pure, you can just you
can just do it that you can just say
like okay, put this pure component in
storybook. You generally don't want to
have your like stateful components that
are making API calls and stuff in
storybook. That's not what it's for at
all. Um but yeah, let's see what this
comes up with.
>> This is so nice. Thank you Dexter for
doing this and we can see exactly what
the win here is. Like I don't have to
like produce everything all the time. I
can just come up with all these edge
cases and just could decide exactly how
we want to render it. By the way.
>> And as soon as a user comes up with an
issue, you just paste it into Claude.
You'll be like hey, here's a bad state,
add it to storybook and then we're going
to fix it.
Today's episode is something that I'm
really excited about. It's a new thing
that I'm actually going to learn from
Dexter and by the end of this episode,
thanks to what we learned here, we'll
actually have watched the migration of
our code base to use this new technique.
This new technique is called storybooks.
And the idea of storybooks is how do you
build learning tests or unit tests for
your UI components so you can iterate
extremely fast with an agentic loop that
doesn't require you to reload your app
state continuously. One of the things
that we do in our playground today is we
actually have to go ahead and every
single time we have something working or
not working, we literally have to go and
run the LLM all the way through and
through to go look at the results. What
I would love to do is be able to iterate
with an agent purely on the UI and as I
iterate on it, be able to test things
out very quickly for different types of
scenarios.
That's what this episode is about. How
do we all do that in our agentic loop?
Let's get started. Welcome to AI that
works where we talk about AI that that
works. This is the show with the worst
SEO of all time. There is no podcast
with worst SEO than AI that works, but
we're appreciative for you all you here
trying to pump it up. We'll get to the
top someday. Um this is all about going
beyond the demo and building things that
actually work in production that you can
put in products and sell to customers,
that you can put in your startup,
whatever it is.
I'm Dex, I'm the founder of Human Layer.
We help people build cool [ __ ] with
coding agents especially in large
complex code bases.
I'm going to let Vibhav introduce
himself.
I'm Vibhav. We're working on a
programming language that hopefully is
designed for agents first and no other
language has done that to this state. So
what happens when you run auto research
on Vibhav's mode and build new syntax.
Incredible. I love that. I talked to
Jeff Huntley a lot about when he's going
to finish cursed lang and he actually
told or no, it was when is he going to
finish his lights off software factory.
And I think actually the alpha there is
something around like we need new
programming languages before the agents
can actually build full lights off
software otherwise they vibe code
themselves into a slop corner.
Yeah, you need you need a totally
different paradigm of software
development. Like the CICD needs to
change. Everything needs to be different
if you're going to run automatic loops.
But that's not what we're here about
today. Yes. Today we're going to talk
about a really fun topic. We've talked a
lot about crispy and and and research
plan implement and like how to get
coding agents to ship better. Um
One thing that we have found internally
and also working with a bunch of users
is there is one area where doing a lot
of planning and reviewing markdown docs,
it's great for like back endy like
system stuff. It is not as good for
front end code. Like I can look at
I'll even pull up let me see can I think
I can find one of these design
discussions.
Incorrect. Lean is not a good
programming language. It's unusable.
>> Oh no.
Anyway, go on. Show show show me what
you got.
>> uh talk. Thank you very much. So I have
this thing so in um
Let me go turn these on. So we have this
feature called tips.
Going to reset all of these.
And so now we can display these tips.
They're supposed to help you through the
crispy workflow here. They don't work
very well. People don't read them and
they just leave them there.
>> And they don't they also don't click
don't Well, you already know how to do
it.
They are useless. You should turn them
off, which I don't even know if you knew
how to turn them off. The point is is we
want to translate them to modals so that
they just show up once and then you say
got it and you're done and you don't
have to read it again.
Um so we have a bunch of copy changes
here. Um and it has some front end code.
Like I can look at this front end code
and I can know does this like follow our
design system, but I can't look at this
and know whether it's going to look good
or not. And so like what you end up
doing something that you often do in
front end is you can vibe code back and
forth with the model and get it to look
how you want. And in this planning flow,
you actually don't know how it's going
to look
until much, much later in the in the
system. And so even here in the
structure outline
um
we kind of
I I can read these components or I can
read this like overview and I I don't
know if this is going to look good or
not. Um
And so I want to talk about some stuff.
Like basically like we talked about
learning tests before. Do you remember
this one Vibhav? We did. We've talked
about them quite a few times. They're
super useful. I use them all the time.
So basically like
you have these assumptions. You can read
the code to understand how the system
works and then you can go make a plan
and then assumption carries through and
then you can implement. And then you get
to the last phase and you're like oh,
that assumption was wrong or like there
was some decision we could have made
earlier on, but we didn't find out until
implementation.
And we talked about basically in the
planning phase writing like learning
tests and proof based development.
Basically writing these little scripts
that verify that the the code works the
way you think it does or the external
system works the way you think it does.
So you find out your unknowns during
planning instead of instead of like
during implementation.
This is the same idea, but it's it's for
unknowns about how is thing how are
things going to look and how are the UX
experience is going to be.
Does that make sense? Yeah, I think
that's there's a few people in here
talking about stitch. They're talking
about a couple other platforms, stately
AI, Figma.
It sounds like some people just use chat
GPT
>> [snorts]
>> So we what what we end up doing a lot is
basically we'll do our research and then
we'll do our, you know, design
discussion.
Um and then we'll sometimes instead of
going straight to the outline and the
implementation
we'll pause and we'll do as part of our
like quote unquote research, part of our
pre-building is we'll make storybook
stories. So we don't really use a lot of
Figma here because Figma is just a
WYSIWYG editor that agents are not that
good at like interacting with, but
they're really good at writing React
code. And so storybook is this tool.
It's been around for 10 plus years at
this point, I think. Um basically since
the beginning of React where you can
basically take your component and let me
go pull up the code here and you
basically have we basically have this
really simple like button story, right?
Um and it has this is this is our this
is our component that we would like
build for our app. So I can come in here
and I can change the font to you know,
system UI sans-serif. We can change the
border radius to you know,
100 px.
And now all of our buttons are super
rounded basically.
>> So I know a few people that use
storybook and I know people have tried
to use storybook beforehand. I know we
even tried to adopt it. Yeah.
Tell me why this is better now for
agentic experience. So I get that it's
super componentized. What am I get So
show me what happens. So yeah, so what
we get to do is we get to do things like
um
401 make all the buttons super
you know, What what's a component you
want to make? Make a page
for
um
reading articles
in a news story. So basically we you can
you can vibe code your components and
your building blocks and essentially
um
So this is the thing I would use in my
app and I can explore it via props in
all of the different like ways I might
want to display it. And so in React you
have this idea of like props versus
state, right? So if your component is
super stateless, then all it does is it
takes these props and it renders
something. And so storybook helps you
get that right and you can use it to
test all the different like ways your
your item might display.
Okay, so I understand that. Now I've got
a question. Now I've got more questions
cuz I can see how the agent loop here is
much faster. What I do is I ask an agent
to build this thing. I go look at it
visually or maybe have an agent use
playwright or like computer use to go
access this locally and that kind of
this hot loop that can do something nice
and I can paste screenshots and all
sorts of stuff around it. Yep. But
how do you make your code actually
persist in that way? What I run into is
I don't have stateless components.
All my components have state.
They have like use effect or something
else. Yeah.
We'll get into that. So that's the idea
that we get into that in like the the
difference between like pure and wired
components. Okay.
And actually it's actually wrote written
an article about this funny enough cuz
that's what we were talking about. Um
but you can basically text like okay, if
there's no image what shows up? Okay, I
actually don't like that it says no
image. I want
uh if there's no image in the props just
don't show no image. Use Whisper flow or
super Whisper.
>> no.
Okay. Um while you do that
>> here is like I can go get the like
basically like the stateless all of the
different um
like
uh
states that my component would be and
I'll I'll get to a a more realistic
example in a sec. Um
here is like a storybook with a bunch of
components from uh from Riptide. Uh so
we can come and like do our theming
stuff here and stuff. Um
this is an example of like how how we
tend to work.
Um let's see this one doesn't have any
interactive controls, huh?
But where where this gets to is
basically like I built a we built like a
very small like dumb little web app here
and this is wired with a back end and a
front end and all kinds of stuff and I
could vibe code against this but it's a
lot more context to pull in if I just
want to like work on a single component.
One like it becomes a lot easier to to
to build with. Do you know what I'm
saying?
So yes, okay. I understand why this is
faster. Um Yeah. But I guess you can't
really test interactivity with this.
So you can. That gets a little weird but
um one of the one of the things that we
end up like
building um
for we use
>> is this is really freaking cool. I I
know for our playground for example, I'd
love to see this kind of stuff where I
could like visualize stuff.
And just render out states like this.
>> This ends up being like one of the one
of the stories like that that that will
build. Okay.
>> and so I think these have these
these have like basically yeah. So so
you can't actually these are all
clickable but they don't actually work.
Makes sense.
Cuz it's not running the full React
server.
Yeah. That's because [snorts] the well
so it's it's not that it's not running
React. It is full React. Um but if you
come into we basically have pure
components that just take props and
render. And then we have the wired
components. And so this has been for a
while like a pattern since I don't want
to say like 2014 or something where you
would take you would create the wired
version and this is where all your state
and interactivity lives. In this case
it's it's pretty like small but it's
like this is fetching data from an API
and stuff. And so the separation that
like the architecture thing here that I
would like have people take away is you
have basically uh okay, they pulled in
some like loading states and stuff like
that. Um but then you have your table
with all the information. And so the
fetching of the information is in like a
wrapper component and then you have this
pure component that is just the display
logic.
That's interesting. That's interesting.
That's very fascinating. I I say this
because like while we're out designing
the Babel playground, we have a really
weird scenario. We we actually run like
web workers and like WASM code in the
browser and that gets you really weird
state with lifetimes and everything else
for these WASM objects that you need to
refer to.
Um and that fuzzes things a little bit
but I can see how it would be incredibly
useful to just have pure UI elements for
rendering things and be able to test and
debug that.
Yeah. And we can actually create like
you can create storybook stories for the
wired components as well or you can
create the interaction layer in
storybook. So like
>> Yeah.
for the
Is anybody else's Whisper flow like
crashing all the time now? I'm telling
you slop code is everywhere. for the
um 03 uh data table stories, can you
create a separate group of stories that
actually demonstrate the interaction
like the sorting and stuff like that? Um
I I'm not sure if there's a good way to
do this in storybook or if we just need
to mount the wired components
themselves. Um but we need to not
actually fetch data from the API in
storybook since this is like an
interactive playground.
Um I think storybook does have like you
can you can program in interactions. But
basically like the architecture of your
app ends up looking like um
and we actually have separate packages
so we have like a you know, we have the
core repo
and then it's a turbo mono repo. So we
have like the apps folder
which is like all the things that
actually run
and then we have the packages folder.
Yeah.
>> have a packages {slash} UI that has all
of our like building blocks.
Uh
and this is where basically all the pure
components live.
And then for Riptide UI versus like say
Riptide Cloud
if you go to these two different things,
you can come and look in here's Riptide.
It has like a visual language. It has
buttons and things like this.
And then you can come to you know, cloud
our
cloud app and it has the same visual
language and it's actually like using
the same uh buttons and everything here.
Like this is the exact same component
that's being imported in both places. So
like part of this is like use a
component library but the other part of
it is like you always want to have your
like
um pure component.
And then the only job of the wrapper
component is basically to
do a bunch of business logic, right? You
have your like
hooks, state, etc. that push props into
the pure component that just renders.
And so you would never actually run
render the pure component in your thing
but we can have multiple different
wrapper components for like okay, in the
cloud we're fetching from different
APIs.
>> So I'm going to ask another follow-up
question. Um so this is actually really
interesting. How do you not get laggy
UIs when you do this? Cuz it seems like
you're going to get like a lot of
re-render loops in the wrapper component
that'll cause everything sub below it in
that subtree to re-render and now you
have a laggy UI. I mean part of this is
like I mean I I am not the person to
lead an episode on uh React optimization
and performance and memos and
re-rendering and all this kind of stuff.
Um but
the the idea there is like every every
component that you render matches this
same pattern. So at any point you can
just take the pure thing off the shelf
and make it look different. Um and so
this this app that we built has you
know, it has users. So I can come in
here and search for Avery and then I can
click on this user and I can get their
didn't build a very smart but then
there's like a to-do system, right? So I
can see all this user's to-dos and like
let's say I wanted to like change the
look of this one. I don't like that this
is like like grayed out when it's
finished.
Yeah.
>> pull up the entire app and then create a
data state locally that matches that and
then go try it. Like this is fetching
ideally like fetching real data from the
API but because we have this as a pure
component, I can come in here and go to
the to-do card and we have every single
state modeled out and so I can test all
of these. I can come in and actually
like edit the props of any of these to
see okay, how does it behave in various
different states? Okay, that's cool.
Yeah, I can see how this is nice.
Yeah, I don't know what the actual
states are but
>> Well, you spelled you spelled it borken
instead of broken.
>> Well, I don't think we have yeah. It
does FYI.
Is it crit? No, I think it's critical.
Um Probably low is probably a
>> priority. priority critical. Yeah. So
the idea here is you can come and change
this. You can set the true like is
deleting. You can look at all the
different loading states.
Um
is toggling. So you can check the
loaders and things like this. You can
all the things that might be passed into
this. You can you can kind of separate
concerns between like the fetching and
the data management and the state
management from actually just like how
does it display in every single state?
And storybook I think is open source,
right? Very open source. Although they
they do collect anonymous analytics if
you don't turn them off. That's I mean
that's the least you can do for an open
source library. Offer them that. That's
cool. This actually tempts me to want to
make storybook for some of our stuff to
make it easier to go build.
We have the same thing where we have a
where we have like a WASM component
where we have like a
native component a pure web component
and having rendering for that would make
life much much easier. We find it really
really useful. The thing we use this for
a lot is like
if you look in like if you're building a
coding agent, there's like a million
different outputs that the coding agent
might give you. So I'll go back to
sharing my screen. Um and I actually
might just pull up the actual Riptide
one real quick.
Um all this code that I'm showing you by
the way is all pushed to the repo
already. Um but there's edits, there's
diffs, there's grep, there's all these
different things where we're just taking
the raw data and rendering it. Every
single row in this is actually a uh is
it is a separate stateless pure
component. Hm. And so if I come into
um
I come here and I run this storybook. Um
yeah, we can run it on 6009.
Um this should just open in my browser,
right?
So here's like the real production one
with all of our different UI components
in it. Um
So here's like the draft action buttons.
Here's all of our like keyboard shortcut
stuff. Here's like the badges on the
sessions. Um but I want to find the
actual like conversation events. Oh
yeah, it's really really helpful for
like iterating on our like mermaid
renderer because like you don't actually
want to go like generate a document that
has mermaid in it in every single case.
So I can just come in here and just put
like
And it just works.
>> I can edit the yeah, the mermaid thing.
This one is not rendering very large,
but yeah, you see what I mean?
>> But
I see cuz it's again, it's pure render
only. I like this a lot. This is really
interesting.
>> here's the conversation event message.
Here's the coding agent thing is like
you can literally see every single
possible thing that And now I can see
how your iteration loop is much faster
both for you and the agent because like
you don't have to run the whole app, you
don't have to run everything. You're
literally just editing data in this
place and you're just telling the model
here's what I'm doing. And then you
iterate. It's like, oh we found this
data state we don't support. I write a
little JSON. It's like it's kind of like
how you would do unit testing, right?
But it's unit testing for visual stuff.
Is you would just figure out
Yeah. Okay. Um
Is there a hook to get Storybook to
print out a PNG via CLI command? That
would be the next OP thing that I would
want. I think it has some stuff for
doing that. I just use agent browser
basically.
Oh, I think I'm going to I'm going to
I'm so going to go on the PNG loop cuz
then I can run an automatic loop with my
agent to just like be like converge
until it looks nice.
Yeah. So I I've already been using I
actually I use the agent browser skill
from Vercel, but that one is not
installed in this project. So it found
the the G stack install that I never
removed, but G stack [ __ ] ships with it.
Browser agent. It's actually one of one
of the parts of that project that I do
really really like.
Um, but this is going to go take the
screenshot and then yeah, I think we can
open this.
Open it in
my default G stack mentioned. Um, Dex is
secretly going for a fundraising through
Garry Tan. That's his goal here.
>> [laughter]
>> I'm joking. Scary Tan have money? I
don't know. I don't
>> No, don't open it in my browser. Open
the PNG.
He should have named it Tan stack. And
just beat them on SEO. I posted I posted
that a while ago. I was like missed
opportunity to call it the Tan stack.
The one true Tan stack.
Yeah. So you can yeah, you can
screenshot this stuff. But we use this
also like to like we'll do this in PR
review too is like we will as a team
review just the storybook stuff. Like
I'll pull it down and just look at the
components.
Um, I think it even they have a paid
thing where you can even leave like
comments on it, but you can see how this
ends up being like if you can pull in
your design system and you can enable
people, I think this is way better than
Figma cuz it is just the code. There's
no translation from how are we going to
take the thing in Figma and turn it into
React code, but it's just as
interactive. So you can you can see you
can see how like if you could get your
designers cuz like Figma and
and and code it's all it's all just
markup and flexbox and like all this
stuff all these concepts are the same
between like design systems and actually
writing the React code at this point or
writing the markup or whatever it is.
And so I I think like the thing that we
see people doing is like kind of
eliminating like they still have a
design step and they still review
mockups, but the mockups are just the
React components. And then when you go
to implement it, there is no like
translate the Figma into React. It's
just already there implemented with your
design system in code and it just it's
it's already like approved by everybody.
All you have to do is like the front end
engineer's job is to then work with AI
to wire up all that data layer. The idea
of being able to build that hot loop is
really the hard part. And it sounds like
this seems like a tool that might help.
Yeah. I mean we use this iterate on UIs
all the time. We use it to fix bugs in
UIs all the time. That's how our
Storybook got so big is every time we
hit an issue or something looked bad, we
would just like, okay Claude, I need you
to like reproduce this state with props
in Storybook and then we'll figure out
how to address it. Okay, so now tell me
how big is your how big is your
Storybook collection here?
It's too big and I need to clean it up
and it's really poorly organized. Uh,
but
>> the next question. Like in code I feel
like I know how to refactor code. How do
I refactor this system? You you said
you're about to go to It is all still
code. I mean the only the only thing
that you're like really working through
is like
Okay, every single one of these is a
code file, right? So you come in here
and you see all these different items
and you're
Claude likes to rip out a ton of these.
And the other thing Claude will like to
do sometimes it will like draw something
here and then also write the component
in the application instead of like
creating a thing that can be imported in
both places. So that's another thing to
watch out for if you're doing this is
like
making sure Claude understands this
concept of pure versus wired. It's not
super baked in the in the training set,
but if you prompt it properly, you can
get you can get there.
But um, we have stuff for comments. So
this is like how we display comments in
the app. Um
and conversations. So yeah, we we we
rift all of this out as a team, but
yeah, I I need to come through and
reorganize this and make it it like
anything else, it does become bigger and
there's a taxonomy of like how do you
order things? How do you organize things
that's true with like all code.
Um But it's sort of similar to the
learning test, right? Like so Kyle
wanted to integrate this charting
library for some of our dashboards.
The first thing he did was he came in
and got it working in Storybook. And
then once those components were baked,
then it just works everywhere.
That's really fascinating.
Yeah, that's really freaking cool. Um, I
think this is something that I might
try. They can hack at if I get bored.
Next week.
I don't have a ton more content. We can
do questions. We can architect some
stuff out. I can answer your questions.
But I just thought this was a useful
thing that people people would probably
get a lot of benefit out of as you try
to like become more AI native. Um, could
you summarize the problem you solved?
Could you summarize the problem that you
solved with this workflow? Someone's
just asking me to summarize everything.
Yeah. So I I guess the biggest problem
here is like number one is like taking
non-React code designs and turning them
into React code creates this like extra
feedback loop where you need to take
what the designer did and then put it
into code and then get their thumb sign
off on it.
And then the other thing is like
the same way with unit test like if you
want to test a logic change in your
code, you have two options. You can go
reproduce that state in your app, which
may take a lot of clicking and running
and running curls and things like that.
Or if you can isolate it and reproduce
it in a unit test, then all you have to
do is make that test pass and then
things are working again.
Um, and it's the same thing for this is
like you don't have to go spin up the
whole web app and click around and
create the state that reproduces the
bug. You just as long as you can figure
out, okay, these are the props. When
this component is in XYZ state, this is
what causes the crash or the ugly
rendering or whatever it is, then you
don't have to like go generate all the
data and it becomes really easy again
with like unit test. I can make a change
to the component and I can click through
the 20 other versions of it without
having to go reproduce all those states.
So it makes it really easy to iterate in
the same way that unit test make it
really easy to iterate on problems or
changes to back end code.
Yeah, it's like here like for example
like
I'm running this code. Yeah. You want to
test your like pass result thing. You
have to actually go write a program,
spin up the playground, run it in the
program, make a change and then do that
loop.
Exactly. This is so ugly cuz it shows
pass pass twice. I know this. But that's
cuz like the data object that I'm
rendering here is not aligned. Whereas
like I go like sentiment pass fire. I
may actually want to go ahead and like
increase like render my sentiment type
slightly differently.
Yep. And in order to do this, I probably
want to Today what we have to do is go
build this whole thing out. Now if you
guys are curious I can actually show you
call to the LLM to test if your change
looks good. Like you actually have to
run the full program. And like so how do
you unit test UI? Well, technically we
have a hot reload loop here. So once you
run it once you can do it, but it's
still not as nice as what it would take.
And like
Well, if you send it to somebody else
and they wanted to see it on their
machine, they would have to go do all of
this.
Um, for example for rendering the
prompt, we want to make this prompt
rendering be a little bit nicer. So it
actually shows it to you in like nice UI
formats.
Yep. I can't really do that here.
So I will have to go ahead and like
build a UI component now for rendering
the prompt.
Um
What is BAML for newbies? It's basically
a programming language that makes LLMs
good at doing things and like make
structured outputs really good. Protobuf
LLMs. That's a good way to describe it.
It's not a really a good for newbies
answer because Protobufs is a weird
advanced concept, but
>> [laughter]
>> It basically will make your LLMs just
perform better for without any effort
and it's interruptible with any other
programming language. So you can use it
as a LangChain replacement or Pydantic
replacement or a Vercel AI SDK
replacement.
Yeah. Question from Rajesh, how do we
add new feature in a big existing old UI
repo? Our Claude agent hallucinates a
lot. I mean, if you want to make coding
agents to work well in big repos, you
should use Crispy or RPI, which we've
talked about a lot on the show. Um, I'm
actually going to ask it to
I'm actually going to ask it to um
go do this.
What I want to do right now is
I want to migrate my repo to use a
little bit more Storybook components for
the TypeScript component, especially for
the shared components in the playground.
Can you build one of the components,
specifically the data renderer
as an output for the result of an LLM
call into a
Storybook system.
This is actually the prompt that I would
write
all the way. You'll probably want to ask
if you ask the model to bootstrap
Storybook
and like add There's like two things
there's two things here, right? And this
is getting into like Alan's question as
well is like you want to bootstrap
Storybook and then you want to like
purify components. You want to take
components that have display and
business logic mixed and said that split
that up.
>> one component that I already know is a
pure component. So, I specifically did
that already. But, Dexter's point is
correct. I Notice I did this very
contextually. I recognized what Dexter
said about wired and pure, and I did not
ask it to migrate all of my stuff. I
specifically said, "Can you build one of
the components?" Specifically, the data
render as an output for the result of a
It should be called function call
into a Storybook system. I know this is
going to work better, so I'm just going
to let this rip. Um can I run I actually
sadly Dexter, I don't want to run it in
Claude code because it's going to take
too long to run it.
>> free form, dude.
Just run a free form.
Free task.
And then just make a session.
Well, I was going to run the plan mode
and then run this. Cuz free form will
not work. That's why.
Um cuz I do want a little bit of plan
mode cuz I don't want the I want I don't
want all the code to be
You could do free form and jump straight
to uh structure outline skill is what I
do sometimes. It's basically like a mini
plan.
But, it's fine.
Sorry. I do really like uh Riptide for
almost everything.
Uh but for this This is good feedback.
No, we we want to try to make it more
accessible for like tighter, smaller
workflows like this. One-off [ __ ]
Yeah, like what I really want is I want
this, I want this, and I just want to
run it. And this will do something.
Um while this uh while this runs, um
Well, I think this will this will
probably address most of your questions
of like how good it is. And we'll get a
really quick answer
very fast about whether or not
uh we're able to produce a good outcome
um
for migrating to Riptide and migrating
to um
Storybook in a new code base. If this
works, then we know it works in like new
code bases, brownfield code bases.
Um pretty standard
>> it You can do it incrementally, right?
You can just do like bootstrap
Storybook, and you get like a couple of
those like hello world stories just like
with some buttons, and then you could
say like, "Cool, take this component and
add it to Storybook and like split it
into wired versus pure." Or if it's
already pure, you can just You can just
do it that You can just say like, "Okay,
put this pure component in Storybook."
You generally don't want to have your
like stateful components that are making
API calls and stuff in Storybook. That's
not what it's for at all.
Um but yeah, let's see what this guy
comes up with. Well, while this runs, uh
Jack, you asked, "How do I build a
classification workflow?" Uh here's like
one example, really fast.
Notice this UI is really bad because we
don't use Storybook. We're working on it
literally right now.
Um thanks to Dex.
Uh if you want to go like a
classification example, it's like
something like this.
You be A classification is basically a
function that takes in like a chat
history or like a user message,
and it spits out a category.
In this case, I have categories defined
as an enum.
Uh no, we don't take sponsorships. We
literally only
we only show code that we are
proud of showing and tools that we like
actually like using.
That's so hopefully it's unbiased
content.
Um and then you just define the prompt.
So, the prompt is written like this. You
can see the prompt. So, like in this
case, I've got a quick little test case.
And like if you just run this, we can
just see what this runs as.
It runs as account issue because it says
I can't access my password login
credentials.
You get rid of account issue, we can see
what it pops up in as.
And it comes in as technical support,
which again is probably right. So, you
can just like build
evals and test cases as you want to go
and quickly understand this workflow.
And for like more complicated systems
like extract receipt, you can have a
receipt data type. You can pass in
images.
And then it kind of just like works for
you. And there's small things it does
like if the LLM messes up on JSON, you
still get the right type. And it plugs
into Python TypeScript pretty
straightforward.
I still don't have a plan. God dang it.
I was really hoping I'd talk for a
minute and we'd get back to plan mode.
Yeah, your code base is really big,
dude. You got to make it You got to make
it little. We want little cute little
cute little code base.
Yeah, yeah, I know. It's very
unfortunate.
Yeah, this website is just
promptfiddle.com. Yeah, it's it's it's
the hard part about big code bases. Like
once you have a bigger code base, like
sadly
agents just runs everything in them is
just slower.
But, this is also why I wanted to run
plan mode because I didn't want the full
plan mode that like Crispy has, which is
like very, very rich.
Uh cuz that would take like 15, 20
minutes to go get anything out of. But,
this plan mode is also going to take
like 5 minutes.
Yeah. But, I think it should hopefully
one-shot it.
What is
WCAG
type stuff? I don't know what that is.
What WCAG?
Web Content Accessibility Guidelines.
Well, I mean accessibility, I think just
use Shadcn and Radix UI, and they do all
that for you.
Um but yeah, Storybook also will do
things like audit your contrast levels
and like tell you if your contrast is
high enough for certain guidelines.
Um
So, they yeah, they have they definitely
have plugins for that as well.
That's cool.
And then I definitely want to make sure
that uh Oh, Dexter, by the way, you will
have to take down the stream because I
shared my API key.
So, in Okay. Which API Just go Just go
rotate it, dude. Oh, that's a great
idea, actually. Let me go rotate my API
key. All right. While Claude is working,
Vibob's going to stop sharing and rotate
his API key so I don't have to go
through the Twitter stream.
>> All right. Uh
that's so annoying.
I wish it would made it so much easier
to
>> beta open a bit, the UI to choose Crispy
versus free mode would be the best of my
week. Ignacio, it's coming.
We are cooking hard on a bunch of things
right now. Let's see what else.
>> I'm logging into ChatGPT as we I'm just
looking for other questions here.
Um yeah, Storybook won't help if your
designer is Claude. Yeah. At the end of
the day, like certain things you just
want to write the code. Uh but Storybook
is really powerful. Like you can do all
the things in the browser, right? You
can right-click, you can inspect, you
can look at the padding, you can figure
out where weird spacing is coming from.
Like you can do all the things you can
do in Figma, but you're just doing it
directly in the browser. I get it. Some
designers are going to roast me for
this. They're just like, "You don't
understand design, and Figma does all
this stuff that like I can never do in
React or is like painful to do in
React." Or like, "Don't make me write
code." I'm like, "That's fine, I get
it." But at the teams I'm seeing moving
the fastest are getting uh folks to
adopt AI, and your options are either
like get your AI to write Stitch or
Figma or Canva and like interact via MCP
and do all this stuff that's not really
in distribution compared to just writing
React code, which is very much in
distribution. The models are really good
at it. And it's the same way. It's like
I know some
I know some folks I'll let you read
this. I definitely know some folks who
are like
they build coding agent tools, and they
work with large enterprises, and they
say like, "If you're not willing to
migrate to a mono repo, then we are not
going to work with you." Because the
teams that are willing to migrate to a
mono repo are just going to get so much
better results from agents that like it
is not worth our time and like you're
not going to get as much value out of
this unless you're willing to do that.
And I think this is the same thing where
it's just like yeah, it's new skills,
it's a new way of working, but there is
so much upside to being able to write do
all your design with Claude code in a in
a like place where Claude code is really
good, which is editing files on disk,
that if you adopt this, like yes, it's
new skills, and maybe it doesn't have
everything, but overall, you're going to
go faster, you're going to enable more
more types of people to contribute to
the visual and design of your website,
and you're going to make it so much
easier to take designs and get them
straight into production that I highly
advocate for like find find a way to
like move things out of Figma earlier
and earlier in the process and get them
into actual built components. Our
designer started using AI to code, and
he hates Figma now. There you go.
Okay, Justin said he only spent a tiny
bit of your token. Okay, we are good to
go. Tokens are saved, and my API key is
now swapped. Sadly, uh sadly, yes. Um
and then
um sadly, I do have to read this, so I
can't just vibe it because I have
opinions, and I'm in I like to read the
plan.
Um
>> Always read You have to read the plans.
You should read something.
Frameworks Storybook eight.
>> [snorts]
>> Are we on Storybook 10?
Okay, then let's let's talk.
Yeah, you need store You should get
Storybook 10. It's the latest. This is
why we do plan mode.
Yeah, because it would have installed
This is the problem with the models I've
been baking and stuff. That repo is
maintained by us. Claude is so annoying
sometimes.
Oh, it took a while to reset the API
key. That's so annoying.
Yeah, I agree. The web search fetch loop
is really dumb.
I think we could by 11:15, we should
have Storybook components running. It
should be very easy to have it running
end-to-end. Okay. I I believe that.
Yeah, I had a bootstrap Storybook and
add five components in about 5 minutes
earlier today, so This is actually the
problem that I run into most of the
time. Um
Sure, I don't care. This is the problem
I run into most of the time. I I like I
didn't know Storybook eight was the
latest, and I would have been a slightly
lazy, and I wouldn't have checked. But,
because Dexter knew off the top of his
head, boom, we're actually getting the
right fix.
This is probably one of the most
annoying things. I wish there was a way
to cross-check versions of stuff
uh and force the model to use the latest
stuff. When we There's this crate
>> Crispy, it would have used a web search
researcher to go find out what the
latest Storybook was instead of using
the default Claude Claude Claude
>> it by default. It doesn't do it by
default.
>> tell it to search the web for the latest
Storybook.
>> I would have I would have to tell
[clears throat] it cuz I Yeah, exactly.
It's like
It has
>> [laughter]
>> It has nothing to do with that. Just
like I just have to go
do this. We had the same problem when we
ran into uh when we used this crate
called Salsa.
The LLM It's a Rust crate for building
like compilers and like sta- like
caching and stuff in them, so they're
fast.
We had the same problem. We're like by
default it did not use the latest
version of Salsa.
Uh and like you had to prompt. And now
that we use the latest version it does
the right thing, but like the initial
plan was like use like uh a year older.
Yeah, so Joe's talking about doing
mock-ups in Figma make and or Google
Stitch and then create plans with the AI
based on that. The challenge there is
that you're not going to know how it
looks until your plan is actually
implemented. You can't read the plan and
know whether it's going to look good or
whether it's going to honor the like
thing that you wanted to build compared
to actually just pausing and having it
build the pure components, which is
really easy to do. Like you don't need a
plan to build one pure component or a
family of pure components from an
outline. And then what I will always do
is just like riff back and forth and
vibe all the states of that component.
And then we'll go do the plan that is
like working across four different
systems across two different repos to
wire everything in.
Um yeah, what do you got here?
>> That looks pretty good. Um Okay.
>> That's really nice. I like that. It's
actually showing like all the objects.
This is exactly what I want.
>> Yeah.
Yep. All right, ship it.
Let's run it. Um and notice I kind of
skipped a few things, but I just I did
want to read this part. And I was like,
oh, that's how it's what's going to show
me in Storybook. Great. I'd be very
happy with these stories.
So now we cook. Um you might want to
>> Now we cook. As soon as it bootstraps
Storybook you should be able to just run
it.
I wonder where it's actually going to
put it. Yeah, there you go.
You know what I hate about Ghosty? It
doesn't do split terminal. It's so
annoying. They don't have panes yet?
No, or maybe they do, but I don't know
how to do it.
See?
My my noob uh my noob coding abilities
don't allow me to use tmux.
Oh, they do have panes. How do we do
that
uh Prayash?
Yeah, Prayash tell us how to teach
Vibhav how to use his terminal, please.
Split right. There you go. Wait, it was
there.
>> Where?
File.
Oh my god, are you kidding me?
That's so hard. [laughter]
I think I just got leveled up. Uh this
is why I secretly do this podcast so I
get taught how to use basic stuff.
>> [laughter]
>> Yeah, and we do the same thing as what
um Dexter's talking about. We have this
core package playground that we actually
ship into like a WASM component, a pure
React component, everything else too. So
it looks the same everywhere.
Uh no. Uh I I know all of you like these
command shortcuts, but for me I'm I'm a
clicky boy.
Uh I like clicks.
Uh still don't have Storybook running.
I hate coding agents sometimes. I'm just
burning money out here.
All right, Dexter, while we wait
>> Manny says, "Was this episode sponsored
by Storybook? Just wondering how many
other tools workflows you guys tested?"
Look, man, it's not about the tool we're
using here. And actually like in 2014
when React was brand new and Storybook
didn't exist, our designer on the team I
was on built a version of Storybook.
Like it's not hard to build a component
that renders other components with
random props. You could probably vibe
code a version of Storybook that does
everything that you want in
the next in in in not a lot of time. If
you know what you want is you basically
want to I I want to be able to see six
versions of this component with
different combination of props. Like
yeah, you don't necessarily need
Storybook. We like it cuz it has a
couple of affordances and it has things
for like if you have a theme switcher in
your app, it does themes nicely and
stuff like that. Uh but no, we don't do
sponsors here. We just talk about
technology that we're excited about.
What is this? Why can't I run this,
Dexter? Oh.
>> Dude, don't talk to me. Talk to Claude.
Okay, here's your result display.
Doesn't have any of your styles, but
Why doesn't have my styles? I don't
know. Tell Claude it it's probably still
working.
Yeah, probably. Uh but click on some of
the other items. There we go. It
actually made a
I don't know what I want, but it's got
something.
Okay. Oh, I do want redaction there.
Look good for it for recognizing that.
I'm actually going to hide the
authorization key by default so I never
have that problem ever again.
Uh this is disgusting. And this is
literally what it sends. This is why it
sends this. I don't know if the logic is
redacting or if it just put redacted
props in, but
>> Wait, I think it did everything, but it
didn't pull up my
Okay. So what I'll do is I'll copy this
looks like [ __ ] It needs the it needs
more styles. Or yeah, drop in the
screenshot. I feel like I'm missing the
styles here.
Yeah. So bootstrapping this and getting
the styles brought in and stuff like
this is uh
But uh That's cool. placeholder.
Um
I think the the snapshot testing stuff
is it can get a little brittle sometimes
and it's
uh I like to test things visually right
now. Um but yes, if you want really
wanted to scale stuff and prevent
regression, then snapshot testing is is
a way to test our business logic and
make sure your like layouts haven't
changed, but I think the problem with
snapshot testing is like it's only as
good as the data set that you create. So
you have to be pretty rigorous about
like, hey, when something breaks and
like
fails in production or whatever it is,
then you got to pull in that data and
make a new snapshot test out of it so
that like people don't accidentally
break it in the future. Any thoughts on
QA and browser-based agents for QA? I I
mean I think automation just gives you
all the wins and the losses of
automation. The more you automate, the
more Like think about when COVID
happened. Like why did we have that
toilet like toilet paper gate? Well,
it's because like
like genuinely it's because our supply
chain is so intrinsically tied together
because it's fully automated that you
break one thing in the supply chain,
everything down the stream of it breaks.
And obviously that didn't happen with
toilet paper cuz like it turns out
people don't actually people just
hoarded toilet paper
as opposed to needing it, but did happen
with like technical stuff where like
some supply chains broke for like how
long shipments for like computer car
computers and cars ended up happening.
And that's because cars got really
expensive because chips got delayed,
right? Like did the chips didn't ship
>> delayed. And then all the ships that
they had pre-bought like Apple doesn't
magically get shipments working in
December. They pre-buy all of that
stuff. If any of you know like futures
markets are like people don't only just
like hope that wheat is a or corn going
to sell eventually. They actually
farmers like pre-sell all their wheat
and all their corn ahead of time.
And the reason for that is because
people like stability in systems. And
that's one of the things that you need
with automation. You need long-term
stability.
And then when you end up when you end up
in a world where like for example like
you automate everything with QA,
you will have a faster system, but when
things break, it'll be you have to
really slow down and then fix it.
So it's just like the trade-off that you
make.
Um and like [clears throat]
what I personally find is add as much AI
as your QA system is going to be able to
handle in terms of how much slow down
can you accept when you really have to
stop and reset. Oh, let's see if it
works.
This is sick.
And now you can see that arrays are not
good. So I can actually just tell it
this and I can say, great.
Oh, this is a thingy. Like this is
actually broken in the product, too. Oh,
yeah. It's broken right now. I know.
We can see over here that arrays don't
work well.
>> without having to go like reproduce the
use case. There you go.
We can see over here that arrays don't
render well. Um we should do something
clever for them. And like empty arrays
render differently than closed arrays,
which is nice.
This is what I'm going to have to fix
later, too. I don't like the This is so
nice. Thank you, Dexter, for doing this.
And we can see exactly what the win here
is. Like I don't have to like produce
everything all the time. I can just come
up with
all these edge cases and just could
decide exactly how we want to render it
right away.
>> And as soon as a user comes up with an
issue, you just paste it in the Claude.
You'll be like, "Hey, here's a bad
state. Add it to Storybook and then
we're going to fix it."
Exactly. And like I can actually see
exactly and like it it's going to do
this and like probably
boom. It actually does this.
Nice. And it made an array of objects.
It's actually like showing me different
things in here to give me what it does.
And it I agree, this still kind of looks
bad.
So the AI still want to kind of like
>> and you don't have to iterate it on the
app. You're just iterating on the pure
component. This is freaking awesome. Our
playground is going to get a lot better
just thanks to this.
Nice. See, I I like I I I pitched this
episode like it sounds dumb, but I bet
this is really useful for a lot of
people who are trying to figure out
agentic coding and like the new SDLC.
And I think I think doing these like
component preview style things, whether
it's in Storybook or something you vibe
coded or one of the many other things
that does this is going to be really
important.
>> Yeah. And I it's like it's kind of
weird. It looks kind of tacky, which is
why I don't like it, but like
uh the general thumb like I
it does it's going to look nicer to do
this
than it will to do anything else. So I
love this. This is great. Thank you,
Dexter, so much. Yeah, and you can
control the stage and the frame. Like
you can actually put a static image of
VS Code in here and so this will all
display in the in the VS Code thing.
Like you can you can customize a lot
here.
Oh, no. I I mean we don't have to Oh,
what do you mean like the frame?
Like see that white border around it?
Yeah. Like you can customize that. You
can pick what color it is. You can make
it literally a VS code thing, so all of
this renders inside on the left on the
right side of a VS code pane, so it
looks more realistic. You can do
whatever you want here.
>> That's cool. No, I think I just like
this idea of like even this alone I I
this has been something I've been trying
to get to for a while. It's just easier
to do this now cuz I iterate faster.
Yep. I think iteration speed is under
valued.
Make sure it's actually importing your
your your shared components and not just
vibing out a bunch of [ __ ] in storybook
that doesn't actually impact your app.
That's the one thing I've seen Claude do
sometimes.
Now what I can do is do this.
Uh it looks like it made this and it
looks like it made stories.
Yep. So just go I would just go yeah,
okay. So you modified result display. I
would just look in result display that
stories.tsx and make sure it's like
importing your actual shared component,
but I'm I have high confidence that it's
that it's happening properly.
So the structure of this is an
interesting file. So you create like
versions of it.
Um but it looks like these all come off
of yeah, story type of result display.
So it is importing it and using it.
Great. Interesting. And this is what it
actually renders now.
Yep. So it's just like hey, render that
component with these different sets of
props. I see. I see. Yeah, one of the
things that I've been trying to think
about I'm going to I'm going to see if I
can get a hackathon project here is I
really want users to be able to
customize how their objects render in
the playground. So imagine you have a
class and you want to say like I'm going
to render this class with like a custom
React component. Ooh. Exactly. Cuz
that's how we do this. That's how like
the system prompt and user prompt
renders differently. That's how like the
HTTP web request renders like this
instead of just like a plain object. We
have like a registry of like you can
register things to different types.
So you could imagine
>> in your test like function in BAML where
you're testing a prompt and getting an
output, you can set a custom component
instead of just printing the JSON, it
actually shows the user like card
streaming out or whatever it is.
Exactly. Exactly. And I feel like that'd
be so freaking cool. Like right over
here one of the things I want to test Go
ahead. You go ahead. No, it's it's good.
Um I've just it's 11:15, so we should
probably wrap up soon. All right. I want
to try one more thing and see if this
looks cool. I want to show an array of I
want to show an array of HTTP request.
Cuz I want to see what that UI looks
like. Cuz that's really This is like
something I couldn't have done before.
Mhm. Yeah, an array of HTTP request.
Yep. So you may not even be able to
produce that state in the app today, but
you can test it this way. Exactly. I
actually cannot produce I mean, I can,
but it's kind of annoying. But it's
>> now you haven't built all the wiring for
handle array of HTTP request, but you
can decide if it looks good and if it's
even worth building before you go do all
of it.
Exactly. And now I'm like oh, and like
um you know, I don't like this. I can be
like hey, if it's an array of objects
actually just make it like a pagination
thing.
Yep. Which could be kind of nice to be
able to just like paginate through all
the different elements of the array.
Yep.
Well, thank you. This makes life much
easier, much cooler to navigate across,
and I'm excited to be able to add
storybook. Time to peace out. Adios,
amigos. Thanks, everybody. See you.