274 | Stop Building AI Demos: How to Build Production-Grade AI Solutions with Joanna Stoffregen

26:28Here is cursor.

26:34So I have been using cursor for, I would say now, a year or so. And I still actually prefer it. I mean, I use the cloud models and cloud code inside cursor, to be honest. But I still prefer it because I do a lot of front-end work. And I would say for front-end, it also has this kind of select elements that I can actually also change things like this. So I favor it for now for UI. But yeah, so now, how did I end?

27:11Joanna Stoffregen:Before we dive in, are you going to explain what cursor is or do you want me to do that? No, I mean, I did not have the intention, but feel free to explain it here. Yeah, so two cents about what is cursor. So developers write code inside a development environment. It's called an IDE. There were multiple IDEs before the AI space. This is how developers write and manage and share their code. However, in the recent two years and definitely in the last year, there's been a really hard push towards vibe coding inside of a developer environment, making it accessible to anyone. So while it sounds really scary and complicated and there's like all these menus and so on, literally all it is, again, it's just a user interface for you to be able to write code.

28:01Joanna Stoffregen:And I use Cursor and I use Replit and I used to use some others. The two I use the most right now are Replit and Cursor. And you don't need to know anything. Literally, you need to install it. So install Replit or Cursor. And then you click on Create New Project. And you're up and running. So nothing to be scared about. And in this particular case, all Joanna did is bring her code components. And I'm sure she'll show us in a second. She brought the user interface components that she didn't generate, Figma generated, into Cursor. So now cursor has access to how the user interface is supposed to look like.

28:38Yeah, and actually you will have a chat interface there. You could actually chat as you would chat with any, with chat GPT, cloud, doesn't matter. And then you just have your here, your files and the code and everything. So how did I go from Figma to this? So this, I did not, as I mentioned, we could have essentially saved our Figma make code into GitHub and actually open it here. But as I mentioned, we might code with a different essentially framework that we cannot use basically what Figma make provide us. So my here, like what I'm going to show you is actually how to rebuild what you have in Figma inside an AI coding agent to be production ready for, you know, giving it afterwards to your backend engineer to put the business logic, the backend and so on.

29:43So first, how do we start? So we actually need this. We need a folder with this essentially documents here. So first, the PRD. What is a PRD? Let me give a preview mode. PRD stands for Product Requirements Document. And if we go back to our UI screens, what we want to achieve with the Product Requirements Documents is that essentially all the context that we have about our UI, about what it does, what screens it contains, what is the problem that the product solves. All of that, we actually need to give the same context to the AI agent so it can understand what we are building and so on, so it can build it.

30:39So let me show you what is included in the product requirements document. So overview, what is the product that we are building? Who are the target users? What are the core features? You could add what is out of the scope of volume one. Very important to add the tech stack. So basically, I am building the UI with this Next.js framework. I will use Radix UI. So basically, what is Radix UI? It's the component library. It's a headless component library. So basically like a library that will enable us to style afterwards a component with our design tokens and with our styling from the design system, right?

31:25And I also told it that we need to install Storybook. So this is the tool to document the components that we will look into it in a minute. And the screen specs. So what screens are included in the software? You will see actually here design system, but this is added actually after we generate the design system here. I just updated it afterwards. But the most important thing to add is to be very simple. Like what is the product about? What are the core features, the tech stack that you will build with, and the screen specs. And I have actually the screens for like three of these screens here, as well as the separate files.

32:10So I want to add one more thing about PRDs and requirement documents.

32:16Joanna Stoffregen:I said before that I think the limiting factors today is good ideas, prioritization and requirement definitions. i one of the first things that i built with like multiple agent orchestration solution is a solution that interviews me for 30 to 45 minutes with multiple questions across multiple aspects and then it writes a 30 to 50 page prd so i don't have to do the heavy lifting i don't actually have to need to know everything but it's just going to ask me questions like who's the target audience what are they supposed to do with it uh is there another audience that is going to use it? Is it just you?

32:53Joanna Stoffregen:Are you going to distribute it to other people? Is it people in your company? Does it need to go outside? What tech stack do you have now? All the stuff I don't know, it will go and research. So if it asks me, okay, do you want to write this in this platform and that platform? Like, I don't know. Then there's another agent that does online research and will come back with recommendations. But he writes without me having to do anything other than being the subject matter expert, it's going to ask me questions and I will answer. He writes 30 to 50 pages document of requirements across everything it needs to know, including user interface, backend, what it needs to perform, blah, blah, blah, blah, blah.

33:28Joanna Stoffregen:And then I can allow AI to plan the project and plan the execution and define the components and so on, because the requirement document is that detailed. And again, I don't know how to write these documents. When I used to run software companies, I had people like Joanna, like product people who would figure it out. But now you don't have to. Like AI knows how to create incredible requirements documents that are extremely detailed. By the way, what I'm doing afterwards is every time I have a new idea, I tell the AI to go and update the PRD. So now I have PRD, you know, 3.7 as far as the version, because it keeps on updating it every time I have new ideas or things that I want to evolve.

34:07Joanna Stoffregen:But that's kind of like piggybacking on this idea of requirements documents are very, very important. yeah and totally you can do it with ai actually i also do it with ai don't write it on myself um but not 30 50 pages though yeah so yeah um where where we are left so we have also the links to the screen specs individual screen specs that our ui will have and i will show you these the screen specs pages Are these the code from Figma or is this just screenshots? No, no, no, no, no. This is just the specs. So here's essentially. Oh, got it, got it, got it. Yeah, yeah. So basically if we go here, the screen spec about the dashboard will be what are the user flows, you know, mainly like stories, like user stories.

35:01As a user, when I go into the dashboard, I actually want to see my people's growth rate, whatever, or all the flows that you're able actually to do in the specific screen. So let me actually show you.

35:18Joanna Stoffregen:And who writes the user stories? Who writes it?

35:24Like usually the product manager. No, no, no.

35:26Joanna Stoffregen:But in this particular case, like, are you having AI do this or like a person writes the user stories? I mean, when we when I when we work, for instance, with with a project, we we need to kind of define what it's what goes in each screen. right? So I know for instance that for instance in this screen that this screen should contain a dashboard like a table sorry of all the people that are working you know like in this company these are should be the columns what each column are so on. So once we get that kind of like specifications from the client, then we are able to either... Actually, sometimes they provided themselves, but sometimes the specs could be just very vague, as I said to you, just like, hey, I want a dashboard, a table here, what we need to do, and then we can just...

36:28Got it. Yeah. So yeah, so here are the specs for each of these pages. what is the purpose of this dashboard, so what I'm able to do in this dashboard, right? What are all the user flows and so on? What data is displayed? So again, you need the data, right? Like what is the content or, yeah, let's say, what will be included there, the components needed, different states, and you could also have some edge cases, right? So these are essentially, when you open Cursor or your AI coding agent, these are the main documents that you need to start, the PRD and the specs for each screen. So once you have that, the next step is actually to open your chat here, reference the PRD and tell it, please read the PRD and plan and install all dependencies for this project, right?

37:35And I always, always select plan mode. So when I do that, the agent will actually read the PRD. It understands what my product is. It understands what tech stack and everything to include. So it can actually install all the technologies or the dependencies, all the libraries that we would need to actually start developing the product. Then afterwards, once you actually have it planned, you will build it and will start installing all your dependencies. You will end up with something like this. And then you're actually ready to start. So at this point, what we do next, we actually need to extract the design tokens from our design system, right?

38:31So how you do that, I have actually a prompt. So what I do, I copy that, that screen here. Where is it? Copy. Copy link to selection. And I go back to cursor. By the way, for this to work, you need to have the Figma MCP installed. And I use this. Pause for a second.

38:56Joanna Stoffregen:Again, for those of you who don't understand what that means. So we're using, let me do a quick recap, right? We started with getting inspiration from other websites and potentially our internal tools. Brought it into Figma. Had Figma help us define, A, how the screens are going to look like, but B, develop a language. This is going to be the design language you're going to use across the different things. Then we want to create the actual code to make the software work. We do that in a tool called Cursor or any other IDE. We're bringing the requirements documents. We're bringing in the information from the design, from Figma, into that document, into the development environment, in this case, cursor.

39:41Joanna Stoffregen:How do we do this? Well, you can do this manually by copying and pasting documents. You can do this by allowing both software to use the same place it saves. So as Joanna said, you can do this in GitHub. You can do this with local folders. You can do this in a mix of two. or today there's a concept of an mcp what is an mcp an mcp allows any ai tool to access any software that has an mcp without any heavy lifting which basically means you can connect figma and cursor without knowing how to write apis and connectors and so on it just works because the tool both tools have an MCP back and forth. So the two software knows how to talk to one another, and you don't really need to know more than that on how it works.

40:31Yeah. So it essentially lets Figma communicate with your AI agent and back and forth. So what we need to do at this point is to extract from our design system, the design tokens, right? So we mentioned before that design tokens are essentially variables that translate our design styles into variables. So without design tokens, imagine when you would just screenshot that and give it to the AI coding agent without actually having proper variables, proper design tokens. In code, it will actually hard code that this is, for instance, like a black button. This is, for instance, what color is this? A green badge, right?

41:28With design tokens, with the variables, we will know that actually our primary button is black. Our secondary button looks like this. This is how our input field looks, right? So tomorrow, when, for instance, you would want to change this button, the primary button, to blue, let's say, you don't have to go into 50 different files to find where we hardcoded the black color to actually change it with blue. And in code, it will look something like this. So this is without tokens, right? We have, for instance, the color, the hard-coded color, that it might be repeated 50 times in your code. However, with tokens, you will just have that the black color is a primary color.

42:25So you know that the primary button is black. So you just need to actually change in one place what is my primary button now to blue. and it will change it everywhere. So how we do that to actually translate our Figma design system into design tokens, I have this prompt, read the PRD, then look at my Figma design system. Let me actually copy it here. So I will just show you exactly how I will do it.

43:00So read the PRD. Here I will just reference it again.

43:08To understand the project, then look at my Figma design system. So here I would just need to copy the design system.

43:22And because we have the Figma MCP installed, it will just go to Figma and just understand everything. and extract all design tokens and create the custom properties and so on and so forth. So this is when you actually just go and click plan. You will end up with, where are the design tokens? No.

43:48Here, the design tokens. It will look something like this. So now essentially, your AI coding agent is translated all of that design decisions here into code. So it can actually start, we can actually use that design systems, the design tokens to actually start building our product. So once we actually have that ready, now we are ready to start building our components. And how we do that, again, I don't suggest that you take the whole UI and just start building it. Because actually, we would need to build first the components so we can use those components to actually build afterwards our screens.

44:43So how I will do that, I will just take, let's say we will start building the button components. I will take this essentially, the button components here, or you can actually just directly take it from here and start opening another chat and actually start telling it to build the button component. What it will do that now, if you remember, we actually installed Storybook. So Storybook, when I will start building the components, it will start saving all the components that we build here. So this is kind of like the tool that you will have all the components isolated from the main code. So here, as you can see, I have the avatar component with all the states, everything, how it looks like.

45:45Like I have the badges, how all the badges are looking, all the banners, how the banners are looking. So here I can actually modify them and so on and so forth. I can even have the code here and everything. So it's essentially a very useful tool when you are working, I would say, on a bigger project that has a lot of components, a lot of dependencies, a lot of screens. that you need to use the components to keep it consistent. So I go through -

46:17Joanna Stoffregen:Yeah, I want to pause you just for one second because I think it is critical for people to understand. Can you ask AI to just vibe code the thing that you wanted to vibe code? The answer is yes, and it will create it and will be consistent. But let's say it's something that will need to have 30 other pages in the next year. And let's say you're not working alone, you're working with two other people that are going to be working in parallel in order to build those pages and those additional functionalities. what this is doing the infrastructure that joanna is showing you is what makes everything consistent afterwards so it's not the first kind of like oh just write this thing for me and have it work it's write this thing for me but i know i will need to add other pages and other functionalities and other capabilities in the future and instead of going and figuring it out afterwards this is building if you want it's the difference between trying to build a lego car versus trying to build the Legos first.

47:12Joanna Stoffregen:And what we're doing is we're building the Legos. So after that, we can use the Legos for whatever we want to build afterwards versus just building the car because I can build the car. But then if I want to add a trailer to the car, well, now I don't have the pieces. I don't have the way to do this. And it's not going to look the same and consistent like the car that I built. And so being able to build these components in a way that are centralized, consistent and well-documented allows you and other people who work on this thing to build it in a consistent way that will look and work exactly the same.

47:48Yes, exactly. So it's mainly about consistency and to have a central place to document everything so you can actually know, right, this is my primary button, this is secondary button, This is how it looks like. As you can see, all the components that we actually have, that we will use in our UI, everything is clearly documented here for everyone to use. This happens automatically because when you would install the dependencies and everything, when you start building the components as I showed you here, it will actually show it in Storybook automatically. You don't need to do anything. So once we actually have all the components built, now we are, before we go to build the screens, I actually have also a command that refactors each component.

48:46So command, like I would say, like a rule or like a prompt, I would say, that refactors the components. and afterwards the screen. Why we actually need that is essentially to enforce all our basically senior UI engineer best practices so everything can be consistent and everything is saved and essentially the code is clean to start building. So I have essentially this refactoring command that I use after I build each component. And I suggest you also to have in the middle like a refactoring steps that enforces essentially rules and best practices of how I would say a senior UI engineer will do to build like the components.

49:43So yeah, so once actually we have our components built, how we end up with this is very simple from this point because what we will need to do, we will just need to, again, And let's say now if we want to build our home screen, you will just copy the link from Figma. Go to your chat agent. And what I say, I say, sorry, read again the PRD and also the specs from the particular screen, so the dashboard. So if you remember in the dashboard, in the specs, we actually describe all the user flows, all the data that we need to include, all the components needed. So now, for instance, it will have an idea about what components to use from Storybook and it will build it.

50:48So if I click and also the spec. So if I basically now let's finish the prompt. So read the PRD and also the specs from the dashboard screen specs here. and build the page. So I usually always, as I said, click plan mode, Opus will create now a plan and you will end up with the screen built afterwards. That it looks pixel perfect because actually we made all the preparation we build in advance our components. So we can now with one prompt build like a pixel perfect pages afterwards. So yeah, this is essentially the system. What I do afterwards, again, once I have the screen builds, I use the screen refactoring prompt.

51:40That essentially is doing the same thing as the component refactoring prompt is essentially enforcing all our design styles. Components are correct. Nothing is hard-coded. So essentially how a senior UI engineer will code it without the AI, we want actually to enforce all of that with the refactoring prompt. So yeah, this is essentially my process. Now we have production-ready code UI that can be handed over to engineers, to backend engineers, to add the business logic, the backend, and all of that. And also in case now another engineer want to come along and build the rest of the screens, everything is essentially built, defined.

52:37So it's easy now just to go from Figma to actually code just with one prompt and with like, you know, as I showed you before with the Figma MCP.

52:49Joanna Stoffregen:Amazing. I want to add a few things. First of all, a quick recap of everything we talked about. So the idea here is how to go from an idea in your head to a functional working interface in code. And the steps were, first of all, to be able to get the style that you want. For that, we used inspiration, like other sources, other examples that we want to use. The second step was to create Figma design. What is Figma? It's a design tool. It always has been a design tool. But until AI, people, graphic designers would design the designs. And now AI can do it for you. And we can do it, as Joanna showed, with one line.

53:30Joanna Stoffregen:Copy this design, and then you have it. Using this, you can create the design language, basically the overall how everything is going to look like. And based on that, you can define every single component. What could be a component? A button is a component. A drop-down menu is a component. a field that you can put your name in is a component. Each and every one of these things is a component, and there's hundreds of them in a website. But then this is where it gets really cool. In order to have this consistent across the board, what Joanna did is she said, instead of just taking the design as a design, I will allow my coding platform, in this particular case, Cursor, or Claude inside of Cursor, to build each and every one of those components as a library.

54:18Joanna Stoffregen:So now any future thing that I built has these reusable Legos, these reusable components that any person that adds more pages can use to build exactly the same stuff that I or can build new things that will look and operate exactly like all the other things. So again, there's a very, very big difference between building a quick and dirty app that you want to build and you can just let the AI incursor go and say, build this for me. And it will. And it will actually work versus something that you want to scale and maintain over time. And then the process that we did here of thinking about it in a very structured, organized way will pay off tenfolds in the long run.

55:03Joanna Stoffregen:And as you've seen here, it's not such a crazy investment in time. Like we just literally took you through the entire process, including explaining everything that needs to happen in about 45 minutes. Meaning without explaining, you can probably do the whole process in 20 to 30 minutes. And now you have a repository of well-defined components that sit inside your development environment that can be shared with other people who are working on the process all in one place. When I talked about the requirements document, the ones that I build that are much longer, they also have the functional requirement and the business requirements built into them, which means now the agents can actually go ahead and start writing the backend and the process and everything, and not just the front end.

55:48Joanna Stoffregen:And it goes back to the same thing. The more granular you're going to be with defining your requirements and the flows and the building blocks and so on, the better off your software is going to be. Both things means it's going to run smoother, but it's also going to be easier to maintain and more scalable if more people need to work on it or you want to build more stuff on top of it afterwards. There was an interesting question in the chat earlier that I want to mention. So the question was, can I use an existing piece of application that I have and improve it or update it with a similar process?

56:27uh do you mean basically like really redesign how it looks like so if you have an existing

56:35Joanna Stoffregen:application that you own the code for so you have the code for it somebody developed it for you can you now go in and say oh i want to rebuild it because i want the user interface to now be mobile friendly and i want it to look more like uh 2026 versus 2005 when it was originally built and I want to add this and that functionality to it. Yeah, 100%. I mean, if you have the code in GitHub, you could open it in any AI coding agent and go through the same process and just rebuild it. Yeah. It's actually also very common, right? That you have already your product and then you might want to change the design, you might want to change the components.

57:20and so yeah totally possible it's very common yeah yeah and i and i've i've done this multiple

57:26Joanna Stoffregen:times like actually open something that i had before again all you need is the code like if you have access to the code you can do this by the way if you don't have access to the code and you're not trying to rebuild salesforce but you're trying to rebuild a specific application that works in your business and it's 15 years old and you don't have the code and you don't even have support for it anymore, you can do that as well. You can take the software, explain to it what it does, show it the user interface, explain what you want it to do differently, explain what other things you want in the user interface, have it write a requirements document, have it write the user interface, and then go through the process we just defined.

58:05Joanna Stoffregen:And you can rebuild the software from scratch, but to your needs. And I've done that as well. I'm actually doing a project like this right now that I'm very, very excited about, that is combining several different ideas and several different pieces of things that I had before into one unified solution that is just tailored to my needs. And I thought about it yesterday. Last night, I already have the requirements documents. Most likely by the end of today, I will have version one. Most likely by beginning of next week, it will be fully functional and running. And this is the world we live in. Anything you want to build that can help you in your day-to-day, you can build with zero knowledge.

58:44Joanna Stoffregen:And again, Joanna has been doing product management for 10 years. I've been running software companies for X number of years. None of us have actually done everything we just showed you. This wasn't a product manager scope. This is not a CEO of a software company scope. This is stuff that other people, professionals in this used to do. And now there's AI tools who know how to do this. They know how to do the design. They know how to break the components. They know how to save it in the right place. They know how to write the codes to make it work. You don't need to know any of that. It sounds, the reason we want to show you, the reason I like these kind of episodes is I show you that literally anyone can write, not just create new software.

59:27Joanna Stoffregen:Again, today it's easy. Like with one prompt, you can create a piece of software, but create a piece of software correctly, professionally, in a way that will be scalable and that will work well in a production environment for lots and lots of people. Joanna, this was fantastic. Thank you so, so much. If people want to learn from you, hire you, work with you, like these kind of things, what are the best ways to do that? Yes, sure. So basically, you can contact me here from my company, labspit.ai uh we have a form or whatever if you want to work with us or just add me on my linkedin let me see here uh i probably will have the link there but yeah i will put the link in the show notes yeah feel free to add me on linkedin and we can continue the conversation there but yeah that's that's all and i also have a youtube channel that actually just launched uh to relaunched, I would say two months ago.

1:00:29It's called AI Builder Space that I share actually all this kind of like interesting tutorials about how I build products. So yeah, feel free to also subscribe there. Yeah.

1:00:43Joanna Stoffregen:So people in the chat really love this and I did too. So thank you so much. Thank you all of you for joining us and being active in the chat and asking questions and do these kinds of things. Like this is the age of experimentation. And if you're going to allow yourself the time and the energy to experiment, you'll be able to do significantly more things. Now, the cool thing, this sounds like a lot of work, but actually it's not. And once you figure it out, you'll be able to build software that's going to save you time every single day and every single week in things that you're doing, you or other people in your company on the day to day.

1:01:21Joanna Stoffregen:That's it for today. Thank you so much. Thank you so much, Joanna. have an awesome day. Thank you everyone.