O guia definitivo de vibe coding | Google

Autoria: Grow with Google · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: The ultimate guide to vibe coding | Google · Canal: Grow with Google · 23:47 · Assistir no YouTube

Tópicos: Cibersegurança e segurança de software, Engenharia de software com IA

Resumo

Ammaar apresenta um workflow em três fases para transformar ideias em apps confiáveis: planejar, testar e depurar, e preparar o compartilhamento com segurança. Com demonstrações no AI Studio, ele mostra como refinar prompts com requisitos e documentos de referência antes de gerar um protótipo. Em seguida, usa erros, logs e testes sob pressão para identificar falhas e ajustar o app. Por fim, demonstra como fundamentar respostas em dados verificados, configurar uma experiência de boas-vindas e compartilhar o app com as pessoas certas.

Pontos-chave

Planeje os requisitos e as restrições antes de pedir à IA que crie o app.
Use conversas iterativas para refinar a solução e transforme o planejamento em um prompt claro.
Anexe documentos e planilhas relevantes para dar contexto e orientar o app com dados reais.
Teste o app com cenários concretos, examine os logs e forneça à IA detalhes sobre os erros encontrados.
Peça ao app para corrigir automaticamente saídas que violem as regras definidas.
Use verificações antes da exportação para confirmar que regras e requisitos foram atendidos.
Verifique se o app consulta os dados corretos, em vez de responder com números ou categorias fictícios.
Configure uma mensagem de boas-vindas e controle o acesso antes de compartilhar o app.

Capítulos

Início	Capítulo	Resumo
00:00	O workflow de vibe coding	Ammaar apresenta o processo em três fases: planejar, testar e depurar, e preparar o app para compartilhamento.
02:05	Planejamento e criação do protótipo	O apresentador refina os requisitos com Gemini, usa documentos de referência e cria um app baseado no plano do projeto.
10:05	Testes e depuração	A demonstração identifica erros no app, usa logs para orientar as correções e adiciona validações automáticas para as regras do storyboard.
18:02	Preparação para compartilhar com a equipe	O apresentador fundamenta um dashboard em padrões financeiros, acrescenta uma mensagem de boas-vindas e testa suas respostas com dados reais.
23:17	Compartilhamento e implantação	Ele configura uma visualização em tela cheia para quem recebe o link e conclui incentivando o público a proteger e compartilhar seus apps.

Citações

Se você consegue descrever, consegue construir. — 00:00

Um único prompt é um ótimo começo, mas só a intuição não vai impedir que um app quebre quando as coisas ficam complexas. — 01:02

Investir tempo em um plano não é apenas uma etapa preliminar: é a estratégia que transforma um prompt único em uma ferramenta confiável. — 09:34

Testar intencionalmente os limites do seu app é a melhor maneira de provar que ele está pronto para o mundo real. — 17:01

Conceitos e entidades

vibe coding (conceito): Abordagem de criação de apps por meio de instruções em linguagem natural e iteração com IA.
AI Studio (ferramenta): Ferramenta usada nas demonstrações para conversar com modelos e criar apps.
Gemini (modelo): Modelo de IA usado para planejar, gerar, testar e corrigir os apps demonstrados.
Gemini 3.5 Flash (modelo): Modelo que o apresentador escolhe para ajudar a elaborar o prompt inicial.
Gemini 3.1 Pro (modelo): Modelo mencionado ao investigar um erro relacionado ao limite de uso.
Google Drive (ferramenta): Serviço usado para fornecer documentos e planilhas como contexto para o app.
Project Ripple (conceito): Nome criado pelo app para o protótipo de acompanhamento de tarefas e atrasos em um projeto.
Gantt chart (conceito): Representação visual de tarefas e cronogramas citada como uma opção para o app de planejamento.
CTA (conceito): Chamada para ação que o apresentador pede que apareça no diálogo final de cada storyboard.

Tradução completa (pt-BR)

00:00 Se você consegue descrever, consegue construir. Essa é a magia do vibe coding. É a maneira mais rápida de transformar uma ideia em um app, mas, como muitos criadores sabem, a magia pode ser imprevisível. Sou Ammaar e lidero a área de produto e design do AI studio aqui no Google. Um único prompt é um ótimo começo, mas só boas intenções não vão impedir um app de apresentar problemas quando as coisas ficarem complexas. Para criar ferramentas nas quais você e sua equipe possam realmente confiar, é preciso ir além do prompt de uma única tentativa. Você precisa de um sistema. Hoje, vou mostrar o workflow de três fases que os profissionais usam.

00:32 Essas são as habilidades essenciais que transformam uma demonstração interessante em uma ferramenta confiável, segura e fácil de compartilhar. É assim que você adota a mentalidade de um desenvolvedor. Primeiro, vamos elaborar um plano sólido, que servirá de base para desenvolver sua ideia. Depois, vamos testar e depurar para garantir que seu app funcione de maneira confiável. Por fim, vamos fazer o deploy do app para que outras pessoas possam usá-lo em um ambiente seguro e protegido. Vou usar o AI studio nestas demonstrações, mas essas estratégias funcionam em qualquer ferramenta de IA baseada em navegador.

01:02 Como as ferramentas de IA mudam com frequência, sempre confira os recursos atuais das plataformas. Depois de deixar tudo pronto, você estará preparado para criar ferramentas que simplifiquem seu trabalho e economizem o tempo da sua equipe. Poder fazer vibe coding de um app do zero muda tudo. E é natural querer começar logo o desenvolvimento. Seja para criar um app pessoal ou um app para compartilhar com outras pessoas, ainda é preciso investir em um bom planejamento para garantir que ele realmente funcione. Vou usar o AI Studio como parceiro de reflexão

01:33 para elaborar um plano claro antes de criar qualquer código. Vou começar fazendo perguntas à IA para me ajudar a levantar os requisitos. Depois, podemos aprimorar essas ideias e transformá-las em um plano de projeto personalizado, também conhecido como documento de especificações. Em seguida, vou definir regras simples para manter a IA no caminho certo e impedir que invente coisas. Ao final, você verá como esse workflow transforma nosso plano em um protótipo confiável. Vamos começar. Nesta demonstração, vou assumir o papel de gerente de projetos.

02:05 Em um projeto típico, acompanho dezenas de tarefas que dependem umas das outras. Eis um problema que encontro: quando uma tarefa atrasa, não consigo ver como isso afeta o restante do projeto ou a data de lançamento. Então, quero criar um app que mostre como as tarefas se conectam e como um atraso afeta cada etapa seguinte. Legal, agora estamos no ambiente de testes do AI studio. É aqui que você pode conversar e experimentar todos os modelos Gemini. Vou usar o Gemini 3.5 flash para criar um prompt para nós.

02:38 Vou começar simplesmente descrevendo meu problema aqui. Quero criar um app que receba um plano de projeto e mostre visualmente como o atraso de uma tarefa pode afetar o projeto inteiro e o lançamento final. Ajude-me a planejar isso. Agora, quando clico em executar, o Gemini vai analisar o problema e encontrar uma solução. Ele nos deu cinco fases, mas não quero o gráfico. Quero algo bem mais simples para visualizar os projetos.

03:11 Então, vou dizer: não tenho tanta certeza sobre a representação do projeto em um gráfico. Podemos pensar em uma visualização simplificada? Talvez seja informação demais para colocar em um único prompt. Na prática, é um documento grande, e também não queremos confundir o modelo com detalhes demais. Então, vou encontrar um bom meio-termo. E também vou continuar dizendo: quero que você escreva isso como um prompt sólido, em um único parágrafo, para uma ferramenta de vibe coding, explicando o que deve ser criado,

03:44 e inclua no prompt todos os detalhes essenciais. O que é útil aqui, e o motivo de estarmos planejando, é que, se não tivéssemos feito isso, você já teria visto o modelo adicionar um gráfico que ele considerou uma solução. Mas talvez eu tivesse outra coisa em mente. O legal é que, como continuei dizendo que não tinha tanta certeza sobre a representação em gráfico, agora ele está sugerindo algumas outras ideias. Ele diz: certo, talvez uma rede complexa seja demais. Poderíamos mostrar as informações em uma lista hierárquica ou em uma planilha.

04:16 Essa conversa de idas e vindas é, na prática, a parceria que você vai desenvolver com o Gemini enquanto cria coisas. Você vai conversar, trocar ideias e chegar a uma solução de que goste e que realmente resolva o problema que está tentando solucionar. Gosto da ideia de algo bem mais simples, e parece que ele até criou um prompt de um parágrafo para uma ferramenta de vibe coding. Ele diz que vai criar um único app. Definiu alguns detalhes técnicos para nós. E você também pode ver que ele abordou parte da UI que vamos obter. Por exemplo, diz que você quer um controle deslizante para simular os dias.

04:48 Isso é muito interessante. Um gráfico de Gantt responsivo, também gostei. E parece que ele destaca o efeito cascata na linha do tempo, mostrando os itens desbotados quando ocorre um atraso. Tudo isso me parece muito legal. Então, agora vou pegar isso e criar um app com esse material. Temos um ótimo prompt, mas quero ter certeza de que não estou deixando passar nenhum detalhe. Agora posso dar algum contexto ao Gemini e ver se há outras coisas que eu deveria considerar neste prompt para o app que estou criando.

05:20 Observe o botão de mais aqui embaixo. Se eu clicar nele e selecionar Drive, posso acessar a pasta do meu projeto e escolher o documento Project Charter. Agora o Gemini pode usar esse conteúdo como contexto para nos ajudar a aprimorar o prompt. Então, posso dizer: leia o documento de abertura do projeto abaixo. Há outras perguntas ou coisas que eu deveria considerar ao criar o app sobre o qual estamos conversando?

05:50 Agora vamos fornecer esse contexto, e o Gemini vai analisar tudo isso e nos dizer se há outras coisas que deveríamos considerar. Essa é mais uma maneira interessante de conversar com um modelo e construir algo em conjunto. Como você pode ver, ele está nos dando vários detalhes que talvez devêssemos considerar. Por exemplo, percebeu que a aprovação na App Store leva de sete a quatorze dias. Isso não é trabalho ativo feito pela equipe; é um período de espera. Seu app precisa dar conta do tempo de espera e das dependências. Essa é outra ideia interessante em que eu nem tinha pensado

06:23 e que agora podemos incorporar ao nosso app. Outra coisa que você pode notar é que ele menciona os orçamentos identificados no documento de abertura do projeto e diz que também poderia ser útil mostrar, nessa visualização, uma taxa de custo diário para determinadas tarefas. Todas essas são ótimas ideias que o modelo identificou e nos deu para trabalhar. Agora vou dizer: incorpore todas essas coisas que você identificou ao prompt original que me deu. Então, incorpore todos esses pontos que você percebeu ao prompt original. Legal. Agora temos o prompt revisado final.

06:54 Vamos transformar isso em algo que possamos construir. Para fazer isso, basta clicar nos três pontos. Clique em “Criar um app”. Agora vou para o modo Build, e nosso prompt foi copiado. Mas observe que ele também copiou tudo o que disse antes do nosso prompt. É bom ficar atento a isso, porque o que está acontecendo é que ele está simplesmente transferindo a conversa para esta tela de criação. Mas você pode limpar tudo isso, indo até a parte em que está o prompt propriamente dito e apagando o restante. Agora você fica só com o prompt.

07:25 Na prática, esse prompt contém todos os recursos que nos interessam e as restrições, resumindo muito bem nosso documento de especificações. Antes, você tinha os requisitos e tudo aquilo detalhado; agora, tem algo que um modelo de IA pode seguir para construir o app. Só falta anexar mais uma coisa: nosso plano de projeto propriamente dito. Então, se eu acessar o Drive e selecionar a planilha do Google do nosso projeto, ela contém o plano completo. E agora posso dizer:

07:56 Também anexei a planilha do Google Sheets com o plano do nosso projeto. Certifique-se de basear o app nela. Geralmente gosto de dizer algo como “certifique-se”, porque às vezes o modelo pode seguir uma direção em que usa a planilha mais como referência, em vez de realmente segui-la do começo ao fim. Então, agora, só preciso clicar em criar. Certo. O app foi criado, e dá para ver que os modelos adoram dar nomes às coisas.

08:31 Ele até chamou o app de Project Ripple. Não há nenhum lugar em que eu o tenha chamado de Project Ripple. Tudo bem. Podemos mudar a marca do app mais tarde. Mas você vai ver que ele adicionou todas as diferentes fases e tarefas com base na nossa planilha. Desde a pesquisa de mercado até as fases de design de UI/UX, que, acredito, estão todas perfeitamente mapeadas para o nosso app. Você também vai notar que ele adicionou o controle deslizante de atraso de que falamos. A opção de semana de cinco dias e até orçamentos como contingência.

09:02 Então, se eu mexer em qualquer uma dessas coisas, digamos, no controle deslizante de atraso, dá para ver como ele vai adiando diferentes tarefas que dependiam dele. Era exatamente isso que queríamos. E o mais legal é que esse protótipo é bastante pessoal para mim. Ele é personalizado para a planilha que forneci. É personalizado para o termo de abertura que forneci, e entendeu todas essas restrições para criar algo que eu realmente posso usar e compartilhar com a equipe. Isso nos dá um protótipo funcional criado com base em um plano documentado. Em seguida, vamos testá-lo e corrigir o que não funcionar.

09:34 Investir tempo em um plano não é apenas uma etapa preliminar. É a estratégia que transforma um prompt de uma única tentativa em uma ferramenta confiável. E, ao definir as restrições desde o início, você vai deixar de apenas fazer prompts e passar a conduzir a criação. Agora é a sua vez de começar a planejar a criação do seu primeiro app. Mal posso esperar para ver o que você vai criar. É ótimo quando o app funciona logo na primeira tentativa, mas essa é a parte fácil. O trabalho de verdade começa quando as coisas começam a dar errado,

10:05 e é aí que você aprende a solucionar problemas. Hoje, você vai aprender estratégias de solução de problemas que melhoram o desempenho do app. Vou orientar a IA para dividir o app em partes menores e identificar os problemas exatos. Criar em etapas e verificar as mensagens de erro é como resolver problemas rapidamente. Certo. Meu protótipo está pronto. É um app que transforma uma ideia de vídeo em um storyboard do que vemos, do que ouvimos e da duração de cada tomada. E vou mostrar como testá-lo sob pressão para encontrar possíveis pontos fracos ocultos,

10:38 Saber lidar com um contratempo é o que transforma um rascunho em um app confiável. Vamos lá. Já temos nosso app, mas a experiência não é bem a que eu queria. Tenho o layout de três colunas, mas queria que essa caixa de prompt fosse a primeira coisa que aparece. Depois, chegamos ao layout de colunas com o storyboard que queríamos visualizar, já preenchido. Então, vou pedir essa alteração. Vou dizer que quero mudar um pouco a experiência do app: em vez de uma única página com tudo,

11:13 primeiro quero que apareça uma caixa de prompt onde eu possa inserir a ideia do storyboard e, depois, que ela passe para uma nova tela com o layout de três colunas que temos. Então, vou enviar isso para o Gemini, e ele fará as atualizações solicitadas na interface. Isso faz parte do processo de iteração ao criar um protótipo. O Gemini interpretou de um jeito, tentando acrescentar seus próprios detalhes

11:44 e talvez seus próprios layouts, mas nós temos outra ideia. Então, você simplesmente vai e volta com o modelo até chegar à experiência que esperava. Ótimo. Observando o resultado, o Gemini entendeu que queríamos uma boa tela inicial. Adorei a caixa de prompt que ele adicionou aqui; ele até pergunta se o conceito do vídeo que estamos tentando visualizar é de formato curto ou longo. Agora, vamos testar nosso app. Vou descrever um anúncio curto

12:14 de um novo tipo de café. E vou clicar em “Gerar storyboard”. Certo, executamos nosso app e encontramos um erro. Agora, vamos depurá-lo juntos com o Gemini para corrigi-lo e chegar a um visualizador de storyboard funcional. A primeira coisa que você vai notar são três eixos vermelhos na parte inferior da tela. Se eu clicar neles, vejo um painel de depuração. Basicamente, ele nos mostra onde o app pode estar falhando. Isso ajuda a dar contexto ao Gemini para que eu possa corrigir nosso app.

12:45 Aqui, dá para ver que a mensagem diz que ocorreram erros ao gerar o storyboard, exatamente o que aconteceu quando clicamos no botão de gerar. E, na área de chat, dá para ver que aparece “três erros ao executar o código”. Há um botão para corrigir. Se clicarmos nele, o Gemini começa a analisar essas mensagens de erro e a trabalhar para fazer nosso app funcionar. Observando o registro de erros, você também pode ver, entre as outras informações, a mensagem que explica o que está dando errado. Bem aqui, dá para ver que diz que excedemos nossa cota e que talvez não possamos mais usar o 3.1 Pro neste app.

13:18 Poderíamos mudar para outro modelo. Mas, enquanto o Gemini trabalha na correção, vamos ver o que ele vai fazer. Ótimo, o Gemini respondeu e percebeu que o problema era a cota que mencionamos. Ele também vê que estávamos usando o 3.1 Pro e sugere usar o 3.5 flash. Também encontrou outros problemas e os corrigiu. Agora, vamos testar nosso app de novo. Vou digitar um conceito de vídeo e ver se ele gera um storyboard. Vamos criar um anúncio para um novo tipo de café.

13:50 Certo, vejo que um storyboard foi gerado. Ele tem descrições visuais, diálogos de áudio e até a duração e o tipo de tomada, o que é muito útil. Mas o que estou percebendo é que, ao chegar aos itens três e quatro, ele me diz quais erros está encontrando nessas descrições. Aqui, diz que a duração do plano de detalhe deve ser de dois a quatro segundos e que o B-roll deve ter de um a três segundos. Então, ele entendeu nossas diretrizes. No entanto, está me deixando fazer o trabalho de montar esse storyboard.

14:21 E eu quero que o próprio app cuide disso. Então, vou pedir essa alteração. Vou dizer: quando você gerar um storyboard e encontrar algum problema que não esteja de acordo com nossas diretrizes, corrija-o automaticamente e ajuste cada tomada. Vou fornecer uma captura de tela como exemplo do que ele já está fazendo, para dar contexto, e então vou enviar esse prompt.

14:53 Ótimo, dá para ver que o Gemini respondeu explicando como fez a correção. O que ele está dizendo é que, primeiro, vai fazer a solicitação para gerar o storyboard. Se, por algum motivo, ele violar alguma das regras que fornecemos, o Gemini executa outro ciclo para corrigir aquela área específica, para que tudo funcione no nosso storyboard visual sem que precisemos cuidar disso. Então, vamos fazer isso de novo. Quero criar um anúncio para um novo tipo de café.

15:24 Agora, dá para ver o storyboard visual com tudo de acordo com as restrições e sem nenhum erro no anúncio proposto. Legal, também notei um botão para verificar a exportação. Se eu clicar nele… Ótimo, ele está mostrando que levou em conta todas as regras da marca e que elas foram aprovadas. Agora podemos prosseguir com a exportação. E quero adicionar uma instrução de controle final: o storyboard deve sempre terminar com uma CTA. Talvez até possamos adicionar isso como uma regra que ele nos informa.

15:55 Então, vamos garantir que fazemos esse pedido. Quero adicionar aqui uma instrução de controle para que todo storyboard gerado sempre termine com uma CTA no diálogo. Certifique-se também de destacar isso na verificação de exportação. Certo, parece que o Gemini atualizou a geração do storyboard para garantir que sempre haja uma CTA no diálogo final.

16:28 Podemos ver que ele recebeu instruções rigorosas para o modelo e até adicionou isso ao nosso ciclo de autocorreção. Então, vamos pedir isso. De novo, quero criar um anúncio para um novo tipo de café e clicar em enviar. Ótimo, ele gerou nosso storyboard. E, se voltarmos ao diálogo final, podemos ver que há uma CTA que diz “Comece grátis”. Quando vamos à verificação de exportação, ela diz que todas as regras da marca foram aprovadas. Mas lembre-se de que pedimos que, se faltasse a CTA, ele nos avisasse aqui.

17:01 Então, por que não voltamos ao editor e mudamos essa última linha para algo como “Café é incrível” e, se voltarmos à verificação de exportação, ótimo. Ele está nos dizendo que há um erro e que falta uma CTA aprovada na seção de diálogo. Então sabemos que nossa verificação prévia está funcionando como deveria. Testar intencionalmente os limites do seu app é a melhor maneira de provar que seu trabalho está pronto para o mundo real. Você sabe trabalhar com a IA para isolar falhas e rastrear

17:32 a causa raiz de qualquer problema antes que ele afete seus usuários. Agora, coloque sua build à prova. Não se preocupe com os erros. É apenas a IA mostrando como deixar o app ainda mais robusto. Espero que você consiga solucionar os problemas e chegar a uma versão melhor. Agora que seu app está funcionando, talvez você esteja pronto para levá-lo ao próximo nível e compartilhá-lo com outras pessoas. Vou mostrar como conectar seu app a arquivos reais do projeto, para que ele sempre use informações reais e verificadas em vez de fazer suposições.

18:02 Também vamos configurar uma mensagem de boas-vindas simpática que sirva como um lembrete discreto da política para lidar com dados internos com segurança. Depois, vamos definir as permissões, controlando exatamente quem tem acesso por meio de uma liberação em etapas. Ao estabelecer essas proteções, qualquer pessoa que use seu app poderá começar a obter resultados confiáveis por conta própria. Agora que colocamos o app sob pressão e corrigimos os pontos fracos, meu protótipo está testado. Ele transforma minhas planilhas de vendas em um resumo que a liderança pode usar, com um painel de chat para perguntas de acompanhamento.

18:32 Agora vamos prepará-lo para compartilhar com a equipe. Mostrei esse painel a alguém da equipe, e essa pessoa adorou, mas ele ainda não está pronto para ser compartilhado com todo mundo. Então preciso fazer algumas mudanças para deixá-lo pronto para compartilhar com a equipe. Vamos pedir isso. Primeiro, quero fundamentar todas as métricas e cálculos do nosso app nos padrões financeiros que temos.

19:02 Este é um documento que estou anexando. Siga-o para todos os cálculos e regras internas; você deve aplicar tudo isso ao nosso painel. Segundo, estou me preparando para compartilhar este app com nossos executivos. Adicione um banner de boas-vindas explicando este painel e seus recursos para ajudá-los a começar. Então vou escolher o documento de Padrões Financeiros. Vou acessar o Google Drive e selecioná-lo,

19:35 e adicioná-lo como contexto ao nosso prompt. E você pode ver aqui como tudo foi configurado. Então vou enviar o pedido. O Gemini cuidará do resto. Certo, ele voltou com o que fez. Diz que resolveu os cálculos. Corrigiu e incorporou os padrões financeiros em todos os recursos de IA também. E o app está fundamentado nos dados da nossa empresa. Agora vamos testar nosso app. Vou enviar nosso CSV novamente. E você pode ver aqui que ele adicionou um banner de boas-vindas.

20:07 Ele explica que este painel apresenta métricas gerais, detalhamentos por região e categoria de produto, e que podemos analisar o desempenho ou pedir informações mais detalhadas no chat. Vou fazer mais uma rápida demonstração de todo o app para garantir que foi testado e está pronto para ser compartilhado. Vou fazer uma pergunta: qual categoria de produto está gerando mais receita?

20:39 Certo, nosso chat está claramente nos dando informações incorretas. Não há eletrônicos nas categorias de produtos. E esse número, 1.234.567…, parece uma receita incrível, mas não é um valor que eu esteja vendo em nenhum outro lugar. Então, podemos dar esse contexto ao modelo novamente. Colei a captura de tela porque queria fornecer esse contexto. Agora vou dizer: as respostas no chat do Analista

21:11 são quase instantâneas e não parecem precisas. Mencionei que são quase instantâneas porque antes parecia que o Gemini estava pensando, mas agora ele está apenas respondendo com um prompt bastante padrão. Então estou me perguntando se ele está mesmo enviando o chat. E, ao depurar dessa forma, é importante tentar dizer ao modelo exatamente o que você está vivenciando, porque assim ele pode pensar em como você pode ter chegado a esse problema. Ainda bem que testamos isso, porque, se eu tivesse compartilhado este app

21:44 com a equipe executiva, eles teriam visto alguns números mágicos e uma categoria que não existia, e eu teria muito mais perguntas para responder. Certo, demos esse feedback e o modelo voltou com esta resposta. Na verdade, ele havia escrito um arquivo de teste quando estava criando o recurso de chat do Analista. Nesse arquivo de teste, tinha escrito números falsos de receita só para testar e ver se o chat estava funcionando no próprio código. Então, ele escreveu um número que estava

22:14 consultando, em vez de usar nosso CSV real. Agora ele percebeu isso, e parece que está até nos dizendo que, quando pedirmos informações, vai consultar o CSV atual. Então, vamos enviar nosso CSV novamente e fazer a mesma pergunta: qual categoria de produto está gerando mais receita? E podemos ver que ele pensou um pouco

22:45 e está nos dizendo que é software, com 7,92 milhões, o que está exatamente correto quando olhamos para o nosso painel. Esse processo de testes e ajustes é muito importante, porque às vezes o modelo terá feito esse caso de teste enquanto estava criando seu app e verificando se tudo funcionava. Então, neste caso, percebemos isso e corrigimos nosso app. Agora ele está em um estado adequado para ser compartilhado com nossa equipe executiva. Então, adicionei o executivo ao app e quero garantir que ele o veja em tela cheia.

23:17 Em vez de ver uma visualização como esta, queremos que o app abra em uma visualização como esta. Vou clicar em compartilhar, marcar esta opção e depois clicar em copiar link. Quando abrirem o app, verão em tela cheia o painel que acabamos de criar. Proteger seus dados e configurar uma liberação controlada é o que garante que sua ferramenta esteja pronta para ser compartilhada com outras pessoas. Você tem um sistema completo para planejar, depurar e compartilhar seus apps.

23:47 Agora, o passo final é seu. Use o que aprendeu para proteger e fazer o deploy da sua build de app e veja como seu app pode simplificar o trabalho de outras pessoas. Espero ver seus apps em ação. Você consegue.

Transcrição original

[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.