“I haven’t written a single line of front-end code in 3 months”: Notion’s prototype playground

The way I think about designing B2B SAS is you want your designs to encounter reality as early as possible. I've

always been into prototyping and then all of a sudden these AI coding tools come along and now I can prototype faster. I can prototype in production.

faster. I can prototype in production.

>> So explain to us what this prototype playground [music] is.

>> It's just an X.js app. All of our prototypes are in one place. Seeing what

other people are working on is really fun and interesting. And often times you spot cool ideas and you're like, "Oo, I want to try that." The code is all in one place. It's just in one repo and so

one place. It's just in one repo and so I can just yank cool ideas from other people's prototypes and incorporate them into mine.

>> Every time somebody is like a little anti- AI assisted coding, I'm like, do you know that I used to have to walk uphill both ways for my CSS? It was not fun to do this.

>> I mean, even just sitting here watching this, I still just find this magical.

>> Welcome back to How I AI. I'm Claire

Velo, product leader and AI obsessive here on a mission to help you build better with these new tools. Today we

have a designer ccentric [music] episode with Brian Leven, designer at Notion AI, who's going to show us how he set up a prototype playground for the entire

Notion design team to vibe code using Claude Code any prototype they need.

This is a great one for someone looking to either shift their design organization into a code first prototyping mode or learn some advanced techniques with cloud code. Let's get to

it. This episode is brought to you by

it. This episode is brought to you by work OS. [music] AI has already changed

work OS. [music] AI has already changed how we work. Tools are helping teams write better code, analyze customer data, and even handle support tickets automatically. [music]

automatically. [music] But there's a catch. These tools only work well when they have deep [music] access to company systems. Your co-pilot needs to see your entire codebase. Your

chatbot needs to search across [music] internal docs. And for enterprise

internal docs. And for enterprise buyers, that raises serious security concerns. That's why these apps face

concerns. That's why these apps face intense IT scrutiny from day one. To

pass, they need secure authentication, access controls, audit logs, the whole suite of enterprise [music] features.

Building all that from scratch, it's a massive lift. That's where Work OS comes

massive lift. That's where Work OS comes in. Work OS [music] gives you drop-in

in. Work OS [music] gives you drop-in APIs for enterprise features so your app can become enterprise ready and scale up market faster. Think of it [music] like

market faster. Think of it [music] like Stripe for enterprise features. OpenAI,

Perplexity, and Cursor are already using work OS to move faster and meet enterprise demands. [music] Join them

enterprise demands. [music] Join them and hundreds of other industry leaders at workos.com.

at workos.com.

Start building today. Brian, welcome to How I AI. What I am so excited about in terms of our conversation today is you're going to show us about how one of

the best designed products out there, notion is being designed by people like you using these new AI tools like cloud

code. So why did you make this shift to

code. So why did you make this shift to how you were doing design, what it meant to prototype, design and build things, especially for a product and in a

company who values design so highly. The

way I think about designing B2B SAS is you want your designs to encounter reality as early as possible. And you

know, if you imagine this gradient of like I'm scribbling on a napkin on one side to I'm shipping to production and showing customers on the other side. Our

goal as designers is to move up that gradient towards prod as quickly as possible. So I'd say for most of my

possible. So I'd say for most of my career I've I've sort of biased towards being interested in programming mostly at the prototyping level. I just find that when you're designing something in

Figma and then you actually try it in the browser in the browser you notice a ton of problems. You know all of a sudden you're clicking things you notice loading states you notice ah that didn't

quite work on this screen size. So you

encounter um some version of reality sooner and you end up getting to a better design more quickly. So you know I've always been into prototyping and then all of a sudden these AI coding

tools come along and now I can prototype faster. I can prototype in production. I

faster. I can prototype in production. I

can uh or what I most often do now at notion is just prototype in a little internal tool we've built called prototype playground. And again, the

prototype playground. And again, the idea is just like how do we get something that's somewhat realistic in a kind of real environment, in our

case, the browser, uh, as quickly as possible and I think that just helps you move faster and end up with better designs.

>> So explain to us what this prototype playground is and how you set it up and how you might use it.

>> Okay, so prototype playground is nothing magical. It is just a Nex.js project.

magical. It is just a Nex.js project.

So, uh, actually here just source apps and there's an app directory. And you'll

notice here in our app directory, we're normally in an Nex.js uh app, you would see pages. Um, well,

we've just namespaced every designer on the team or PM or engineer, whoever signs up and wants to use it can just namespace um some directory. So, here is

Brian. And then every directory inside

Brian. And then every directory inside of that is some prototype. And so it's just an X.js app, but each page is sort of a standalone. There's no global

layout. There's no global I don't know

layout. There's no global I don't know like structure that you have to adhere to. And so what that looks like on the

to. And so what that looks like on the front end is this. This is what we call prototype playground. And it's just a

prototype playground. And it's just a list of prototypes ordered by who is working on stuff recently. So here's a few from December and then a bunch from November. And it's really cool because

November. And it's really cool because having everybody's prototypes in one place is useful in two dimensions. One

just from a visibility point of view, seeing what other people are working on is really fun and interesting. And

oftentimes you spot cool ideas and you're like, I want to try that. And

then on the other dimension is like if you spot a cool idea and you want to try it, the code is all in one place. It's

just in one repo. And so I can just yoink cool ideas from other people's prototypes and incorporate them into mine. Usually usually by just telling

mine. Usually usually by just telling Claude to do that. Uh

yeah, I think before prototype playground there was a lot of designers at notion who prototyped in code. The

difference was we were all creating our own repository, our own Nex.js instance. And

so it was hard to know where everyone's stuff was. as everyone was rebuilding it

stuff was. as everyone was rebuilding it in different ways or if people were trying to recreate something that looked notion-y, we were all doing it from scratch. So anyways, prototype

scratch. So anyways, prototype playground next.js app. All of our prototypes are in one place and then we have a few shared components and shared styles. So if you want to make something

styles. So if you want to make something that looks notiony, you can do that pretty quickly. So for example, we have

pretty quickly. So for example, we have some templates here. I can show you like notion UI is just a notion sidebar. And

actually, this isn't even very notiony.

I think at some point I I slipped this new button in here, which obviously doesn't exist in the the the product. I

don't think these things do anything, but it's close enough. If you're like, "Oh, I needed to prototype something with a notion sidebar." I can just come in here and duplicate this template. And

then we of course pull in a bunch of our colors, typography, icons. So that

again, just getting to close enough Notion styles uh without a whole lot of effort.

>> Yeah. Yeah. And I want to call out for people a couple episodes ago, I showed how you could build a very similar Nex.js app for yourself that had a combination of docs you were working on,

mock markdown docs you were working on and prototypes in a very similar format where it was like here's my folder of just stuff I'm working on. Very minimal

shared components, very minimal shared styles. I like this too because it's

styles. I like this too because it's nice to have that team level organization so you can pop in and see >> who your teammates are working with. I

have a question from an operational perspective. Did you set this up? Why

perspective. Did you set this up? Why

like was this like a passion project for you? Uh did engineering set it up for

you? Uh did engineering set it up for you? Like how did this actually get

you? Like how did this actually get created?

>> Yeah, I set it up with another engineer.

I mean it's just anjs app but then operationally just a few approvals. It's

deployed on Verscell. We had to like go through a little bit of process to get that project spun up, get a few people added as members.

Otherwise, yeah, it's not that much.

Again, it's just a pretty basic Nex.js app, which you can literally use Claude to like help me make a Nex.js app and it's just going to get you the default.

>> I like, you know, I like keyboard hands.

Everybody does the same keyboard hands motion where it's just this. [laughter]

I have one more question which is >> of the people now working in this repository how many before >> were working in >> code versus this is their first

repository that they've cloned to you know their desktop or deployed it was the design team pretty technically adept already so this was very natural or were there some people that needed to be onboarded

>> I think so I mean to be honest prototype playground is still really for me like I think I use it the most you can See here, there's a bunch of other people that that are creating things. But if

you were to go through, I probably use it the most. I think there's maybe like five to 10 people at Notion that use it quite a lot and then a bunch of people

who either have tried it and it didn't stick. Um, and we can get into reasons

stick. Um, and we can get into reasons why that is or they're just not interested or they prototype separately, right? Like we still have people

right? Like we still have people prototyping in Figma. We have people that prototype in their own codebase still. they just prefer their own stack.

still. they just prefer their own stack.

Maybe they don't like Nex.js, maybe they don't like React, so they do something else. Um, and I think all that is

else. Um, and I think all that is totally fine. In fact, one of the the

totally fine. In fact, one of the the features I added recently was this ability to link to an external prototype. So, if you prefer using Vzero

prototype. So, if you prefer using Vzero or Lovable or a Figma make file, whatever it might be, you could just link to it here. And in fact, this is what it'll show up as in prototype playground, just have this little

external icon. And so, you can click it

external icon. And so, you can click it and it'll open in a new tab. So in

theory, this could be the prototype playground or repo for any prototyping tool. My hope is that over time we make

tool. My hope is that over time we make this thing useful enough that more people will want to prototype in it because it's just faster than those

other tools. And we got to figure out

other tools. And we got to figure out how to lower the the onboarding complexity for people who aren't technical before. So to answer your

technical before. So to answer your question, um I don't know. I'd say some people who weren't technical made their very first code prototypes or like AI

assisted prototypes in the playground.

Um but probably the majority of us that are still using it daily had some technical background.

>> Got it. Perfect. Well, let's prototype something. I want to see how it actually

something. I want to see how it actually works.

>> Let's do it. Um okay, so there's a few ways to make new things in Nex.js, right? Like we could be in

Nex.js, right? Like we could be in cursor and we could come in here and create a new folder and create a bunch of page.tsx and metadata files and that

of page.tsx and metadata files and that sucks. I don't want to do it. Um, so

sucks. I don't want to do it. Um, so

there's two ways around that. The first

is when you're running in local host, you can actually just click this button that says new and you give your prototype a name and a description. I'll

call this one um, how I AI and then this is for fun. And I create that. And all

that's doing under the hood, if we bounce back over to cursor, is it just created those files for me on my computer. This is my favorite part is

computer. This is my favorite part is like there's no backend for prototype playground. It's just all files on disk.

playground. It's just all files on disk.

Uh and then we can just push all this to GitHub. So here we have like a little

GitHub. So here we have like a little metadata file. These get sort of

metadata file. These get sort of collated to render the list on the homepage.

We have an actual uh prototype file here with some code. And then this is kind of nice like it automatically gives you a button to open it in cursor. So now I can just come in here and start

prototyping. Now typically my workflow

prototyping. Now typically my workflow is I just f open claude in the terminal.

I know this isn't how you're supposed to use cursor, but it's just it's just how I do it. It's probably not even how you're supposed to use claude code, but >> I just do it. Um

>> we're just equal opportunity offending these two tools.

>> I know. I know. Sorry everybody. Um but

this is how I like to work. Um, and in fact I have a little shortcut here where I can just press uh caps lock G and then

I can get these two things side by side in my computer. So I usually am clotting over here reviewing the changes here and

then monitoring sort of the output over here. So let's see here. Uh, I want to

here. So let's see here. Uh, I want to make a prototype and I don't know, let's just come up with some contrived example like maybe you can help me think of a a

good good use case.

>> Can we make a prototype for oh like a little a video and audio? This may be complicated. Video and audio like

complicated. Video and audio like display module for my my podcasts.

>> Video and audio.

>> So it show like video and then maybe like an audio player. Let's see. I you

know it's it's Opus45. I think it can do it.

>> Okay, let's try it. So, normally, uh, let's walk through like my actual workflow. There's sort of two steps. One

workflow. There's sort of two steps. One

is you can type a lot. Uh, that's not that fun. Um, I do use this tool called

that fun. Um, I do use this tool called Monologue where you can just talk to your computer. There's many

your computer. There's many >> products like this. I think monologue is just nice and cute. Um, so we can just talk and it's just much faster than typing our prompt. The second thing you'll notice with cloud code is I

switched over to plan mode. I think it's really, really important to plan before doing anything. For whatever reason, you

doing anything. For whatever reason, you just get better outcomes. Now, the key thing about using plan mode is to actually read the plan. And I think this

is where having a development background just gives you an edge because you can read the plan and be like, "Oh, that part actually doesn't look quite right."

Whereas, if you maybe don't have as much programming experience, it would be harder to tell that. But in either case, I still find that having the plan mode and creating some structure before actually writing code is better. So,

let's just do both of these things at the same time. So we're in plan mode and I'm gonna invoke monologue here and it's recording. And so let's say I want to

recording. And so let's say I want to build a new prototype in this how I AI directory

and we are a podcast and I want to build a detail page for a podcast episode that has both a video player and an audio

player underneath. The page should have

player underneath. The page should have the title of the episode, a description,

and how about if you hit play, there's little confetti that shoots up out of the player. And so we end that. And now

the player. And so we end that. And now

I will delete this. And we plan.

>> So I have to give you props on two things. One, I am also a plan mode slash

things. One, I am also a plan mode slash like write your spec, write your PRD person. Obviously, I think the second

person. Obviously, I think the second thing is I am still just such a read the code, read the outputs girl when it comes to AI. It's actually one of my

challenges when I use something like claude code or watch people use cloud code is if you don't do it inside a cursor or something that gives you this sort of I love your three pane window

your like code window your cla window your output window because I see people with like 17 tabs of quad code going just accepting a bunch of changes and I have

to read I think this is also just >> like engineering development background where you can just spot things that make no sense in the moment as opposed to having to go back and and debug

something. So, I am I am very much

something. So, I am I am very much aligned with you on that.

>> Yeah, it's helpful. Um, and you know, this is probably obvious to a lot of people who are familiar with using cloud code, but maybe if if you aren't, like another piece that's really important

here is getting the right context up front, right? like we just typed in some

front, right? like we just typed in some prompt. Um, but under the hood, I can

prompt. Um, but under the hood, I can show you we actually have uh some other files helping us out here. So, we have a cloudMD file at the root of our project with just some rough instructions around

like the tooling that we use like we use bun, we use tailwind. It has like a rough outline of the project structure.

Another thing that we do is anytime someone runs the project locally, we create a cloud.local.md local MD file and that local uh file is not committed

to the git repo. So it's personal per computer and it adds a little bit of extra context like hey this is my username in prototype playground. It

tells claude where my directory is and it gives some instructions like hey you know don't go around and mess with other people's files like prefer to work in my directory and a little bit more about

the workspace structure and how like individual projects can be built. So, a

couple of those things are are working under the hood here.

>> And while you're accepting some of these cloud code changes and questions, I do want to call this out for folks because I think people are pretty aware of the Claude MD global um settings, but I

think people forget that there are actually locally scoped versions of these that you can implement. And so

it's really useful to get one version deployed to everybody that gives you your master rules for using claude and then you can set up your own custom one with your own particular preferences.

And I think that's a really nice way to create a good collaborative environment where people are using a similar AI tool or agent to to work in the repo.

>> Totally. Yeah.

Okay. I don't know. We'll we'll see how this goes. But it's going to install

this goes. But it's going to install some sort of confetti. It's going to have a player audio player. Really

awesome. Like it does a wireframe in the plan, which is crazy. Um, and here, I don't know. We can just kind of skim

don't know. We can just kind of skim this for the sake of this example.

>> Uh, this looks fine. So, let's auto accept edits. Now, I have a tip for for

accept edits. Now, I have a tip for for people because I think when you spend enough time on Twitter or watching other people use these coding

tools, people are always like, "How do you get it to run for longer?" You know, they find themselves constantly getting stuck or the agent does the wrong thing

or it's asking for their input. And my

philosophy on this has been anytime the AI asks you to do something, you should before responding, try your best to see if you could teach

the AI to answer that question for itself. There's a good example. Oh, wow.

itself. There's a good example. Oh, wow.

That was very fast.

>> Ooh la la.

>> Well, here, let's let's hold on that and see if the confetti works. Well, actually here the example is I've already taught Claude to like always lint itself after it's done, right? Like what's really annoying is when it builds a bunch of

stuff and then you go and look in your browser and there's some error, right?

So, for example, I've taught Claude, hey, check your work. One, you can run commands like uh what was this like eslint, right? And like look for actual

eslint, right? And like look for actual TypeScript errors. The second is you can

TypeScript errors. The second is you can give it access to MCP tools. So,

Playright is one, the Chrome Dev Tools, MCP is another one. And you can say, well, actually, you know, before installing this, Claude would say to you, hey, I've

implemented your feature. Go take a look at it and let me know what you think.

And remember, our rule is anytime Claude tells you to do something, ask if you can teach it to do that thing for itself. So, I don't want to have to look

itself. So, I don't want to have to look at the browser every time to see if I did it correctly. So, instead, I teach Claude, actually, you should be the one to go and open the browser. So, it knows how to launch Chrome. It knows how to

navigate here. It knows how to click the

navigate here. It knows how to click the play button, look for confetti, make sure the audio is working, all that kind of stuff. And so now we we were able to

of stuff. And so now we we were able to run this task for much longer without my input and actually get to something that is working well. Um

>> I I'm actually very impressed with this prototype. It's much more lovely than I

prototype. It's much more lovely than I thought it was going to to end up. Much

more robust. And the confetti looks great.

>> The confetti looks great. Yeah. Well,

here I'll I'll show you another example.

This is, I think, where the power of MCP gets crazy. So, let's let's actually

gets crazy. So, let's let's actually clear this. We're just going to start

clear this. We're just going to start start a new new conversation here. I'm

going to just totally undo everything.

Let's just start from scratch. So, uh, a couple other things that I've built in, you know, I think, uh, remember like I'm trying to make the onboarding flow as

simple as possible for people on my team.

>> Yep. Um, so what Claude has is called slash commands.

>> And you can just build these yourselves and they're basically glorified prompts, but they can also run scripts. And so we have some slash commands in the project that help people get going really quickly. So I have one called create

quickly. So I have one called create prototype. And then you can give it an

prototype. And then you can give it an optional name. So we'll call this one

optional name. So we'll call this one how I AI. And that's going to do the same thing as clicking the new button on on the the browser, which is what we did

earlier. Uh the difference of course is

earlier. Uh the difference of course is I don't have to click things. I kind of want to design this so that I basically live over in the terminal.

>> Can you show us really quickly in your repo just how these these commands get defined? Perfect. Thank you.

defined? Perfect. Thank you.

>> Yeah, sure. So uh again it's basically a glorified prompt. Um it has a name, a

glorified prompt. Um it has a name, a description, and then some instructions.

So in our case uh we say uh kind of how to come up with a name based on what the the user provides tells it uh where to look to determine the current user's

username how to create the new thing. It

actually provides some sample code to use for both creating the page and the the metadata file. I think I need to

also approve this. So it goes let's just do blank for now.

uh as well as creating the metadata. So,

you know, AI is better with good context, but it's also really really good if you just provided examples of how to do things.

So, the reason it's important to provide these code snippets is to show it what success looks like, right? Yep.

>> If this was like >> just instructions to create blank files, it wouldn't know what to create. So, in

our case, we're just showing it an example of of success. And we could probably simplify this. It's actually

quite a long command, but but here we go. So it created this and a blank piece

go. So it created this and a blank piece of text. That's great.

of text. That's great.

So that's just one way to start. You

just type /create a prototype and then and then that'll create. But maybe we have some design in Figma and we want to build this.

This might not work, but let's try it.

Um, so we can connect to the Figma MCP and I can just copy a link to this frame and say like let's build this uh this notion UI.

So uh before you could just paste uh a link to a Figma URL and try and manually invoke the Figma MCP and it would sometimes ask clarifying questions and

sometimes it would build it and then sort of stop halfway through. I don't

like any of that. So, we actually built a command called /figma and it roughly does a couple of things. The first is it actually checks that you have the MCP

server installed and running. You know,

for people on the team who have never done MCP stuff before, they might not know how to do this. And so, it detects if you have it installed and if it doesn't if if it finds that it's not

installed, it'll just teach you how to do it. So, it actually returns

do it. So, it actually returns instructions to the user on how to set all this stuff up. And then it moves on to phase A designing uh or extracting the design from Figma. Then it'll

implement it. And then the most important thing is we enter this third phase called the verification loop where it's going to open the browser and compare the implementation it created to

the original Figma file. And I think my instructions are basically keep looping until you've gone through like two loops where there were no more changes. Oh

yeah, here. repeat until the implementation matches or after three iterations with no changes and then stop iterating. So, let's just see what

iterating. So, let's just see what happens. This I would say it gets like

happens. This I would say it gets like 80% correct 80% of the time, but that's just that's just how AI is right now.

>> I was going to say about 60%. So, I

think I was right. Well, actually, you know, I think it is 60%, but this this command and this loop and these instructions and like the pairing of the two MCPS actually gets us to 80%.

>> I want to call call this out for folks because one of the things that I find most frustrating using MCPS even as a fairly sophisticated user is one, you just have to use these like magic

keywords to invoke the MCP and the right tool and the right thing. And you know sometimes I have one of the challenges I have is I have a lot of MCPs that use the same tool names um because so much

across SAS is named the same like everybody has the concept of projects everybody has the concepts of pages or documents and so I like this idea of like force invoking a specific MCP via a

slash command and not even just force invoking that specific MCP but force invoking a specific set of tools in that MCP. super super useful. And then I will

MCP. super super useful. And then I will give you props for the instructions at the top that teach somebody if you have no idea what you're doing here, how

to even get this thing installed. That's

such a nice piece to add in as user experience for a consumer of this um slash command that might not be you. Um

and so that's something that people should really really think about.

>> Yeah. Yeah. Um, I would say also it's funny because I I've actually watched a bunch of these videos and looking even back at the ones from 6 months ago, it's crazy how far the tooling has come. And

so I imagine that people who for whatever reason might be watching this video in 6 months will look at what we're doing here and be like, "Oh, how naive, you know, we've come so far MCP is no longer a thing." Or something like

that, right? And I kind of feel that way

that, right? And I kind of feel that way now where MCP is it's like not the best thing, but it's

the best we have so far, right? Like

it's very context inefficient. Sometimes

it runs forever. Sometimes it Yeah, it just like blows up your context window, but it's the best we have right now. So

even just watching this, right? Like

here's our design that got built. This

was literally just pasting the link to the Figma file. No other custom instructions. And now over here on the

instructions. And now over here on the right, it should be uh I think I ran into an issue earlier. Yeah, the

something got busted with this. Let's

try the Chrome Dev Tools MCP again. I think I quit it midway through because it was detecting some conflict with the window. But

anyways, this is pretty good by default.

And then from here, I would iterate. You

know, some things things you might notice would be like there's no hover states, some of these images are broken, but those are just some easy follow-up tasks. Well, and you're doing this from

tasks. Well, and you're doing this from a kind of design perspective, but think about how many engineers sit there and like pixel pull over Figma prototypes

into the front end. And you know, if you have a great design system, maybe that's easier to do, but it's not what the 27 seconds that we just watched

>> to scaffold stuff out. And so I just think you know the friction reduction in these um you know assetto asset handoffs which for my entire career 20 plus years

in tech have been the most expensive part of implementing something where a designer gives you a design and then you have to get into the front end or the front end has to be hooked up to the

back end. all those little pieces can be

back end. all those little pieces can be smoothed out and done much faster. And

then you can spend the time on the optimizations, the performance, the how it feels, how it how it works. And I

think that's just really it's really fun from a builder perspective.

>> Totally. It's so fun. And yeah, I mean, even just sitting here watching this, I still just find this magical, right?

Like now that it's using the the Chrome Dev Tools MCP, it like looped and fixed the broken images and like created this checklist of stuff like, okay, everything appears to be right. It's got

this bottom bar. These things are obviously wrong, but we could go and fix those with the follow-up prompt. But

again, the goal is like, can we get 80% in literally one prompt? I just pasted a link and it just iterated itself towards something that's roughly complete.

>> I know. And every time somebody is like a little anti- AI assisted coding, I'm like, do you know that I used to have to walk uphill both ways for my CSS? Like

it was not fun to do this.

>> Like [laughter] I I find this just mesmerizing. This is

so >> mesmerizing.

This is great. This episode is brought to you by Orcus, the company behind Open-source Conductor, the platform powering complex workflows and process orchestration for modern enterprise apps

and agentic workflows. Legacy business

process automation tools are breaking down. Siloed low code platforms,

down. Siloed low code platforms, outdated process management systems, and disconnected [music] API management tools weren't built for today's event-driven AI powered

cloudnative world. [music] Orcus changes

cloudnative world. [music] Orcus changes that. With Orcus Conductor, you get a

that. With Orcus Conductor, you get a modern orchestration layer that scales with high reliability, supports both visual and code first development, [music] and brings human AI and systems

together in real time. It's not just about [music] tasks. It's about

orchestrating everything. APIs,

microservices, data pipelines, human in the loop actions, and even [music] autonomous agents. So build, test, and

autonomous agents. So build, test, and debug complex workflows with ease. add

human approvals, automate back-end processes, and orchestrate agentic [music] workflows at enterprise scale.

All while maintaining enterprisegrade security, [music] compliance, and observability.

Whether you're modernizing legacy systems or scaling nextgen AIdriven apps, Orcus helps you go from idea to production [music]

fast. Orcus, orchestrate the future of

fast. Orcus, orchestrate the future of work. Learn more and start building at

work. Learn more and start building at orcus.io.

orcus.io.

That's o r kes.io. [music]

Are there any other uh commands that you think are super useful?

>> Yeah. Yeah, I can show you a couple. Um,

so I want to scroll back up a little ways actually. There was this step very

ways actually. There was this step very early on where you can see it was running over and over again this skill called uh bunr run claude skills find icon. What's

that? Well, if you look over here in our design, we actually have a bunch of very notion specific icons, right? Like we

have this AI face, we've got home, inbox. Uh, we have all of the icons in

inbox. Uh, we have all of the icons in our project. The problem is AI is really

our project. The problem is AI is really bad at estimating what the name of an icon should be. Or rather, it uses like the most obvious name possible, which

doesn't always match what's in code. For

example, like this face icon, there's no way AI would know what we call this. Or a very common one is it

call this. Or a very common one is it will if you have like a search magnifying glass, right? It will just assume that it's called search icon when

in fact in our code it's called magnifying glass icon. And so this icon hallucination was getting really really annoying. So, I wrote a little skill

annoying. So, I wrote a little skill called find icon. And the skill basically says look, anytime you're going to implement an icon, first go and

actually look through the whole project, but also look for uh synonyms or or closely related words to the icon. So,

if you're going to look up something called search icon, also try search for magnifying glass icon. And it actually wrote a TypeScript script to do this to

just iterate through all of the the files in our icons directory, which is like 5,000, right? It's a lot. So, it'

actually be very inefficient for it to try and load all of that up into context. It needs to write itself a

context. It needs to write itself a script to do more effective searching.

So, in that that loop here, um yeah, you can see it like found it looked up magnifying and found the magnifying glass icon. and it looked up inbox and

glass icon. and it looked up inbox and it looked up gear and trash in order to get all of these things correctly. Now,

this only this skill had to exist after all of us on the team just got really really frustrated with it hallucinating over and over and over again. Um, it's

sad because it obviously missed these bottom three. It didn't get them

bottom three. It didn't get them correct. Uh, but the fact that it got

correct. Uh, but the fact that it got these on on the first pass is a huge step up. So the way I think about it is

step up. So the way I think about it is you know we have these commands that you run manually and skills are these capabilities that uh the AI should

detect automatically and sort of use at the appropriate time and it'll know to do that based on the description and title you've given it. So in this case find icon and then how to search for

icons. And of course the best part is

icons. And of course the best part is just letting it do things programmatically on your computer by calling actual uh coded scripts. So,

this was really helpful. Saves us a lot of time and just fixing imports and nope, search icon does not exist. Those

kinds of annoying annoying steps.

>> Well, what I like about this uh is one, this is exactly what you would do to like a junior designer or engineer onboarding, you would like explain you'd be like sometimes we call it search, but

not really. It's magnifying glass. You

not really. It's magnifying glass. You

just got to go find like the closest >> synonym. And the ability to be able to

>> synonym. And the ability to be able to describe that to an agent or a skill or a tool and then let it do it programmatically for you is really useful. Um, we do have a how I how I AI

useful. Um, we do have a how I how I AI episode on Claude skills, but one piece we don't go into in detail, which I think is really important is Claude skills can be bundled with scripts. And

so the ability to combine both um, you know, natural language prompting, which is in the skill.mmarkdown, with a set of programmatic tools in terms of scripts

is a very powerful combination. And

Claude's very good at making these. So,

>> oh yeah, like all this like I did not type a single line of code in this, right? Like this is 100% like, hey, I

right? Like this is 100% like, hey, I just need this problem to be solved.

Create a skill for it. And in creating that skill, also create a script so that you can work more effectively. Like this

is 100% prompted.

>> Show us your your last command because I think this is a really useful one.

>> Okay, this is fairly new. I think I emerged this last week. Going back to sort of the problem with prototype playground, it's still a Nex.js app.

It's still React and TypeScript and Git and branches and it's just a lot of concepts to throw at someone who maybe is used to only prototyping in Figma or

they're intimidated by a terminal or code. And so I'm trying to figure out

code. And so I'm trying to figure out like how do we make this thing more approachable? How do we make it easier

approachable? How do we make it easier to onboard but also not dumbed down, right? Like

right? Like I want people to learn how to use computers. I want people to even

computers. I want people to even subconsciously absorb the ideas of git and branching and pull requests and merging. So I don't know the best way to

merging. So I don't know the best way to do that but my first attempt is to create this skill called or this command called deploy.

And deploy does basically two things.

The first is it like goes through prerequisites and makes sure that it has the GitHub CLI tool installed on your computer and that you're authenticated.

And if you're not, it like walks you through those steps how to do it. And

then the second step is it will just walk you through step by step how to get this prototype you've just created deployed so that you can share the link

with someone on your team. Uh let's see what happens. I'm going to try it now.

what happens. I'm going to try it now.

I'm going to hit deploy and we'll see what happens. Um

what happens. Um there's a couple of really cool loops in here that I think save people a lot of time. So, we can see it going through

time. So, we can see it going through the prerequisite steps here. It's making

sure I'm logged into GitHub.

Now, the first thing here, look, it's looking to see if I'm on a Git branch.

It notices I'm not. I'm on main, and it shouldn't be doing that, right? Like, we

never want to push to main. So, I think what it should do is help me create a new branch. Um,

new branch. Um, and we'll see if it actually does it correctly. It's also trying to find some

correctly. It's also trying to find some TypeScript errors and it's going to run some tests. I basically told it to do

some tests. I basically told it to do all this stuff because it's really annoying if you push code to GitHub, wait for all the checks there to pass.

If they fail, then you got to come back to your computer, fix stuff.

>> Okay, great. So, it created a branch.

>> Now, it's staging our changes.

>> Nice branch name.

>> It's perfect.

Creating the commit.

>> I'll give I love this. This is a great idea. I will also give my just like hack

idea. I will also give my just like hack to learning git for anybody who hasn't used it. I just love the git git github

used it. I just love the git git github desktop app. It just like it gives you

desktop app. It just like it gives you buttons for all of this. You can see your diffs. You can like create branches

your diffs. You can like create branches with buttons. So I think this is

with buttons. So I think this is awesome. And if you are intimidated by

awesome. And if you are intimidated by the command line, there's like literally a beautifully designed desktop app that you can use. True. It's pretty nice.

>> True.

>> Well, now check this out. So, it's

created the PR and in the instructions I've told Claude, hey, whenever you create the PR, open it in the user's default browser. So, now we have

default browser. So, now we have >> our our PR opened here. And uh this check to deploy it to Verscell will fail, but that's okay because I give it

one more step here. And all this red looks scary, but it's not. I tell Claude to just monitor the CI every 30 seconds or every 60 seconds until all of the

checks pass and I tell them the the specific checks that I care about. And

if any of the checks fail, just fix yourself and then push the changes. So,

you know, if people push something to GitHub and there's a TypeScript error, they'll see some error over here in the GitHub UI. They'll take a screenshot.

GitHub UI. They'll take a screenshot.

they'll send it to me on Slack and be like, "Why is my thing not working?" I

want to just avoid that entirely.

And you know, going all the way back to my first principles, like if the AI is asking you to do something like check the PR or tell me the CI status, you

should really be thinking about how do I teach claude to just do that for itself.

So over here, this slash deploy command literally is just end to end. I just sit back and watch it loop over and over and over again, checking its its commit

status, its CI status, making sure everything works. And then when all of

everything works. And then when all of the check marks over here are green, the script will stop.

I think this is pretty awesome. I I feel uh I hope it lowers the barrier and like the intimidation factor of having to learn all these tools, but at the same time, you know, if you are curious, you

can just sort of read along and understand what's happening. It's like

instructed to communicate in clear English what it's doing.

>> My favorite part of this, and it's not going to be what people think. I think

the slash command is amazing. I think

running through all the um pre-pro. I

love that you just open it up in a browser window. It's one of those things

browser window. It's one of those things that, you know, even if you created the branch, created the pull request, said it was ready to go, people are like, "Okay, well now now what do I like now

what do I do?" And just forcing open the browser window and saying like, "This is where it lives on GitHub." My question is, >> do you have to get your code reviewed in

prototype playground or do you just >> uh for prototype playground? No. I mean,

people can always ask for it, but no, we pretty much just yolo merge. I think the thing that I mostly check for is like, did my PR accidentally mess up someone else's prototype?

>> Yeah.

>> But again, like that happened a couple of times and that was annoying. So then

we created this clawed local file that's like important, do not do this, you know, and that seems to have have fixed the the problem. So yeah, a lot of uh

yolo enable automerge. And of course, it's not perfect. I don't know. It's it

seems to be hallucinating some stuff here. Like it thinks it thinks these

here. Like it thinks it thinks these passed even though they haven't. I don't

know. It It's close.

>> So I'm just going to zoom out everything that we went over. You created a shared repo for your entire team where you could have name level directories. No

database. We're just using metadata JSON and and and um shared code to put different prototypes inside this repo.

You set it up with both global cla rules as well as local claude rules plus cloud commands and claude skills to sort of

guide people along common paths. My

favorite one is going to be Figma to code.

>> It's so cool.

>> Beautiful. It's so good. And then the number one rule that I've heard from you today is when asked to do something by Claude, teach Claude to do it. It's

itself.

>> Yeah.

>> So, you have this amazing prototype um playground. You've set all this stuff

playground. You've set all this stuff up. How has let's just do a couple

up. How has let's just do a couple lightning round questions and get you on your way. And my first one is how is

your way. And my first one is how is this shift from doing things, you know, maybe exclusively in Figma or in these lower fidelity prototype models to

really leaning on things like cloud code, codebased prototyping? How has

that changed the design team? Has it

changed a small part of the design team?

Do you feel like overall things in the organization are shifting in in a way?

How do you feel like it's changing the way people work together? I still use Figma. Um, I probably still spend 60 to

Figma. Um, I probably still spend 60 to 70% of my time in Figma. You know,

there's just certain things that you're making that don't need to be in the browser. They don't need to be coded up.

browser. They don't need to be coded up.

You can just look at it and be like, "Yeah, that's roughly right. We should

just ship that."

I find that as you're designing for things that use AI, that is not true, though. So for

example, if you are building a chatbot or in my case, I work on notion AI,

I don't think you can design a good chat experience in Figma. You can design what the chat input looks like. You could

design a little chat bubble and a send button and like a drop down for model picker. I think all that's fine in

picker. I think all that's fine in Figma, but what you can't design in Figma is what it actually will feel like to use that thing. I probably should have said this at the very beginning,

but the reason prototype playground existed is because when I started working on notion AI, I was literally designing conversations in Figma. you

know, is like the user's going to say this and then the AI is going to say this and then it's going to work perfectly and create a page or a database and like you mock these golden

paths in >> Figma and then the engineers go and they build it and then it just doesn't work that way, right? It you send a message, the AI gets stuck or it asks a follow-up

question or it does the wrong thing and you need to correct it. And prototype

playground was for me a way to connect to real AI models and just start feeling out like okay how are the models going to work if I submit this kind of prompt what happens if I connect it to the notion MCP doesn't even know how to

create a page what happens if it runs into an error oh right we need to design an error state for this what happens if the model is thinking for two minutes and the user staring at an empty chat

screen like what should we do in that intermediary time to help them feel confident that it's working that it's doing the thing. Is there any way to show incremental progress? Like I just

found those things very very hard to design in Figma. So to go all the way back to answering your question, I think as more and more people are designing

apps that both are for AI or incorporate AI in some way, they're going to need some other like native code first way of

working to actually understand what the models can do. It feels honestly kind of bad. It feels like a lot of wasted time

bad. It feels like a lot of wasted time where every month the whole freaking industry has to learn like oh what are the new capabilities of this model 4.3.2

Max Pro and then a month later it's all irrelevant because the new thing has come out and then you learn that. Um it

feels like a waste of time.

Unfortunately, I think it's necessary because the model capabilities are still advancing quite steadily with each release. And it's really important as

release. And it's really important as designers to understand what models are capable of doing so that we can create product experiences and designs that sort of live right at the edge of what

the model's going to be able to do.

Well, what's really frustrating is if you design something that's like, you know, oh, a user is just going to ask for a cool website and it's going to be

this perfect output website on the other side. Models can't do it right or or

side. Models can't do it right or or they require a bunch of fine-tuning and and sort of like intermediary prompting to get that right. Designers just have to know what's going on under the hood

there to to design something that's plausible and possible. So I I suppose the more products incorporate AI, the

more designers will have to shift to thinking sort of prototype first, but probably prototype first with actual code under the hood where you can incorporate modern models and see where

they break and see where they're good and see where they're bad and actually form an opinion about which models are good for which things. Uh that kind of stuff. So, speaking of which models are

stuff. So, speaking of which models are good for which things, and you're using my my current fave, my babe Opus 45.

>> Why? Why CL? I mean, why Claude code?

Why cursor in this non-cursory configuration? Tell me how you arrived

configuration? Tell me how you arrived at this is your your tool stack.

>> I need to play with more of the cursor stuff. I actually think cursor agent

stuff. I actually think cursor agent mode is pretty awesome. I've like

clearly tried it a little bit. I just

haven't gotten that that far. The thing

that I still really appreciate about cursor I actually technically use both like if I have I don't know like some file and there's there's like some error here. I still

really appreciate being able to just hover over the error and there's a button that says fix in chat.

>> Y >> that's still faster than like copying and pasting it down into cloud code. So

I actually use both a little bit. I just

think cloud code does the best work. I

don't know how else to describe it.

There's this weird feeling as you use all the different models for different things. It's like to different people,

things. It's like to different people, they just feel right. For me, Opus 45 is just insanely good at doing what I want.

And I like the way it approaches problems. I like the way it plans. I

like the way it executes. I like the way it communicates back to me and the the follow-up questions it asks. And then,

you know, why not use Opus 4.5 in cursor versus in the the terminal UI? I don't

know. I think this is just purely personal preference. Like, some people

personal preference. Like, some people look at this and they're like, "This looks like shit." Like, give me buttons and UI and components and and drop downs and things like that. And for me, I don't know. This just feels nice and

don't know. This just feels nice and easy.

>> It just feels good. As our friends over at every say, each model has a mouth feel. [laughter]

feel. [laughter] >> Yeah. Yeah. Exactly. and Claude Code and

>> Yeah. Yeah. Exactly. and Claude Code and Opus have a good one. Okay. And then my very last question because you are you seem like a uh expert prompter

>> but when AI is not listening when it's not listening when it makes up you know CI checks that passed where it didn't it didn't actually pass what is your prompting technique?

>> Basically I notice there's a direct correlation with how good of things I can make and how tired I am. And if I ever get to the point where, man, Claude

just sucks. It's doing the wrong stuff

just sucks. It's doing the wrong stuff and I go back and I reread the thing that I said, I realize I made no sense.

And so the best solution for me to write better prompts is like go to bed, try again tomorrow. Um, which

again tomorrow. Um, which [laughter] I don't know if that's a copout answer. It's not actually writing

copout answer. It's not actually writing better prompts, but uh you know, your your output's just directly correlated with how good of context do you give the thing. And if you're giving it sleepy,

thing. And if you're giving it sleepy, tired, lazy, please fix this type uh commands, it's going to do bad work.

>> I don't know if this is what you intended, but you gave me very good both relationship and parenting ad advice there, which I'm thinking about. I was

trying to ask my kid this morning to do something. I'm pretty tired, and I

something. I'm pretty tired, and I clearly the inputs were not going to get get the outputs that I wanted.

>> Well, it's easy. I mean, just go take a nap. Can't you do that at any point that

nap. Can't you do that at any point that you need?

>> I love that. You know, one of my my one of my favorite little agents, Devon, does have a sleep. You you can send the agent to sleep, baby. We just need we need the agents to send us to sleep.

Well, Brian, this has been >> awesome. Just a deep dive, I think, in a

>> awesome. Just a deep dive, I think, in a very forward-looking view into how design teams, as you say, especially ones that are going to be building AI products, are going to start doing their

work. So, where can we find you and how

work. So, where can we find you and how can we be helpful to you in Notion? Uh

you can find me I'm mostly on Twitter or X uh Brian_1 or my website brianloven.com.

brianloven.com.

And then I work on notion AI and I think it's genuinely uh one of the few useful sort of knowledge work agents. So if you haven't tried it, try it and send me

feedback. We're always trying to make it

feedback. We're always trying to make it better, help it do more things better, faster. So try Notion AI. Yeah. And

faster. So try Notion AI. Yeah. And

we're big fans of Notion AI too here at the podcast. So definitely give it a

the podcast. So definitely give it a look and definitely give some feedback and we will send it directly to Cla Claude and put it in prototype playground. Brian, thank you for joining

playground. Brian, thank you for joining How I AI.

>> Thank you for having me.

>> Thanks so much [music] for watching. If

you enjoyed this show, please like and subscribe here on YouTube or even better, leave us a comment with your thoughts. You can also find this podcast

thoughts. You can also find this podcast on Apple Podcasts, Spotify, or your favorite podcast app. Please consider

leaving us a rating and review which will help others find the show. You can

see all our episodes and learn more about the show at howiiaipod.com.

See you next time.