The ultimate guide to vibe coding | Google

Author: Grow with Google · Watch on YouTube

Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.

Original language: English

Original video: The ultimate guide to vibe coding | Google · Channel: Grow with Google · 23:47 · Watch on YouTube

Topics: Cybersecurity and software security, Software engineering with AI

Summary

The video presents a three-phase workflow for turning a vibe-coded prototype into a reliable tool: plan the app, test and debug it, then prepare it for secure sharing. The presenter uses AI Studio to gather requirements, refine a spec prompt with project documents, and build a prototype based on real project data. He then demonstrates iterative testing, using error logs and specific feedback to fix problems and enforce app rules. Finally, he grounds a dashboard in verified company data, catches inaccurate chat results, and configures a full-screen sharing experience for the intended audience.

Key points

Move beyond a single prompt by using a system: plan, test and debug, then deploy or share.
Use the AI as a thought partner to gather requirements, explore alternatives, and refine a concise build prompt.
Attach relevant source documents and project plans so the app reflects real constraints and information.
Review what the generated app actually built, then iterate on its interface and behavior.
Use debug panels, error messages, screenshots, and precise descriptions of problems to help identify failures.
Test edge cases and make the app automatically correct outputs that violate defined guidelines.
Add explicit control rules, such as requiring a call to action, and verify them with export checks.
Ground calculations and answers in approved company documents and current data rather than assumptions or test data.
Test the app with realistic questions before sharing, and configure access and presentation for the audience.

Chapters

Start	Chapter	Summary
00:00	The three-phase workflow	The presenter introduces a developer-minded process for planning, testing, and safely sharing vibe-coded apps.
01:02	Plan the app and build a prototype	He refines a project-management app idea with Gemini, adds context from project documents and a spreadsheet, and builds a working prototype.
09:34	Test and debug the storyboard app	The presenter iterates on a storyboard app, diagnoses errors, and adds automatic corrections and checks for required rules.
17:32	Ground the dashboard in verified data	He prepares a sales dashboard for sharing by applying financial standards, adding a welcome banner, and testing its analyst chat.
22:45	Share the app with the team	After confirming the dashboard gives an accurate answer, he configures a full-screen view and concludes with guidance to secure and deploy the app.

Quotes

If you can describe it, you can build it. — 00:00

First, we’ll map out a solid plan — 00:32

Investing time in a plan isn’t just a preliminary step. — 09:34

Intentionally testing your app’s limits is the ultimate way to prove your work is ready for the real world. — 17:01

You’ve got this. — 23:47

Concepts and entities

vibe coding, AI Studio, Gemini, Gemini 3.5 Flash, Gemini 3.1 Pro, Google Drive, Project Ripple, Gantt chart, CTA

Full transcript (original language)

00:00 If you can describe it, you can build it. That’s the magic of vibe coding. It’s the fastest way to turn an idea into an app, but as many builders know, magic can be unpredictable. I’m Ammaar and I lead product and design for AI studio here at Google. A single prompt is a great start, but vibes alone won’t stop an app from breaking when things get complex. To build tools that you and your team can actually depend on, you have to move beyond the one-shot prompt. You need a system. Today, I’m showing you the three-phase workflow the pros use.

00:32 These are the core skills that turn a cool demo into a reliable, secure, and shareable tool. It’s how you adopt a developer mindset. First, we’ll map out a solid plan, which gives us a baseline to lean on as we build out your idea. Then we’ll test and debug to ensure your app works reliably. Finally, we’ll deploy the app so others can use it in a safe and secure environment. I’ll be using AI studio for these demos, but these strategies work in any browser based AI tool.

01:02 Because AI tools change frequently, always double-check your platforms current features. Once you have your setup ready, you are set to build tools that simplify your work and save your team time. Being able to vibe code an app from scratch is a game changer. And it’s natural to want to jump right into development. Whether you’re building a personal app or an app to be shared with others, you still need to invest in solid planning to make sure it will actually work. I’m going to use AI Studio as a thought partner

01:33 to build a clear plan before creating any code. I’ll start by asking the AI questions to help me gather requirements. From there, we can refine those ideas into a customized project plan, also known as a spec doc. Then I’ll set up simple rules to keep the AI on track and prevent it from making things up. By the end, you’ll see how this workflow turns our plan into a reliable prototype. Let’s get started. For this demo, I’ll take on the role of a project manager.

02:05 On a typical project, I track dozens of tasks that depend on each other. Here’s a problem I run into: When one task is delayed, I can’t see how it affects the rest of the project or the launch date. So I want to build an app that shows how the tasks connect, and how one delay affects every step after it. Cool, so now we’re in the AI studio playground. This is the place where you can actually chat and experiment with all of the Gemini models. I’m going to use Gemini 3.5 flash to create a prompt for us.

02:38 I’m going to start by just describing my problem here. I want to build an app that takes a project plan and visually shows me how a delay in one task may affect the entire project and the final launch. Help me plan it out. So now when I hit run, Gemini is actually going to think through this problem and come up with a solution. It’s given us five phases, and I don’t really want the graph. I want something far simpler in order to see the projects.

03:11 So I’m going to say, I am not so sure about the graph representation of the project. Can we come up with simplified view? This might be way too much to give to one prompt. It’s effectively a large doc, and we don’t want to confuse the model with too many details either. So, I’m going to find a good middle ground here. And, so, I’m also going to follow up and say, I also want you to write this as a solid one paragraph prompt for a vibe coding tool to explain what to build,

03:44 capture all of the critical details in your prompt. And so what’s helpful here and why we’re doing this planning is because, if we hadn’t, you would have already seen it add a graph that it thought was a solution. But, maybe I wanted something else in my head. So what’s fun about this is, because I followed up with saying, I’m not so sure about the graph representation. It’s now coming up with a few other ideas. It’s saying, okay, maybe the complex web is too much. We could just view it as a hierarchical list or a spreadsheet.

04:16 This back and forth is effectively the partnership you’re going to build with Gemini as you go about building things. You’re going to go back and forth and get to a solution that you like, and it actually solves the problem you’re going after. I like the idea that it’s something much simpler, and it looks like it’s even created a one paragraph prompt for us for a vibe coding tool. So it’s saying it’s building a single app. It’s defined some technical details for us. And then you can see it’s also covered some of the UI we’re going to get. So it’s saying you want a simulate day slider.

04:48 That’s really interesting. A responsive Gantt, I like that as well. And then it seems to highlight the ripple effect in the timeline by showing things fading when a delay takes place. All of this sounds really cool to me. So, I’m going to take this now and go and build an app with it. So, we have a great prompt, but I want to make sure I’m not missing any details. So, now I can actually give Gemini some context and see if there’s other things I should be considering in this prompt for the app that I’m making.

05:20 So, notice the plus button here at the bottom. If I click that and hit Drive, I can then go to my folder of my project choose the Project Charter Doc. And now Gemini can use that as context to help us refine our prompt. So I can say, read the charter doc below, are there any other questions or things I should be considering when making this app we’ve been talking about?

05:50 So, now we’ll give it this context, and Gemini is going to look at all of that and tell us if there are other things that we should be considering. This is, again, another nice way to go back and forth with a model and build together. So, you can see it’s giving us a bunch of detail for what we should potentially consider. For instance, it’s noticed that App Store approval here takes seven to fourteen days. This isn’t active work done by the team, it’s a waiting period. Your app needs to support lag time and dependencies. So that’s another interesting idea that I hadn’t even thought of

06:23 that we could, now, incorporate in our app. Another one you’re noticing is it’s mentioning the budgets that it’s picked up from the charter, and that a daily cost rate with certain tasks could also be helpful to see in that view. So, these are all great ideas that the model has picked up and given us to work with. So, now I’m going to say incorporate all of those things you picked up on in that original prompt you gave me. So, incorporate all of these catches you’ve made in the original prompt. Cool. So, now we’ve got the final revised prompt.

06:54 So, let’s turn that into something we can build with. To do that, I just have to click the three dots. Click, make this an app. And now I’m going to be headed to Build mode and it’s copied our prompt. But notice it’s also copied all the other things it said before our prompt. And so this is something just to watch out for because what it’s doing is, it’s just porting over that chat into this build screen. But, you can just clean that up by going to the part where your actual prompt is deleting all the other stuff, and now you have just your prompt.

07:25 So this prompt effectively contains all the features we care about and the constraints, making it a pretty nicely summarized version of our spec doc. You had the requirements earlier and all of that outlined, and now you have something that an AI model can follow to build off of. Now I just need to attach one last thing, which is our actual project plan. So, if I go to Drive, and select the Google Sheet for our project it has the entire plan outlined there. And so now I can say,

07:56 I have also attached the Google Sheet of our project plan, make sure you base the app off of this. I usually like to say something like “make sure”, because the model can sometimes go in a direction where it’s using it more as a reference, rather than something that it’s actually following all the way through. So now, all I have to do is hit build. Ok. So, we’ve got the app built and you can see models love to brand things.

08:31 So it even called it Project Ripple. Now, there’s no place where I’ve called it Project Ripple. That’s okay. We can rebrand our app again later. But, you’ll see that it’s actually added all of the different phases and tasks based off of our Sheet. So, the market research to the UI/UX design phases which I believe are all mapping to our app perfectly. You’ll also notice that it’s added this delay slider that we talked about. The five day week as an option, and even budgets as a contingency.

09:02 So, if I mess around with any of these things, let’s say the delay slider you can see how it’s pushing out different tasks that depended on it. This is exactly what we wanted. And what’s awesome about this is this prototype is pretty personal to me. It’s personal to the Sheet that I gave it. It’s personal to the charter that I gave it, and it understood all these constraints to build something that I can actually use and share with the team. That gives us a working prototype built from a documented plan. Next, we’ll test it and fix what breaks.

09:34 Investing time in a plan isn’t just a preliminary step. It’s the strategy that transforms a one-shot prompt into a reliable tool. And, by defining the constraints early, you’ll move from passive prompting to leading the build. Now it’s your turn to start planning your first app build. I can’t wait to see what you create. It feels great when your app works on the first try, but that’s the easy part. The real work begins when things start to break,

10:05 and that’s when you learn how to troubleshoot. Today, you’ll learn troubleshooting strategies that improve your app’s performance. I’ll guide the AI to break the app down into smaller pieces to pinpoint the exact issues. Building in stages and checking the error messages is how you quickly solve problems. Okay. My prototype is ready. It’s an app that turns a video idea into a storyboard of what we see, what we hear, and how long each shot runs. and I’ll show you how to test it under pressure to find any hidden weak spots,

10:38 Knowing how to handle a setback is what turns a rough draft into a dependable app. Let’s get to it. So we’ve gotten our app, but it’s not quite the experience I wanted. I do have the three column layout, but I wanted this prompt box to be the first thing I see. And then we get to the column layout with the storyboard we wanted to visualized, filled out. So I’m going to go ahead and prompt that. I’ll say I want to change the app experience a little bit - instead of a single page view with everything,

11:13 first I want a prompt box to appear where I enter my storyboard idea and then it transitions to a new screen with the three column layout we have. And so I’m just going to go and send that to Gemini, and it’s going to make the updates to the UI that I requested. And this is part of the iteration flow when you’re making a prototype. Gemini interpreted it one way, trying to add its own flourishes

11:44 and potentially its own layouts, and we have an idea of something else. And so you just go back and forth with the model until you get to an experience that you were hoping for. Awesome, so looking at the output, Gemini understood that we wanted a nice home view. I love the way it added a nice prompt box here, and even asks for short form or long form when thinking about the video concept that we’re trying to visualize. So now let’s go ahead and test our app. I’m going to describe a short ad

12:14 for a new form of coffee. And I’m going to hit Generate Storyboard. Okay, so we ran our app and we ran into an error. But now we’re going to debug that together with Gemini to fix it and get to a working storyboard visualizer. So the first thing you’ll notice is that there are three red axes at the bottom of the screen. If I click that, I see a debug panel. This basically tells us where our app may be failing. It helps give Gemini context so that I can go ahead and fix our app.

12:45 So you can see here what it’s saying is it’s errors generating the storyboard, which is exactly what happened when we click the generate button. And you can see in the chat area it says three errors running the code. And there’s a fix button. So if we click that Gemini starts taking those error messages and working on making our app work. so looking at the error log, you can also see that the message of what’s going wrong is there amongst everything. So right here you can see that saying we exceeded our quota and potentially can’t use 3.1 Pro in this app anymore.

13:18 We could switch to a different model. But while Gemini works on the fix, let’s see what it comes up with. Awesome, so Gemini responded, realizing that it was about the quota that we called out. It also sees that we have been using 3.1 Pro, and is suggesting using a 3.5 flash It also found some other issues that it went on and fixed. So now let’s test our app again. So now I’m going to type a video concept and see a generate storyboard. Let’s create an ad. For a new form of coffee.

13:50 Okay, so I can see a storyboard generated. It’s got visual descriptions, audio dialogues, even the time and shot type, which is all super helpful. But what I’m noticing is that when I get to number three and four, it’s telling me what errors it’s finding in that description. So it’s saying here detail shot duration should be between 2 and 4 seconds and B-roll should be between 1 and 3. So it understood our guidelines. However, it’s making me do the work around building out this storyboard.

14:21 And I actually want the app to take care of that itself. So I’m going to prompt to make that change. I’m going to say when you generate a storyboard and it runs into any issues that don’t meet our guidelines, please fix them automatically and adjust each shot. I’m just going to give it a screenshot of what I mean by giving an example of what it’s doing already so it has the context and we’ll go and send that prompt.

14:53 Awesome, so we can see that Gemini responded with how it went about fixing this. So what it’s saying is, At first is going to make that request to generate storyboard. If for some reason it violates any of the rules that we gave it, it runs a loop again to fix that specific area so that everything works in our visual storyboard without us having to take care of it. So let’s do that again. I want to create an ad for a new form of coffee.

15:24 And now we can see the visual storyboard with everything, meeting all of the right constraints and no errors at all in our proposed ad. Cool, and I also noticed an export check button. So if I click that - Awesome, so it’s showing us that it took into account all the brand rules and they passed. Now we can proceed to export. And I want to add one final control instruction which is at the end of the storyboard. It should always end with a CTA. And maybe even we can add that as a rule that it tells us about.

15:55 So let’s make sure we go ahead and prompt that. I want to add a control instruction here, where every storyboard generated always ends with a CTA In the dialogue. Make sure to also highlight that in our export check. Okay, so it looks like Gemini updated the storyboard generation with the presence of a CTA always being in the final dialogue .

16:28 We can see it’s given strict model instructions and has even added that to our autocorrect loop. So let’s go ahead and ask for that. Again, I want to create an ad for a new form of coffee and hit submit. Awesome, so it generated our storyboard. And if we go back to the final piece of dialogue, we can see it has a CTA that says get started for free. When we go to the export check. It does say that all brand rules passed. But remember we asked that if the CTA was missing, it should tell us here.

17:01 So why don’t we go back to the editor and actually change this last line and say something like, coffee is amazing, and if we go back to the export check, awesome. It’s telling us there’s an error and there’s a missing approved CTA in the dialogue section. So we know our pre-flight check is working as intended. Intentionally testing your app’s limits is the ultimate way to prove your work is ready for the real world. You know how to work with the AI to isolate failures and track down

17:32 the root cause of any issue before it impacts your users. Now put your bill to the test. Don’t worry about the errors. That’s just the AI showing you how to make the app even stronger. I look forward to seeing you troubleshoot your way to a better build. Now that your app is working, you might be ready to take it to the next level, sharing it with others. I’ll show you how to connect your app to actual project files, so it always uses real verified information instead of making guesses.

18:02 We’ll also set up a friendly welcome message that doubles as a quiet policy reminder for handling internal data safely. Then we’ll walk through setting permissions, controlling exactly who has access using a phased rollout. By establishing these safeguards, anyone using your app can start getting reliable results on their own. Now that we’ve put the app under pressure and fixed any weak spots, my prototype is tested. It turns my sales spreadsheets into a summary

18:32 leadership can use with a chat panel for follow up questions. Now let’s get it ready to share with the team. So, I showed someone on the team this dashboard and they loved it, but it’s not quite ready to share with everyone just yet. So I need to make a few changes so that it’s ready to share with the team. So let’s go ahead and prompt that. First, I want to ground all of the metrics and calculations in our app to the financial standards that we have.

19:02 This is a doc I’m attaching, follow that for all calculations and internal rules, you must apply all of this to our dashboard. Second, I’m preparing to share this app with our executives, add a welcome banner explaining this dashboard and its features to help them get started. Then I’m going to choose the Financial Standards dock So I’m going to go to Google Drive and select that,

19:35 And add that as context to our prompt. And you can see how that’s all set up here. And then I’m just going to fire that off. And Gemini will take care of the rest. Okay, so it’s gotten back to me with what it did. It’s saying it resolved the calculations. It’s fixed and embedded the financial standards across all of the AI capabilities as well. And it’s grounded in our company’s data. Now let’s put our app to the test. So I’m going to upload our CSV again. And you can see here that it’s added a welcome banner.

20:07 So it’s walking people through this dashboard being one with top line metrics regional and product category breakdowns. And that we can review performance or ask for granular points in the chat. I’m just going to do one more quick walkthrough of the whole app to make sure it’s tested and ready to share. So, I’ll ask a question, which product category is driving the most revenue?

20:39 Okay, so our chat is clearly giving us incorrect information. There’s no electronics in the product categories. And that number 1234567… sounds like an amazing revenue number, but just not one that I’m seeing anywhere else. So, we can actually give this context again back to the model. I pasted the screenshot in because I wanted to give it that context. And now I’m going to say, the responses in the Analyst chat

21:11 are both near instant and don’t seem accurate. I mentioned the near instant because it seemed like Gemini was thinking earlier, and now it’s just responding with a pretty default prompt. So I’m wondering if it’s even sending the chat at all. And when you debug like this, it’s important to try to tell the model exactly what you’re experiencing, because then it can actually go ahead and think through how you might have arrived at this problem. And I’m so glad we tested this, because if I had shared this

21:44 with the executive team, they would have seen some magical numbers and a category that didn’t exist, and I would have had a lot more questions to answer for them. Okay, so we gave it that feedback and the model came back with this. It actually had written a test file when it was designing the Analyst chat feature. In that test file it had written fake revenue numbers just to test and see if the chat was working for itself in code. So it wrote a number that it was going

22:14 and querying instead of our actual CSV. It’s now picked up on that, and it looks like it’s even telling us that it will now look at the current CSV and question that when we ask for information. So now, let’s upload our CSV again and ask the same question, which product category is driving the most revenue? And we can see that it did some thinking

22:45 and it’s telling us software with 7.92 million, which is exactly correct when we look at our dashboard. This back and forth testing is pretty important because sometimes the model will have done this test case where it is actually just building your app and making sure everything works, And so in this case, we picked up on that and we corrected our app. And now it’s in a state that is good to share with our executive team. So now I’ve added the executive to the app and I want to make sure they experience it in full screen.

23:17 So instead of seeing a view like this, we want them to open to a view like this. So I’m going to hit share, check this toggle and then hit copy link. And when they open the app they’ll get a full screen view of the dashboard we just created. Securing your data and setting up a control rollout is what ensures your tool is ready to be shared with others. You have a complete system to plan, debug and share your apps.

23:47 Now the final move is yours. Take what you’ve learned to secure and deploy your app build, and see how your app can simplify work for others. I look forward to seeing your apps in action. You’ve got this.