Como eu uso o Claude Code (Workflow Anti-Vibe Coding)

No vídeo de hoje, eu vou mostrar para vocês o workflow completo que eu uso para construir aplicações com o Cloud Code. E esse é exatamente o mesmo processo que eu usei para construir o Epic, que é o meu app que tá com mais de 3.000 usuários que eu lancei há 90 dias, se eu não me engano, sem escrever uma linha de código. E se você acha que todo código gerado por ai não presta, eu vou te dizer que você pode estar certo ou Você pode estar errado, dependendo da maneira como você faz isso. Porque se

você faz vibe coding, né, no sentido literal desse termo, que é basicamente você jogar um monte de promptatório e fazer uma oração torcendo para aquilo dar certo, eu acho que você tá certo. Eu acho que o código gerado por AI dessa forma não funciona mesmo. E eu não colocaria algo feito assim em produção. Agora, se você tem um método para você conseguir explicar pra IAI exatamente o Que precisa ser feito, aí eu te garanto que a sua percepção vai ser bem diferente, como foi o meu caso, porque foi assim que eu consegui construir o appicc

do começo ao fim, coisa que a maioria das pessoas que não tm um background de engenharia jamais conseguem fazer porque em algum momento elas vão travar. E eu não travei justamente porque eu aprendi esse método que realmente foi muito, muito útil nessa minha jornada. E essa metodologia Que eu uso, o pessoal chama de spec driven developments, né? Então você tem o test driven developments, esse é o Spect Driven Developments, que eu vou abreviar de SDD, só para facilitar um pouco. E a maneira que eu faço isso é relativamente simples e ela consiste em três passos

que são, primeiro, eu começo fazendo uma pesquisa na minha base de código existente, lendo documentações externas e buscando padrões de implementação que eu quero trazer para Dentro do meu projeto. Aí eu pego e gero o que eu chamo de prd.md. Aí depois eu passo paraa segunda etapa, que é escrever uma spec. Então eu pego o output que eu tive nessa fase de pesquisa e gero uma spec que é basicamente um arquivo que diz todos os arquivos da base de código que precisam ser criados e todos os arquivos da base de código que precisam ser modificados

e o que precisa ser criado ou modificado em cada arquivo. E aí por fim pego o Resultado disso que é o my spec.m e passo para a terceira etapa para enfim implementar esse plano da minha spec. Então é basicamente isso que eu faço. Agora eu vou explicar para vocês no detalhe, passo a passo, tudo que eu faço para vocês conseguirem aplicar exatamente esse mesmo método no workflow de vocês. Só que antes da gente entrar no método, eu queria dar só um pouco de contexto para vocês, para vocês entenderem por que as pessoas acham que O

código gerado por AI não presta. Bom, então eu vou compartilhar para vocês os problemas que eu tive, tá? Eh, não sei se tem mais algum aqui que eu que eu deixei de listar, mas se você por acaso observou algum outro padrão que eu deixei de listar aqui, por favor, deixa aqui nos comentários que eu quero saber. O primeiro padrão bem comum é o que a gente chama de overengine engineering. Então, muitas vezes a II vai ter o hábito de complicar um negócio que Poderia ser muito muito simples. Esse é um padrão bem comum que eu

já observei que eu tô falando do cloud code, tá? Mas isso se aplica a literalmente todos os modelos. Outro padrão bem comum é reinventar a roda. Então, muitas vezes já existe alguma coisa pronta e ele vai te induzir a criar algo novo. Vou dar um exemplo bem fácil de entender para vocês. O appic tem o Markdown Editor, né, que é tipo esses como se fosse um Notion, sabe, onde você consegue anotar As suas coisas e e formatar ali o o texto bonitinho. E quando eu tava desenvolvendo isso no Epic, ele tentou me induzir a criar

o Markdown Editor do Zero. Só que isso é um trabalho absurdo, né? Não sei se algum de vocês já tentou codar isso do zero, mas é realmente muito trabalhoso. Por sorte, eu tinha feito uma pesquisa antes e eu sabia que existiam algumas soluções prontas, como o Pros Mirror, por exemplo, e o tip Tap, que eu acabei usando para fazer o appic. Daí eu não tive que criar um Markdown Editor do zero, então eu não tive que reinventar a roda, mas assim tô dizendo pr vocês que isso é um padrão que eu sei que acontece e

é importante vocês ficarem de olho. Outro ponto, às vezes ele não sabe fazer o que você pediu. Então, por exemplo, você pediu para ele implementar alguma coisa com uma documentação que saiu em 2026, só que a base de corte do treinamento dele foi de 2024. Ele não vai saber implementar, né? Então, ele vai fazer o melhor, mas possivelmente ele vai errar. Outra coisa comum, ele repete trechos de código que já existem na sua base de código. Então, dando um exemplo aqui fácil para todo mundo entender, você criou já um componente de botão, já existe um

arquivinho de botão. Ele não se lembra que ele fez isso. Aí que ele faz, cria outro botão. E agora você tem que dar manutenção no botão um e no botão dois, ao invés de você dar manutenção em um Botão só, porque ele basicamente faz a mesma coisa. Então esse é um padrão bem comum também e isso é um pesadelo de manutenção, porque você tem que ficar fazendo o dobro, triplo, quádruplo de manutenção por causa desse tipo de coisa. E outra coisa que eu já vi também é que muitas vezes ele acaba juntando códigos que fazem

coisas diferentes, né, que tem responsabilidades diferentes dentro do mesmo arquivo. E isso também Torna o seu código um pesadelo de manutenção. Bom, então esses são os padrões que eu já vi que são muito comuns de acontecerem com a EI. E é esse tipo de coisa que faz aí travar no meio do projeto, porque chega uma hora que esses débitos técnicos vão ficando tão grandes, mas tão grandes, mas tão grandes, que ela realmente não vai conseguir avançar. E o maior culpado de tudo isso é o que a gente chama de context window, né, que é a

janela de Contexto do seu modelo. Então, só para ficar mais ilustrativo, para quem não tá familiarizado com esse termo, context window pensa que é tudo o que o modelo consegue se lembrar, digamos assim. E geralmente isso é medido em número de tokens, né? Então a gente vai falar: "Ah, 400.000 tokens, 200.000 tokens". Esse é o tanto de informação que o seu modelo consegue, entre aspas, se lembrar. E o token, só para vocês terem uma uma dimensão do que que é um token, Geralmente um token são quatro caracteres. Então, se a gente fala 200.000 tokens, a

gente tá falando de 800.000 caracteres. Isso é tudo que a sua AI consegue se lembrar. Só que por que que esses probleminhas que eu relatei acontecem, né? Eh, quando a gente fala de desse padrão de overengine engineering, o que acontece? A sua talvez não saiba que existe uma forma mais simples de fazer aquilo que ela tá fazendo. Por quê? Porque você não diz Para ela: "Isso não tá no context window dela." Por que que a IAI reinventa a roda? Porque às vezes ela não sabe que alguém já fez aquilo que ela tá tentando fazer. Por

que que ela às vezes não sabe fazer alguma coisa ali quando você pede para ela implementar uma documentação externa? Porque às vezes ela não sabe que ela tem que ler uma documentação que talvez esteja mais atualizada do que conhecimento que ela tem. você também provavelmente não diz para ela, não Disse isso para ela e não colocou isso na janela de contexto dela. Essa parte de repetir trechos de código é mais um problema clássico de context window, porque às vezes ela já fez, por exemplo, o botão que a gente deu de exemplo, já existe aquele botão,

só que esse botão foi feito antes de estourar a janela de contexto dela. Então, como estourou, ela não se lembra daquele botão, porque aquele botão passou do montante de coisas que ela poderia se lembrar. E por Fim, esse padrão de juntar tudo no mesmo lugar. Eh, por que que isso acontece? Porque você muitas vezes também não diz para ela, né? Não coloca isso na janela de contexto, a maneira como você quer separar os seus arquivos. E aí, se você juntar tudo isso aqui que eu disse para vocês, é assim que você produz um código muito

muito ruim. É por isso que tem muitas pessoas que dizem que eh vibe coding não funciona. E de fato, como eu disse, vibe coding não funciona, mas Existe uma maneira de você conseguir endereçar cada um desses pontos e fazer a sua AI gerar um código que é muito mais confiável e muito mais fácil de dar manutenção. Uma coisa que é muito importante a gente lembrar é que meio óbvio que eu tô falando aqui, né? Mas a qualidade do seu input determina a qualidade do seu output. Então, se faltou informação no seu input, se a informação

que você colocou é ruim, se a informação que você colocou é errada, Provavelmente o que ela vai produzir ali é bem ruim, né? Porque a IAI é um multiplicador de coisas, entendeu? Eu costumo falar que ã quem transforma água em vinho é Jesus, né? A Iai não transforma uma coisa na outra, ela multiplica o que você deu para ela. Então, se você alimentou a sua EAI com um monte de bosta, o que ela vai produzir também é um monte de bosta. e você não deveria ficar surpreso, né? Eu pelo menos não ficaria. Então assim, Para

começar a gente precisa lembrar disso, que é uma coisa meio óbvia, mas eu vejo frequentemente as pessoas se esquecendo. Bom, e aí quando a gente diz que a qualidade do seu output é diretamente proporcional à qualidade do seu input, só para deixar um pouco mais claro no contexto de geração de código, o que que acaba com a qualidade do seu input? Primeira coisa, informação incorreta, tá? Então, às vezes você pode colocar um prompt ali que está errado. Às vezes você pediu para alterar um arquivo que não é aquele arquivo que tem que ser alterado. Ou

às vezes você do seu prompt não deixou claríssimo qual arquivo tem que ser alterado. E aí é óbvio que ela vai fazer bosta. Então, informação incorreta realmente é um problema que vai acabar com a qualidade do seu input. Outra coisa, informação incompleta. Então, por exemplo, se a gente voltar aqui que a gente tava falando, eu não passei a documentação do Da biblioteca que eu tô usando. Ela não tem como adivinhar, né? Então, a informação incompleta vai fazer ela provavelmente implementar coisas erradas. Informações inúteis também não ajudam. Por quê? porque elas enchem a sua janela de

contexto e elas não agregam em nada para o output, porque a talvez aquela informação não vá fazer ele produzir um output melhor ou pior, logo ele só tá enchendo a janela de contexto e confundindo a sua AI também. Isso acaba com a qualidade do seu input. E por fim, informações de mais. Então, quanto mais informação você tiver e mais você encher a sua janela de contexto, pior vai ser a qualidade do seu output. Isso todo mundo fala, todos os pesquisadores. E eu, como testei muito isso, eu posso afirmar para vocês que isso é verdade. E

aí, só para vocês entenderem o que que vai entrando na sua janela de contexto. Primeira coisa, você buscou um arquivo. Então, quando ele tem Que rodar comandos para ficar buscando os arquivos, ele vai escrever o comando para buscar, ele vai receber o retorno com todos os arquivos da sua base de código. Tudo isso tá consumindo janela de contexto. Aí ele vai ler os arquivos que ele achou. não vai consumir de nada de contexto. Aí ele vai editar arquivo, vai consumir também. Aí ele vai eh eh escrever algum arquivo novo, vai consumir já de contexto também.

Aí ele rodou um MCP. Eu não sei se vocês já Viram, mas quando você roda um MCP, a resposta do MCP é um Jason Blob enorme com um monte de informação. Isso consome essa janela de contexto também. E também os prontos que você manda pro seu coding assistant também vão consumir a janela de contexto do mesmo jeito. E aí você vai somando, somando, somando, somando, somando e isso vai enchendo a sua janela de contexto. E geralmente quanto mais cheia a sua janela de contexto está, pior o seu resultado é, né? Isso é Claríssimo. Eh, acho

que em todas as pesquisas que eu li isso fica claro. Eh, e como eu disse, testei para comprovar que isso é sim, verdade. Então, se isso é o que a gente não quer, o que que a gente quer? a gente quer alimentar a II com as informações necessárias para ela fazer uma implementação, só que da forma mais resumida possível. Então assim, eu não posso ter informações incompletas, né? Eu preciso que todas as informações Estejam lá. Só que eu preciso fazer isso da forma mais resumida possível. Por quê? porque eu quero usar a menor parte possível

da minha janela de contexto para deixar a maior parte possível da minha janela de contexto para que ela possa fazer a implementação do jeito certo. Então, dado essa introdução toda, como que eu faço isso na prática, tá? Eu vou explicar aqui um pouco para vocês. Bom, para vocês terem uma ideia, eu comecei a usar o Cloud Codes em abril, Né? né? Então, faz quase 10 meses que eu tô usando ele. E ele foi lançado em março, se eu não me engano. Então, já eu comecei a usar logo no início e desde então eu uso ele

todo santo dia. E por que que eu tô falando isso para vocês? Tô falando para dizer que eu já testei de tudo. Se saiu um prompt, eu já testei. Se saiu método, eu já testei. Então, como eu tive a oportunidade de testar muito dessas coisas, eu fui vendo qual era o melhor. E esse é o melhor Workflow que eu usei até agora. Se por acaso eu descobrir algo melhor ainda nos próximos meses, eu vou vir aqui contar para vocês. Mas primeira coisa que eu faço é esse processo de pesquisa, tá? O que que é esse

processo de pesquisa? Eu basicamente começo, toda vez que eu preciso implementar alguma coisa, eu pego e falo pro cloud code assim: "Olha, eu preciso implementar tal coisa, tá?" E aí eu quero que você faça uma pesquisa primeiro na nossa base de código para Você identificar quais são os arquivos da nossa base de código que vão ser afetados com essa nossa nova implementação e eventualmente para você encontrar padrões de implementação de coisas similares que já tenham sido feitas antes pra gente poder reaproveitar essa mesma linha de raciocínio. Outra coisa, eu quero que você busque na internet

ã documentações de tecnologias que a gente vai usar aqui. E por fim, eu peço também pr ele Buscar padrões de implementação fora da minha base de código pr ele me trazer. Vou dar um exemplo até recente de uma coisa que eu fiz. Eu tinha uma implementação de autenticação, né, para fazer login, signup do meu usuário. Só que eu precisava implementar um processo onde se o usuário não logasse com o Gmail, eu tinha que mandar um e-mail para o e-mail que ele cadastrou na aplicação para ele confirmar que aquele e-mail realmente existe, tá? Então eu Preciso

implementar um sistema para confirmar as contas do meu usuário por e-mail. Beleza? Aí eu pedi para ele fazer uma pesquisa na minha base de código para identificar quais arquivos na minha base de código interfeririam nessa implementação, que basicamente eram os arquivos da minha feature de autenticação do usuário. Por exemplo, o meu próprio banco de dados, né, onde eu tenho minha tabela de usuários, que eu preciso agora colocar Uma coluna dizendo se aquele e-mail está autenticado ou não, true or false. Então eu pedi para ele procurar basicamente todos os arquivos que eram referentes a essa feature

de autenticação, porque eu sabia que isso influenciaria essa funcionalidade de confirmação de e-mail. Documentações, eu usei o o Nextth, né? Não sei se vocês já usaram, mas Nexout tem uma documentação. Então eu pedi para ele ler a documentação eh relevante, né? Não a documentação inteira, mas o trecho Relevante da documentação do next referente a essa parte. E aí, padrões de implementação, eu pedi para ele procurar na própria documentação do Next, porque realmente já tinha alguns trechos de código e eu pedi para ele copiar aquilo. Mas eu poderia, por exemplo, ter pedido para ele olhar no

Stack Overflow, que é uma coisa que eu já fiz muito, ou até mesmo buscar padrões no próprio GitHub. Tem até uma coisa que eu faço bastante, que é legal vocês saberem, que às vezes Eu pego um projeto do GitHub, que tem aquele padrão que eu quero, importo dentro do meu projeto numa pasta dot stamp, né? Então ela fica temporária e aí eu peço pro cloud code olhar essa pasta, entender aquele aquele padrão e me trazer e aí depois eu deleto aquela pasta. Então é uma maneira também que eu uso para puxar esses padrões de implementação.

Isso para mim é particularmente útil porque eu não sou desenvolvedora pessoal, então eu não eu Nunca vi aquele padrão na minha vida, certo? Então, se eu nunca vi um padrão comprovado, como que eu vou saber se o que ele fez é bom ou ruim, se eu não tenho nem referência do que é bom, né? Então, eu sempre prefiro buscar eh reples e buscar padrões de implementação que sejam documentados e comprovados, porque aí eu não preciso reinventar a roda e aí eu inclusive aprendo com quem sabe fazer, né? Então eu faço muito isso. E aí Depois

que ele lê todo esse monte de coisa, eu peço para ele me gerar um prd.md. Basicamente o que que é esse PRD.m? É um resumão de tudo o que ele achou na pesquisa dele, né? Então vai ter nesse PRD todos os arquivos da base de código que são relevantes para aquela implementação, só os que são relevantes, porque pode ser que durante a pesquisa ele encontre alguns arquivos que são inúteis para aquela implementação. Aí Isso não vai pro justamente pelo ponto que a gente falou anteriormente que informações inúteis não ajudam, né? Hã, vai também e trechos

das documentações que ele leu e que são importantes para essa implementação. E vai também codes nipets, né, que são os padrões de implementação que ele encontrou no ST Overflow, na minha base de código, etc., para fazer isso aqui funcionar. E aí depois que ele ele gera esse PRD, eu ã dou um clear, né? Então, se vocês não Estão familiarizados com o cloud code, se você colocar slash clear, ele vai limpar toda a janela de contexto. E aí você vai começar uma nova conversa do zero, porque aí olha o que acontece. Eu, entre aspas, faço o

onboarding desse outro chat aqui, que é o meu chat onde eu vou gerar spec com esse resumão aqui que ele me gerou. Então, o meu segundo pront, quando eu começo a parte de spec, eu basicamente falo para ele assim, ó, lê esse PRD. Nesse PRD ele vai est com Todo essa informação aqui que eu pedi e também vai ter a descrição do que eu quero fazer, né? Então eu vou falar assim: "Lê esse PRD e gera uma spec para mim". E aí o que que ele vai fazer quando ele tiver criando essa spec? Essa spec,

gente, é ela é bem tática. Ela basicamente vai falar para o agente exatamente quais são todos os arquivos à base de código que precisam ser alterados, todos os arquivos à base de código que precisam ser modificados e Tudo o que precisa ser criado ou modificado em cada um desses arquivos, eventualmente inclusive com os nípets de código ou pseudocódigos que eles vão pegar e implementar naqueles arquivos que eu apontei. Só que é muito importante que a sua spec siga muito esse padrão que é a o path, né, do arquivo que você quer modificar ou criar e

o que você quer criar ou modificar naquele arquivo, porque se você não deixar isso muito claro, ele vai Implementar do jeito dele e aí depois você vai falar que tá ruim. Então você precisa ser bem tático e bem específico, porque só assim ele vai mexer exatamente nos arquivos que você pediu. Com isso aqui eu vou gerar justamente esse spec. A spec como se fosse o prom de implementação que eu vou usar na terceira etapa. E aí o que eu faço? Esse spec basicamente é um resumão, né, de tudo aqui que eu que ele que ele

da pesquisa que ele aplicou na base de Código e gerou quais são os arquivos ali que precisam ser criados ou modificados. E aí sim eu uso essa spec como o prompt meu processo, que é a parte de aí sim implementar aquilo que eu quero fazer. Então aí sim eu peço para ele implementar aquela spec que eu gerei. Anexo ali a spec junta, né? Então aquilo compõe o meu prompt, só que aí eu deixo toda a janela de contexto ali livre para ele fazer a implementação usando o máximo da janela de contexto possível Que ele tem.

Porque aí se você fizer dessa forma, né? Ou seja, faz a pesquisa, resume os achados da sua pesquisa, aí limpa a janela de contexto, começa outra conversa. Usa o resumo da sua pesquisa como o input para você gerar sua spec. Gera sua spec, que é o resumo dessa desse raciocínio que ele fez. Aí você limpa sua janela de contexto de novo e aí você usa o resumão da sua spec como input na hora de você gerar o seu código. Você consegue Aproveitar muito melhor a sua janela de contexto, porque se você faz isso tudo em

uma conversa só, olha como fica essa janela de contexto. Você acaba usando ela inteira, né? E o que eu ouço geralmente é que é bom você trabalhar com 40 a 50% da sua janela de contexto no máximo. Então sempre que você vê que tá eh passando um pouco disso, limpa ela e começa de novo, dar um clear. para você não estourar a sua janela de contexto, né? Então essa foi a forma Mais efetiva que eu encontrei de fazer isso, pessoal. E só para lembrar vocês, se vocês quiserem ter acesso aos prontos que eu uso para

fazer essa pesquisa, o spec e a implementação, todos esses prontos estarão disponíveis gratuitamente na minha newsletter, que é a Deb GPT, a maior newsletter de construção de software com I do Brasil. Então, procura aqui na descrição do vídeo o link do meu substac e assina que é grátis e você vai adorar. E agora eu Vou tentar detalhar um pouquinho mais esse processo para vocês, tá? Então, quando a gente tá na fase de pesquisa, eh, qual que é o objetivo aqui, tá? Basicamente, eu quero buscar todo o contexto necessário paraa minha AI conseguir fazer uma implementação

efetiva. E pode ser que nesse momento venha também contexto desnecessário, contexto inútil, contexto errado, que foi até o que a gente falou no começo do vídeo, que isso atrapalha a performance Da sua LM. Só que nesse momento, como eu tô só fazendo uma pesquisa, tudo bem vir coisas que são inúteis, porque quando ele gerar o PRD, né, que é o resultado dessa pesquisa, só vai no PRD o que é realmente relevante. Então, quando ele passar essa bola para a próxima conversa, que é a conversa de spec, ali não vai lixo. Então isso aqui ele serve

como um grande funil, onde ele vai pegar todas as informações possíveis e ele vai filtrar só as informações que realmente Vão ser necessárias para implementar aquilo que você quer fazer. E aí nisso pode ser que venha arquivos da sua base de código que ele precisa ler para ele entender como as partes com as quais essa sua implementação vai ser integrada funciona. Uma coisa muito importante também para você jogar aí dentro da sua parte de pesquisa são documentações de coisas externas. Então, por exemplo, você vai implementar ã um sistema de envio de mails com resend. manda

a Documentação do resend, senão ele não vai saber como é que faz aquilo. Então é importante você colocar isso no nessa parte de de pesquisa também. E outra coisa que eu faço também é trazer padrões de implementação, porque como eu disse, como eu não sou engenheira, eu gosto de copiar padrões de outros engenheiros que já fizeram aquilo outras vezes. Assim eu não preciso ficar reinventando a roda e assim eu copio um padrão que eu sei que vai funcionar. E Aí ele vai fazer essa pesquisa inteira. dentro dessa pesquisa vai vir coisa útil, vai vir coisa

inútil, só que aí justamente no prompt a gente consegue filtrar eh o que é útil e o que é inútil e tá tudo certo. Ã, e aí ele vai gerar esse resultado, né, que é o PRD, que é basicamente um resumão de tudo que ele fez aqui. E eu vou limpar a minha conversa pra gente começar uma outra conversa só para fazer spec. Na hora de fazer spec, que que eu faço? Basicamente Eu entrego pro cloud code, faço uma referência, né, pro cloud code desse PR DMD que ele gerou, só que ele tá com a

janela de contexto limpo. Ele teoricamente não se lembra que ele fez isso. Então eu falo: "Ó, você escreveu isso aqui, dá uma lida e aí eu preciso que a partir disso que você leu, que você me diga exatamente qual arquivo da base de código a gente precisa modificar para fazer isso, qual arquivo a gente precisa criar, o que que a gente precisa Criar, o que que a gente precisa modificar em cada um desses arquivos. E muitas vezes eu gosto de incluir também code snipets, que são aqueles trechinhos de código para ele saber como que eu

quero fazer uma determinada coisa. Geralmente esses codes snipets vem justamente dessa pesquisa aqui, né, dos padrões de implementação. Então eu coloco aqui na spec, olha aquele arquivo, sei lá, o, por exemplo, o meu esquema, né, o arquivo que tá as tabelas Do meu banco de dados, eu preciso que você crie isso aqui, ó, essa tabela do banco de dados ou aquele arquivo, né, teste X, eu preciso que você use esse padrão aqui. Enfim, essa é uma maneira de você deixar bem claro pra IAI o que que você quer que ela faça, como que você quer

que ela faça, porque se você não disser novamente, ela vai fazer do jeito dela e aí pode ser que não seja o jeito que você quer e você vai acabar achando ruim e talvez realmente esteja. E aí, novamente, eu peço para ele gerar essa essa spec aqui, que é um resumão de todo esse trabalho de planejamento que ele fez. De novo, ele teve uma amnésia, né, porque eu limpei a janela de contexto dele e aí eu peço para ele implementar a specd. Então, a SPEC é como se fosse o prom de implementação, né, de fato,

onde vai ter todos os arquivos que ele precisa criar, todos os arquivos que ele precisa modificar. E isso é ótimo, porque aí a gente consegue De fato mostrar pra nossa LLM tudo que ela precisa fazer passo a passo. Então, a chance dela, putz, editar um arquivo que você não quer ou mudar algo errado, se você fizer desse jeito, é muito pequena. E eu diria que foi assim o melhor hack de produtividade que eu já aprendi desde que eu comecei a trabalhar com cloud code e foi assim literalmente a única maneira que eu realmente consegui fazer

as coisas funcionarem sem travar, sem eu precisar chorar. Realmente isso aí funcionou e é por isso que eu tô recomendando para vocês, porque eu acho que isso foi muito, muito bom pro meu workflow. E aí assim, se você fizer isso que eu falei para você, muito provavelmente o que que você vai sentir de resultado, tá? Primeira coisa, você vai ver que a II vai repetir menos código. Por quê? Porque quando você fizer a sua pesquisa, você já vai descobrir, por exemplo, que aquele aquele trecho de código já existe em Algum arquivo e que tudo que

ela precisa fazer é importar aquele trecho ao invés de reescrever ele de novo. Então, como você tá lembrando ela que aquele código já existe, adivinha? Ela não vai ter que repetir aquele negócio de novo. Outra coisa, você vai notar que as implementações que a IAI vai começar a fazer vão ser mais simples, né? Então ela tem muito esse hábito de fazer overengine engineer, só que quando você entrega pra Irões de código que você Pesquisou e que você sabe que funcionam e se funcionam, provavelmente é porque eles são mais simples também, eh ela vai começar a

implementar esse tipo de coisa com um pouco mais de simplicidade e isso é muito melhor para você dar manutenção. Só um parêntese aqui, né? Eu tem um livro do do Reed Hastings, né, que é o fundador do do Netflix, que ele fala que um desenvolvedor muito bom, ele outerformes. E no início, eu confesso que há muitos Anos atrás, quando eu não sabia como as pessoas programavam, eu pensava que o cara que programava 20 vezes melhor, ele, sei lá, ele ditava mais rápido, né? Mas na verdade, se você não é técnico, até para você entender, imagine

que você consegue escrever o mesmo código que faz a mesma coisa. E se você for um desenvolvedor muito bom, talvez você consiga fazer isso em 100 linhas. Se você for um desenvolvedor muito prolixo e talvez não tão um desenvolvedor não Tão bom, talvez você faça isso em 2000 linhas. Então o desenvolvedor ruim, mesmo que ele escreva na mesma velocidade do desenvolvedor bom, ele vai se forçar 20 vezes mais. ele vai demorar muito mais para escrever porque ele tá fazendo um negócio muito mais complicado, entende? Então, quanto mais simples, melhor, porque aí quando você tiver que

dar manutenção, imagina você ler 2.000 linhas de código versus 100 linhas de código, o que que você Preferiria dar manutenção? Na de 100, obviamente. E isso vai ser melhor para você, se você for desenvolvedor e você realmente edita o código e vai ser ótimo para a sua AI, porque adivinha? Isso vai consumir menos toquen. Então, se ela tiver que dar manutenção um arquivo de 2.000 linhas versus um 100, o de 2.000 linhas vai consumir muito mais token, vai demorar mais, enfim. Então, a gente não quer esse tipo de coisa. Mas eu só quis fazer esse

parênteses para dizer Que eh isso não é um problema eh exclusivo de AI, isso é um problema de todo mundo que escreve código. Basicamente outro ponto que você vai notar, as implementações vão ser mais assertivas, porque ã uma coisa que já aconteceu muito comigo é eu pedi para a IIAI fazer algum tipo de implementação ou integração com coisas externas, né, com dependências externas, só que aí ela não tinha o acesso à documentação, né? Eu achava que se ela não soubesse ela ia Pesquisar sozinha. Ela não vai pesquisar sozinha muitas vezes, tá? Então é muito importante

você passar esse essa documentação para ela. E quando você tem exatamente a documentação, a documentação vai explicar como é que faz para implementar, etc. é muito mais provável que o código funcione em one shot, porque justamente ela leu documentações e viu como é que faz aquilo. Logo, a chance dela acertar de primeira é muito maior. E por fim, vocês Também vão notar um código mais modularizado. Claro que isso depende da arquitetura que você usa, né? Porque a definição de modularização depende da arquitetura que você tem. Mas, ã, pelo menos aplicando, né, na na arquitetura que

eu uso, para quem já viu meus outros vídeos, sabe que eu gosto bastante desse tema. Então, quando você diz pra IAI exatamente qual arquivo que eu quero que você crie qual arquivo que eu quero que você modifique, a gente consegue Garantir nessa hora que a IAI tá criando arquivos certos e não, tipo, juntando um monte de código que tem responsabilidades diferentes no mesmo arquivo, importando coisas que já existe. Então, a gente consegue ter um código que é muito mais modularizado e fácil de dar manutenção, porque se você junta tudo realmente depois para você poder mexer

nisso ao inferno, e ninguém vai querer mexer nisso, eu posso te garantir. Bom, sem contar que você vai Conseguir fazer coisas muito mais rápidas, né? Porque uma coisa que às vezes nos dá uma uma impressão de velocidade falsa é que quando você começa vibe code, entre aspas, você começa a ter resultados muito muito muito rápidos, porque você não tem que pesquisar, planejar, etc. Em compensação, você logo vai bater na parede e você vai começar a travar justamente porque o seu código vai se bagunçar tão rapidamente que vai chegar Uma hora que ele vai ficar assim,

é impossível de mexer. Então, acho que usar esse processo, por mais que inicialmente ele pareça um pouco mais burocrático, só um parêntese, eu não acho que seja burocrático, tá? Porque eu venho de uma época onde você precisava de 15 engenheiros para começar uma empresa. Então, para mim isso aqui tá tranquilo. Mas ainda que ele pareça um pouco mais burocrático, no início você talvez tenha uma impressão de que você Tá indo mais devagar, mas você vai muito mais longe se você fizer desse jeito que eu tô explicando para vocês. Então, é basicamente assim que eu trabalho.

Eu recomendo muito que você teste esse método que eu expliquei para vocês. E mais uma vez, se você quiser ter acesso aos prontos que eu uso para fazer essa parte de pesquisa, de spec, de codes, todos eles estarão gratuitamente na minha newsletter. Então, se você ainda não assinou a meu newsletter, assina que Você tá perdendo tempo. Bom, e esse foi o fim de mais um vídeo no meu canal. Se você gostou desse vídeo, por favor, deixa o like aqui para eu saber se você gostou. Aproveita, comenta, me conta o que você achou, me diz se

você tem alguma dúvida. E se você ainda não se inscreveu no meu canal, para de perder tempo e se inscreve no meu canal, assim você ficar sabendo dos meus próximos vídeos, tá bom? Então, muito obrigada pela atenção de vocês e até a próxima. Fui. No vídeo de hoje, eu vou mostrar para vocês o workflow completo que eu uso para construir aplicações com o Cloud Code. E esse é exatamente o mesmo processo que eu usei para construir o Epic, que é o meu app que tá com mais de 3.000 usuários que eu lancei há 90 dias,

se eu não me engano, sem escrever uma linha de código. E se você acha que todo código gerado por ai não presta, eu vou te dizer que você pode estar certo ou Você pode estar errado, dependendo da maneira como você faz isso. Porque se você faz vibe coding, né, no sentido literal desse termo, que é basicamente você jogar um monte de promptatório e fazer uma oração torcendo para aquilo dar certo, eu acho que você tá certo. Eu acho que o código gerado por AI dessa forma não funciona mesmo. E eu não colocaria algo feito assim

em produção. Agora, se você tem um método para você conseguir explicar pra IAI exatamente o Que precisa ser feito, aí eu te garanto que a sua percepção vai ser bem diferente, como foi o meu caso, porque foi assim que eu consegui construir o appicc do começo ao fim, coisa que a maioria das pessoas que não tm um background de engenharia jamais conseguem fazer porque em algum momento elas vão travar. E eu não travei justamente porque eu aprendi esse método que realmente foi muito, muito útil nessa minha jornada. E essa metodologia Que eu uso, o pessoal

chama de spec driven developments, né? Então você tem o test driven developments, esse é o Spect Driven Developments, que eu vou abreviar de SDD, só para facilitar um pouco. E a maneira que eu faço isso é relativamente simples e ela consiste em três passos que são, primeiro, eu começo fazendo uma pesquisa na minha base de código existente, lendo documentações externas e buscando padrões de implementação que eu quero trazer para Dentro do meu projeto. Aí eu pego e gero o que eu chamo de prd.md. Aí depois eu passo paraa segunda etapa, que é escrever uma spec.

Então eu pego o output que eu tive nessa fase de pesquisa e gero uma spec que é basicamente um arquivo que diz todos os arquivos da base de código que precisam ser criados e todos os arquivos da base de código que precisam ser modificados e o que precisa ser criado ou modificado em cada arquivo. E aí por fim pego o Resultado disso que é o my spec.m e passo para a terceira etapa para enfim implementar esse plano da minha spec. Então é basicamente isso que eu faço. Agora eu vou explicar para vocês no detalhe, passo

a passo, tudo que eu faço para vocês conseguirem aplicar exatamente esse mesmo método no workflow de vocês. Só que antes da gente entrar no método, eu queria dar só um pouco de contexto para vocês, para vocês entenderem por que as pessoas acham que O código gerado por AI não presta. Bom, então eu vou compartilhar para vocês os problemas que eu tive, tá? Eh, não sei se tem mais algum aqui que eu que eu deixei de listar, mas se você por acaso observou algum outro padrão que eu deixei de listar aqui, por favor, deixa aqui nos

comentários que eu quero saber. O primeiro padrão bem comum é o que a gente chama de overengine engineering. Então, muitas vezes a II vai ter o hábito de complicar um negócio que Poderia ser muito muito simples. Esse é um padrão bem comum que eu já observei que eu tô falando do cloud code, tá? Mas isso se aplica a literalmente todos os modelos. Outro padrão bem comum é reinventar a roda. Então, muitas vezes já existe alguma coisa pronta e ele vai te induzir a criar algo novo. Vou dar um exemplo bem fácil de entender para vocês.

O appic tem o Markdown Editor, né, que é tipo esses como se fosse um Notion, sabe, onde você consegue anotar As suas coisas e e formatar ali o o texto bonitinho. E quando eu tava desenvolvendo isso no Epic, ele tentou me induzir a criar o Markdown Editor do Zero. Só que isso é um trabalho absurdo, né? Não sei se algum de vocês já tentou codar isso do zero, mas é realmente muito trabalhoso. Por sorte, eu tinha feito uma pesquisa antes e eu sabia que existiam algumas soluções prontas, como o Pros Mirror, por exemplo, e o

tip Tap, que eu acabei usando para fazer o appic. Daí eu não tive que criar um Markdown Editor do zero, então eu não tive que reinventar a roda, mas assim tô dizendo pr vocês que isso é um padrão que eu sei que acontece e é importante vocês ficarem de olho. Outro ponto, às vezes ele não sabe fazer o que você pediu. Então, por exemplo, você pediu para ele implementar alguma coisa com uma documentação que saiu em 2026, só que a base de corte do treinamento dele foi de 2024. Ele não vai saber implementar, né? Então,

ele vai fazer o melhor, mas possivelmente ele vai errar. Outra coisa comum, ele repete trechos de código que já existem na sua base de código. Então, dando um exemplo aqui fácil para todo mundo entender, você criou já um componente de botão, já existe um arquivinho de botão. Ele não se lembra que ele fez isso. Aí que ele faz, cria outro botão. E agora você tem que dar manutenção no botão um e no botão dois, ao invés de você dar manutenção em um Botão só, porque ele basicamente faz a mesma coisa. Então esse é um padrão

bem comum também e isso é um pesadelo de manutenção, porque você tem que ficar fazendo o dobro, triplo, quádruplo de manutenção por causa desse tipo de coisa. E outra coisa que eu já vi também é que muitas vezes ele acaba juntando códigos que fazem coisas diferentes, né, que tem responsabilidades diferentes dentro do mesmo arquivo. E isso também Torna o seu código um pesadelo de manutenção. Bom, então esses são os padrões que eu já vi que são muito comuns de acontecerem com a EI. E é esse tipo de coisa que faz aí travar no meio do

projeto, porque chega uma hora que esses débitos técnicos vão ficando tão grandes, mas tão grandes, mas tão grandes, que ela realmente não vai conseguir avançar. E o maior culpado de tudo isso é o que a gente chama de context window, né, que é a janela de Contexto do seu modelo. Então, só para ficar mais ilustrativo, para quem não tá familiarizado com esse termo, context window pensa que é tudo o que o modelo consegue se lembrar, digamos assim. E geralmente isso é medido em número de tokens, né? Então a gente vai falar: "Ah, 400.000 tokens, 200.000

tokens". Esse é o tanto de informação que o seu modelo consegue, entre aspas, se lembrar. E o token, só para vocês terem uma uma dimensão do que que é um token, Geralmente um token são quatro caracteres. Então, se a gente fala 200.000 tokens, a gente tá falando de 800.000 caracteres. Isso é tudo que a sua AI consegue se lembrar. Só que por que que esses probleminhas que eu relatei acontecem, né? Eh, quando a gente fala de desse padrão de overengine engineering, o que acontece? A sua talvez não saiba que existe uma forma mais simples de

fazer aquilo que ela tá fazendo. Por quê? Porque você não diz Para ela: "Isso não tá no context window dela." Por que que a IAI reinventa a roda? Porque às vezes ela não sabe que alguém já fez aquilo que ela tá tentando fazer. Por que que ela às vezes não sabe fazer alguma coisa ali quando você pede para ela implementar uma documentação externa? Porque às vezes ela não sabe que ela tem que ler uma documentação que talvez esteja mais atualizada do que conhecimento que ela tem. você também provavelmente não diz para ela, não Disse isso

para ela e não colocou isso na janela de contexto dela. Essa parte de repetir trechos de código é mais um problema clássico de context window, porque às vezes ela já fez, por exemplo, o botão que a gente deu de exemplo, já existe aquele botão, só que esse botão foi feito antes de estourar a janela de contexto dela. Então, como estourou, ela não se lembra daquele botão, porque aquele botão passou do montante de coisas que ela poderia se lembrar. E por Fim, esse padrão de juntar tudo no mesmo lugar. Eh, por que que isso acontece? Porque

você muitas vezes também não diz para ela, né? Não coloca isso na janela de contexto, a maneira como você quer separar os seus arquivos. E aí, se você juntar tudo isso aqui que eu disse para vocês, é assim que você produz um código muito muito ruim. É por isso que tem muitas pessoas que dizem que eh vibe coding não funciona. E de fato, como eu disse, vibe coding não funciona, mas Existe uma maneira de você conseguir endereçar cada um desses pontos e fazer a sua AI gerar um código que é muito mais confiável e muito

mais fácil de dar manutenção. Uma coisa que é muito importante a gente lembrar é que meio óbvio que eu tô falando aqui, né? Mas a qualidade do seu input determina a qualidade do seu output. Então, se faltou informação no seu input, se a informação que você colocou é ruim, se a informação que você colocou é errada, Provavelmente o que ela vai produzir ali é bem ruim, né? Porque a IAI é um multiplicador de coisas, entendeu? Eu costumo falar que ã quem transforma água em vinho é Jesus, né? A Iai não transforma uma coisa na outra,

ela multiplica o que você deu para ela. Então, se você alimentou a sua EAI com um monte de bosta, o que ela vai produzir também é um monte de bosta. e você não deveria ficar surpreso, né? Eu pelo menos não ficaria. Então assim, Para começar a gente precisa lembrar disso, que é uma coisa meio óbvia, mas eu vejo frequentemente as pessoas se esquecendo. Bom, e aí quando a gente diz que a qualidade do seu output é diretamente proporcional à qualidade do seu input, só para deixar um pouco mais claro no contexto de geração de código,

o que que acaba com a qualidade do seu input? Primeira coisa, informação incorreta, tá? Então, às vezes você pode colocar um prompt ali que está errado. Às vezes você pediu para alterar um arquivo que não é aquele arquivo que tem que ser alterado. Ou às vezes você do seu prompt não deixou claríssimo qual arquivo tem que ser alterado. E aí é óbvio que ela vai fazer bosta. Então, informação incorreta realmente é um problema que vai acabar com a qualidade do seu input. Outra coisa, informação incompleta. Então, por exemplo, se a gente voltar aqui que a

gente tava falando, eu não passei a documentação do Da biblioteca que eu tô usando. Ela não tem como adivinhar, né? Então, a informação incompleta vai fazer ela provavelmente implementar coisas erradas. Informações inúteis também não ajudam. Por quê? porque elas enchem a sua janela de contexto e elas não agregam em nada para o output, porque a talvez aquela informação não vá fazer ele produzir um output melhor ou pior, logo ele só tá enchendo a janela de contexto e confundindo a sua AI também. Isso acaba com a qualidade do seu input. E por fim, informações de mais.

Então, quanto mais informação você tiver e mais você encher a sua janela de contexto, pior vai ser a qualidade do seu output. Isso todo mundo fala, todos os pesquisadores. E eu, como testei muito isso, eu posso afirmar para vocês que isso é verdade. E aí, só para vocês entenderem o que que vai entrando na sua janela de contexto. Primeira coisa, você buscou um arquivo. Então, quando ele tem Que rodar comandos para ficar buscando os arquivos, ele vai escrever o comando para buscar, ele vai receber o retorno com todos os arquivos da sua base de código.

Tudo isso tá consumindo janela de contexto. Aí ele vai ler os arquivos que ele achou. não vai consumir de nada de contexto. Aí ele vai editar arquivo, vai consumir também. Aí ele vai eh eh escrever algum arquivo novo, vai consumir já de contexto também. Aí ele rodou um MCP. Eu não sei se vocês já Viram, mas quando você roda um MCP, a resposta do MCP é um Jason Blob enorme com um monte de informação. Isso consome essa janela de contexto também. E também os prontos que você manda pro seu coding assistant também vão consumir a

janela de contexto do mesmo jeito. E aí você vai somando, somando, somando, somando, somando e isso vai enchendo a sua janela de contexto. E geralmente quanto mais cheia a sua janela de contexto está, pior o seu resultado é, né? Isso é Claríssimo. Eh, acho que em todas as pesquisas que eu li isso fica claro. Eh, e como eu disse, testei para comprovar que isso é sim, verdade. Então, se isso é o que a gente não quer, o que que a gente quer? a gente quer alimentar a II com as informações necessárias para ela fazer uma

implementação, só que da forma mais resumida possível. Então assim, eu não posso ter informações incompletas, né? Eu preciso que todas as informações Estejam lá. Só que eu preciso fazer isso da forma mais resumida possível. Por quê? porque eu quero usar a menor parte possível da minha janela de contexto para deixar a maior parte possível da minha janela de contexto para que ela possa fazer a implementação do jeito certo. Então, dado essa introdução toda, como que eu faço isso na prática, tá? Eu vou explicar aqui um pouco para vocês. Bom, para vocês terem uma ideia, eu

comecei a usar o Cloud Codes em abril, Né? né? Então, faz quase 10 meses que eu tô usando ele. E ele foi lançado em março, se eu não me engano. Então, já eu comecei a usar logo no início e desde então eu uso ele todo santo dia. E por que que eu tô falando isso para vocês? Tô falando para dizer que eu já testei de tudo. Se saiu um prompt, eu já testei. Se saiu método, eu já testei. Então, como eu tive a oportunidade de testar muito dessas coisas, eu fui vendo qual era o melhor.

E esse é o melhor Workflow que eu usei até agora. Se por acaso eu descobrir algo melhor ainda nos próximos meses, eu vou vir aqui contar para vocês. Mas primeira coisa que eu faço é esse processo de pesquisa, tá? O que que é esse processo de pesquisa? Eu basicamente começo, toda vez que eu preciso implementar alguma coisa, eu pego e falo pro cloud code assim: "Olha, eu preciso implementar tal coisa, tá?" E aí eu quero que você faça uma pesquisa primeiro na nossa base de código para Você identificar quais são os arquivos da nossa base

de código que vão ser afetados com essa nossa nova implementação e eventualmente para você encontrar padrões de implementação de coisas similares que já tenham sido feitas antes pra gente poder reaproveitar essa mesma linha de raciocínio. Outra coisa, eu quero que você busque na internet ã documentações de tecnologias que a gente vai usar aqui. E por fim, eu peço também pr ele Buscar padrões de implementação fora da minha base de código pr ele me trazer. Vou dar um exemplo até recente de uma coisa que eu fiz. Eu tinha uma implementação de autenticação, né, para fazer login,

signup do meu usuário. Só que eu precisava implementar um processo onde se o usuário não logasse com o Gmail, eu tinha que mandar um e-mail para o e-mail que ele cadastrou na aplicação para ele confirmar que aquele e-mail realmente existe, tá? Então eu Preciso implementar um sistema para confirmar as contas do meu usuário por e-mail. Beleza? Aí eu pedi para ele fazer uma pesquisa na minha base de código para identificar quais arquivos na minha base de código interfeririam nessa implementação, que basicamente eram os arquivos da minha feature de autenticação do usuário. Por exemplo, o meu

próprio banco de dados, né, onde eu tenho minha tabela de usuários, que eu preciso agora colocar Uma coluna dizendo se aquele e-mail está autenticado ou não, true or false. Então eu pedi para ele procurar basicamente todos os arquivos que eram referentes a essa feature de autenticação, porque eu sabia que isso influenciaria essa funcionalidade de confirmação de e-mail. Documentações, eu usei o o Nextth, né? Não sei se vocês já usaram, mas Nexout tem uma documentação. Então eu pedi para ele ler a documentação eh relevante, né? Não a documentação inteira, mas o trecho Relevante da documentação do

next referente a essa parte. E aí, padrões de implementação, eu pedi para ele procurar na própria documentação do Next, porque realmente já tinha alguns trechos de código e eu pedi para ele copiar aquilo. Mas eu poderia, por exemplo, ter pedido para ele olhar no Stack Overflow, que é uma coisa que eu já fiz muito, ou até mesmo buscar padrões no próprio GitHub. Tem até uma coisa que eu faço bastante, que é legal vocês saberem, que às vezes Eu pego um projeto do GitHub, que tem aquele padrão que eu quero, importo dentro do meu projeto numa

pasta dot stamp, né? Então ela fica temporária e aí eu peço pro cloud code olhar essa pasta, entender aquele aquele padrão e me trazer e aí depois eu deleto aquela pasta. Então é uma maneira também que eu uso para puxar esses padrões de implementação. Isso para mim é particularmente útil porque eu não sou desenvolvedora pessoal, então eu não eu Nunca vi aquele padrão na minha vida, certo? Então, se eu nunca vi um padrão comprovado, como que eu vou saber se o que ele fez é bom ou ruim, se eu não tenho nem referência do que

é bom, né? Então, eu sempre prefiro buscar eh reples e buscar padrões de implementação que sejam documentados e comprovados, porque aí eu não preciso reinventar a roda e aí eu inclusive aprendo com quem sabe fazer, né? Então eu faço muito isso. E aí Depois que ele lê todo esse monte de coisa, eu peço para ele me gerar um prd.md. Basicamente o que que é esse PRD.m? É um resumão de tudo o que ele achou na pesquisa dele, né? Então vai ter nesse PRD todos os arquivos da base de código que são relevantes para aquela implementação,

só os que são relevantes, porque pode ser que durante a pesquisa ele encontre alguns arquivos que são inúteis para aquela implementação. Aí Isso não vai pro justamente pelo ponto que a gente falou anteriormente que informações inúteis não ajudam, né? Hã, vai também e trechos das documentações que ele leu e que são importantes para essa implementação. E vai também codes nipets, né, que são os padrões de implementação que ele encontrou no ST Overflow, na minha base de código, etc., para fazer isso aqui funcionar. E aí depois que ele ele gera esse PRD, eu ã dou um

clear, né? Então, se vocês não Estão familiarizados com o cloud code, se você colocar slash clear, ele vai limpar toda a janela de contexto. E aí você vai começar uma nova conversa do zero, porque aí olha o que acontece. Eu, entre aspas, faço o onboarding desse outro chat aqui, que é o meu chat onde eu vou gerar spec com esse resumão aqui que ele me gerou. Então, o meu segundo pront, quando eu começo a parte de spec, eu basicamente falo para ele assim, ó, lê esse PRD. Nesse PRD ele vai est com Todo essa informação

aqui que eu pedi e também vai ter a descrição do que eu quero fazer, né? Então eu vou falar assim: "Lê esse PRD e gera uma spec para mim". E aí o que que ele vai fazer quando ele tiver criando essa spec? Essa spec, gente, é ela é bem tática. Ela basicamente vai falar para o agente exatamente quais são todos os arquivos à base de código que precisam ser alterados, todos os arquivos à base de código que precisam ser modificados e Tudo o que precisa ser criado ou modificado em cada um desses arquivos, eventualmente inclusive

com os nípets de código ou pseudocódigos que eles vão pegar e implementar naqueles arquivos que eu apontei. Só que é muito importante que a sua spec siga muito esse padrão que é a o path, né, do arquivo que você quer modificar ou criar e o que você quer criar ou modificar naquele arquivo, porque se você não deixar isso muito claro, ele vai Implementar do jeito dele e aí depois você vai falar que tá ruim. Então você precisa ser bem tático e bem específico, porque só assim ele vai mexer exatamente nos arquivos que você pediu. Com

isso aqui eu vou gerar justamente esse spec. A spec como se fosse o prom de implementação que eu vou usar na terceira etapa. E aí o que eu faço? Esse spec basicamente é um resumão, né, de tudo aqui que eu que ele que ele da pesquisa que ele aplicou na base de Código e gerou quais são os arquivos ali que precisam ser criados ou modificados. E aí sim eu uso essa spec como o prompt meu processo, que é a parte de aí sim implementar aquilo que eu quero fazer. Então aí sim eu peço para ele

implementar aquela spec que eu gerei. Anexo ali a spec junta, né? Então aquilo compõe o meu prompt, só que aí eu deixo toda a janela de contexto ali livre para ele fazer a implementação usando o máximo da janela de contexto possível Que ele tem. Porque aí se você fizer dessa forma, né? Ou seja, faz a pesquisa, resume os achados da sua pesquisa, aí limpa a janela de contexto, começa outra conversa. Usa o resumo da sua pesquisa como o input para você gerar sua spec. Gera sua spec, que é o resumo dessa desse raciocínio que ele

fez. Aí você limpa sua janela de contexto de novo e aí você usa o resumão da sua spec como input na hora de você gerar o seu código. Você consegue Aproveitar muito melhor a sua janela de contexto, porque se você faz isso tudo em uma conversa só, olha como fica essa janela de contexto. Você acaba usando ela inteira, né? E o que eu ouço geralmente é que é bom você trabalhar com 40 a 50% da sua janela de contexto no máximo. Então sempre que você vê que tá eh passando um pouco disso, limpa ela e

começa de novo, dar um clear. para você não estourar a sua janela de contexto, né? Então essa foi a forma Mais efetiva que eu encontrei de fazer isso, pessoal. E só para lembrar vocês, se vocês quiserem ter acesso aos prontos que eu uso para fazer essa pesquisa, o spec e a implementação, todos esses prontos estarão disponíveis gratuitamente na minha newsletter, que é a Deb GPT, a maior newsletter de construção de software com I do Brasil. Então, procura aqui na descrição do vídeo o link do meu substac e assina que é grátis e você vai adorar.

E agora eu Vou tentar detalhar um pouquinho mais esse processo para vocês, tá? Então, quando a gente tá na fase de pesquisa, eh, qual que é o objetivo aqui, tá? Basicamente, eu quero buscar todo o contexto necessário paraa minha AI conseguir fazer uma implementação efetiva. E pode ser que nesse momento venha também contexto desnecessário, contexto inútil, contexto errado, que foi até o que a gente falou no começo do vídeo, que isso atrapalha a performance Da sua LM. Só que nesse momento, como eu tô só fazendo uma pesquisa, tudo bem vir coisas que são inúteis, porque

quando ele gerar o PRD, né, que é o resultado dessa pesquisa, só vai no PRD o que é realmente relevante. Então, quando ele passar essa bola para a próxima conversa, que é a conversa de spec, ali não vai lixo. Então isso aqui ele serve como um grande funil, onde ele vai pegar todas as informações possíveis e ele vai filtrar só as informações que realmente Vão ser necessárias para implementar aquilo que você quer fazer. E aí nisso pode ser que venha arquivos da sua base de código que ele precisa ler para ele entender como as partes

com as quais essa sua implementação vai ser integrada funciona. Uma coisa muito importante também para você jogar aí dentro da sua parte de pesquisa são documentações de coisas externas. Então, por exemplo, você vai implementar ã um sistema de envio de mails com resend. manda a Documentação do resend, senão ele não vai saber como é que faz aquilo. Então é importante você colocar isso no nessa parte de de pesquisa também. E outra coisa que eu faço também é trazer padrões de implementação, porque como eu disse, como eu não sou engenheira, eu gosto de copiar padrões de

outros engenheiros que já fizeram aquilo outras vezes. Assim eu não preciso ficar reinventando a roda e assim eu copio um padrão que eu sei que vai funcionar. E Aí ele vai fazer essa pesquisa inteira. dentro dessa pesquisa vai vir coisa útil, vai vir coisa inútil, só que aí justamente no prompt a gente consegue filtrar eh o que é útil e o que é inútil e tá tudo certo. Ã, e aí ele vai gerar esse resultado, né, que é o PRD, que é basicamente um resumão de tudo que ele fez aqui. E eu vou limpar a

minha conversa pra gente começar uma outra conversa só para fazer spec. Na hora de fazer spec, que que eu faço? Basicamente Eu entrego pro cloud code, faço uma referência, né, pro cloud code desse PR DMD que ele gerou, só que ele tá com a janela de contexto limpo. Ele teoricamente não se lembra que ele fez isso. Então eu falo: "Ó, você escreveu isso aqui, dá uma lida e aí eu preciso que a partir disso que você leu, que você me diga exatamente qual arquivo da base de código a gente precisa modificar para fazer isso, qual

arquivo a gente precisa criar, o que que a gente precisa Criar, o que que a gente precisa modificar em cada um desses arquivos. E muitas vezes eu gosto de incluir também code snipets, que são aqueles trechinhos de código para ele saber como que eu quero fazer uma determinada coisa. Geralmente esses codes snipets vem justamente dessa pesquisa aqui, né, dos padrões de implementação. Então eu coloco aqui na spec, olha aquele arquivo, sei lá, o, por exemplo, o meu esquema, né, o arquivo que tá as tabelas Do meu banco de dados, eu preciso que você crie isso

aqui, ó, essa tabela do banco de dados ou aquele arquivo, né, teste X, eu preciso que você use esse padrão aqui. Enfim, essa é uma maneira de você deixar bem claro pra IAI o que que você quer que ela faça, como que você quer que ela faça, porque se você não disser novamente, ela vai fazer do jeito dela e aí pode ser que não seja o jeito que você quer e você vai acabar achando ruim e talvez realmente esteja. E aí, novamente, eu peço para ele gerar essa essa spec aqui, que é um resumão de

todo esse trabalho de planejamento que ele fez. De novo, ele teve uma amnésia, né, porque eu limpei a janela de contexto dele e aí eu peço para ele implementar a specd. Então, a SPEC é como se fosse o prom de implementação, né, de fato, onde vai ter todos os arquivos que ele precisa criar, todos os arquivos que ele precisa modificar. E isso é ótimo, porque aí a gente consegue De fato mostrar pra nossa LLM tudo que ela precisa fazer passo a passo. Então, a chance dela, putz, editar um arquivo que você não quer ou mudar

algo errado, se você fizer desse jeito, é muito pequena. E eu diria que foi assim o melhor hack de produtividade que eu já aprendi desde que eu comecei a trabalhar com cloud code e foi assim literalmente a única maneira que eu realmente consegui fazer as coisas funcionarem sem travar, sem eu precisar chorar. Realmente isso aí funcionou e é por isso que eu tô recomendando para vocês, porque eu acho que isso foi muito, muito bom pro meu workflow. E aí assim, se você fizer isso que eu falei para você, muito provavelmente o que que você vai

sentir de resultado, tá? Primeira coisa, você vai ver que a II vai repetir menos código. Por quê? Porque quando você fizer a sua pesquisa, você já vai descobrir, por exemplo, que aquele aquele trecho de código já existe em Algum arquivo e que tudo que ela precisa fazer é importar aquele trecho ao invés de reescrever ele de novo. Então, como você tá lembrando ela que aquele código já existe, adivinha? Ela não vai ter que repetir aquele negócio de novo. Outra coisa, você vai notar que as implementações que a IAI vai começar a fazer vão ser mais

simples, né? Então ela tem muito esse hábito de fazer overengine engineer, só que quando você entrega pra Irões de código que você Pesquisou e que você sabe que funcionam e se funcionam, provavelmente é porque eles são mais simples também, eh ela vai começar a implementar esse tipo de coisa com um pouco mais de simplicidade e isso é muito melhor para você dar manutenção. Só um parêntese aqui, né? Eu tem um livro do do Reed Hastings, né, que é o fundador do do Netflix, que ele fala que um desenvolvedor muito bom, ele outerformes. E no início,

eu confesso que há muitos Anos atrás, quando eu não sabia como as pessoas programavam, eu pensava que o cara que programava 20 vezes melhor, ele, sei lá, ele ditava mais rápido, né? Mas na verdade, se você não é técnico, até para você entender, imagine que você consegue escrever o mesmo código que faz a mesma coisa. E se você for um desenvolvedor muito bom, talvez você consiga fazer isso em 100 linhas. Se você for um desenvolvedor muito prolixo e talvez não tão um desenvolvedor não Tão bom, talvez você faça isso em 2000 linhas. Então o desenvolvedor

ruim, mesmo que ele escreva na mesma velocidade do desenvolvedor bom, ele vai se forçar 20 vezes mais. ele vai demorar muito mais para escrever porque ele tá fazendo um negócio muito mais complicado, entende? Então, quanto mais simples, melhor, porque aí quando você tiver que dar manutenção, imagina você ler 2.000 linhas de código versus 100 linhas de código, o que que você Preferiria dar manutenção? Na de 100, obviamente. E isso vai ser melhor para você, se você for desenvolvedor e você realmente edita o código e vai ser ótimo para a sua AI, porque adivinha? Isso vai

consumir menos toquen. Então, se ela tiver que dar manutenção um arquivo de 2.000 linhas versus um 100, o de 2.000 linhas vai consumir muito mais token, vai demorar mais, enfim. Então, a gente não quer esse tipo de coisa. Mas eu só quis fazer esse parênteses para dizer Que eh isso não é um problema eh exclusivo de AI, isso é um problema de todo mundo que escreve código. Basicamente outro ponto que você vai notar, as implementações vão ser mais assertivas, porque ã uma coisa que já aconteceu muito comigo é eu pedi para a IIAI fazer algum

tipo de implementação ou integração com coisas externas, né, com dependências externas, só que aí ela não tinha o acesso à documentação, né? Eu achava que se ela não soubesse ela ia Pesquisar sozinha. Ela não vai pesquisar sozinha muitas vezes, tá? Então é muito importante você passar esse essa documentação para ela. E quando você tem exatamente a documentação, a documentação vai explicar como é que faz para implementar, etc. é muito mais provável que o código funcione em one shot, porque justamente ela leu documentações e viu como é que faz aquilo. Logo, a chance dela acertar de

primeira é muito maior. E por fim, vocês Também vão notar um código mais modularizado. Claro que isso depende da arquitetura que você usa, né? Porque a definição de modularização depende da arquitetura que você tem. Mas, ã, pelo menos aplicando, né, na na arquitetura que eu uso, para quem já viu meus outros vídeos, sabe que eu gosto bastante desse tema. Então, quando você diz pra IAI exatamente qual arquivo que eu quero que você crie qual arquivo que eu quero que você modifique, a gente consegue Garantir nessa hora que a IAI tá criando arquivos certos e não,

tipo, juntando um monte de código que tem responsabilidades diferentes no mesmo arquivo, importando coisas que já existe. Então, a gente consegue ter um código que é muito mais modularizado e fácil de dar manutenção, porque se você junta tudo realmente depois para você poder mexer nisso ao inferno, e ninguém vai querer mexer nisso, eu posso te garantir. Bom, sem contar que você vai Conseguir fazer coisas muito mais rápidas, né? Porque uma coisa que às vezes nos dá uma uma impressão de velocidade falsa é que quando você começa vibe code, entre aspas, você começa a ter resultados

muito muito muito rápidos, porque você não tem que pesquisar, planejar, etc. Em compensação, você logo vai bater na parede e você vai começar a travar justamente porque o seu código vai se bagunçar tão rapidamente que vai chegar Uma hora que ele vai ficar assim, é impossível de mexer. Então, acho que usar esse processo, por mais que inicialmente ele pareça um pouco mais burocrático, só um parêntese, eu não acho que seja burocrático, tá? Porque eu venho de uma época onde você precisava de 15 engenheiros para começar uma empresa. Então, para mim isso aqui tá tranquilo. Mas

ainda que ele pareça um pouco mais burocrático, no início você talvez tenha uma impressão de que você Tá indo mais devagar, mas você vai muito mais longe se você fizer desse jeito que eu tô explicando para vocês. Então, é basicamente assim que eu trabalho. Eu recomendo muito que você teste esse método que eu expliquei para vocês. E mais uma vez, se você quiser ter acesso aos prontos que eu uso para fazer essa parte de pesquisa, de spec, de codes, todos eles estarão gratuitamente na minha newsletter. Então, se você ainda não assinou a meu newsletter, assina

que Você tá perdendo tempo. Bom, e esse foi o fim de mais um vídeo no meu canal. Se você gostou desse vídeo, por favor, deixa o like aqui para eu saber se você gostou. Aproveita, comenta, me conta o que você achou, me diz se você tem alguma dúvida. E se você ainda não se inscreveu no meu canal, para de perder tempo e se inscreve no meu canal, assim você ficar sabendo dos meus próximos vídeos, tá bom? Então, muito obrigada pela atenção de vocês e até a próxima. Fui.