00:00:00Todo mundo sabe que é preciso um framework para trabalhar com agentes de codificação, mas pouca gente
00:00:04tem um que seja simples, realmente seu, e que possa evoluir com o tempo. Agora, existem
00:00:09muitos frameworks super-complexos por aí no GitHub. Todos esses sistemas multiagentes que
00:00:15as pessoas estão criando, eu respeito o trabalho delas, mas muitas vezes você só precisa de algo
00:00:19realmente simples que resolva o problema. Porque eu sei que você tem boas ideias que
00:00:24quer construir, e não quer gastar mais tempo criando fluxos de agentes do que
00:00:29codificando de fato, e é isso que eu tenho para você agora. Este é o meu framework "simples ao extremo"
00:00:35que eu uso toda vez que começo um projeto novo com meu agente de código. Agora, o
00:00:40desenvolvimento "Brownfield", trabalhar em uma base de código existente, é um pouco diferente. Fica para outro vídeo. Este,
00:00:45foca em desenvolvimento "Greenfield". Queremos um framework simples para começar do zero
00:00:50o mais rápido possível, construindo algo novo, e tudo o que estou cobrindo aqui é universal.
00:00:56Estes princípios se aplicam não importa qual agente de codificação você use. Então, há
00:01:00duas partes neste vídeo, e eu vou fazer uma construção ao vivo com você enquanto explico tudo
00:01:05aqui para tornar as coisas bem concretas. E o que eu tenho agora na minha base de código não é quase nada
00:01:11além da minha camada de IA. Trouxe alguns comandos e habilidades. Isso é o que eu uso como
00:01:16ponto de partida em cada um dos meus projetos. Vamos criar algo do zero,
00:01:21então precisamos começar com o planejamento inicial, criando o que chamamos de PRD. Este é o
00:01:27escopo inicial de trabalho para criarmos o produto mínimo viável (MVP) do nosso aplicativo. E há
00:01:32muito o que fazer aqui, configurando nossa camada inicial de IA antes de entrar na codificação real.
00:01:37Depois, pegamos o PRD e o dividimos em fases de trabalho, e vamos executá-las
00:01:43com loops PIV. Vou explicar o que isso significa, veremos um exemplo e então,
00:01:47enquanto passo pela implementação, cobrirei as quatro regras de ouro que queremos
00:01:52seguir sempre. Essas regras se encaixarão naturalmente enquanto eu crio
00:01:57o PRD, a camada de IA e faço um loop PIV. Por exemplo, o gerenciamento de contexto.
00:02:03O contexto é o seu recurso mais precioso ao trabalhar com assistentes de IA. Esse será um
00:02:08grande tema recorrente. Além disso, criar comandos e habilidades para tudo e a mentalidade de evolução do sistema,
00:02:14porque o que buscamos com o nosso sistema é criar algo que seja confiável e
00:02:18repetível. Vou falar sobre isso enquanto passo por tudo. Só estou destacando alguns
00:02:23dos temas centrais que vocês verão. Vai ser um vídeo com muito conteúdo. Então,
00:02:28começaremos aqui com o planejamento inicial, criando o que eu gosto de chamar de camada de IA. Vou explicar
00:02:34o que é isso e vamos construir juntos agora. Sua camada de IA são todos os ativos na sua base
00:02:39de código que você criou para servir de contexto para o seu agente. Como o seu PRD. O que vamos construir?
00:02:45Suas regras globais. Como vamos construir? Os comandos. Assim, temos fluxos reutilizáveis para
00:02:50nosso agente de codificação. Focaremos no principal primeiro. E também subagentes. Para podermos delegar
00:02:55pesquisas. Geralmente, como eu trabalho com a minha camada de IA, e eu tenho isso como um recurso para vocês,
00:03:01é que eu tenho um conjunto genérico de comandos que eu levo para qualquer projeto novo. E o ponto
00:03:07disso é que, conforme minha base de código cresce e eu a desenvolvo, eu também evoluo meus comandos para torná-los
00:03:13mais poderosos para o caso de uso específico, tornando-os mais sob medida para o meu código. E essa
00:03:18é a minha recomendação geral para vocês. Usem isso como ponto de partida se quiserem. Vou deixar
00:03:23o link do repo no GitHub na descrição. O motivo de manter isso tão simples é que você
00:03:27pode pegá-lo para si e evoluí-lo facilmente para o seu caso de uso e para o seu jeito de trabalhar. É por isso
00:03:33que eu recomendo algo assim em vez de um framework complexo como o Beemad ou o GitHub spec kit.
00:03:38Eles são muito poderosos, mas é difícil torná-los realmente seus. Eu quero que você consiga
00:03:42personalizar isso. Então, agora vou mostrar como criar um PRD inteiro. Definir as
00:03:48regras iniciais para nossa base de código. Vamos até customizar um pouco nosso primeiro comando. E depois
00:03:52falarei sobre subagentes ao longo do processo. Eu sei que estamos planejando muito antes de escrever
00:03:57qualquer código real com os loops PIV, mas é importante fazer isso. Planejar antecipadamente
00:04:03pode parecer que estamos indo devagar demais, mas se criarmos um plano realmente bom, com boas
00:04:07regras e um bom PRD, significa que todo o desenvolvimento posterior será muito mais rápido
00:04:13e confiável. Então, vamos começar com o PRD. Muita gente chama isso de especificação. Novamente, é apenas
00:04:18todo o escopo de trabalho para construir a versão inicial do nosso aplicativo. E, a partir desse
00:04:24ponto, quando tivermos uma boa base, a coisa muda para desenvolvimento brownfield. Esse é o próximo
00:04:28vídeo que estou preparando. Então, fiquem ligados. O que eu vou fazer aqui com o Claude Code,
00:04:34eu tenho um projeto basicamente vazio, exceto pela camada de IA, é ter uma conversa casual
00:04:40primeiro. Apenas contando minha ideia, talvez algumas ideias que tenho para a stack tecnológica e
00:04:45arquitetura. Você começa de forma bem desestruturada, o que também facilita o início.
00:04:50Aí, você chega ao ponto de usar a conversa como contexto para criar
00:04:55um PRD estruturado. Eu tenho um comando que nos ajudará nisso. Falarei sobre ele quando
00:05:01chegarmos lá, mas primeiro vamos começar com a nossa ideia. O que eu quero construir apenas como um
00:05:06exemplo divertido para este vídeo é algo tipo um Linktree, mas uma versão auto-hospedada
00:05:12onde você pode configurar sua própria landing page com vários links organizados.
00:05:16Teria análises como a taxa de cliques nos diferentes links. Quero construir algo
00:05:20assim. É um bom exemplo para agora porque não é super trivial a ponto de você
00:05:24conseguir codificar só no "feeling" com os recursos legais que podemos adicionar, mas também
00:05:29não vai ser excessivamente complicado a ponto de não termos quase nada ao final do vídeo.
00:05:33Vou usar uma ferramenta de voz para texto para facilitar as coisas aqui. Recomendo muito o uso
00:05:39de algo como o Aqua Voice. É o que eu uso. Existem muitas boas opções gratuitas e de código aberto também.
00:05:43Whisper Flow, Epicenter Whispering, ótimas ferramentas, mas eu amo usar voz para
00:05:48texto porque, garanto a você, eu nunca conseguiria digitar 226 palavras por minuto. Então,
00:05:54vou usar uma ferramenta assim só para despejar as ideias iniciais do que eu quero construir. E isso
00:05:59vai ser bem bruto, mas vou fazer esse despejo de ideias ao vivo para você agora, e preste
00:06:03atenção no que eu peço para o Claude Code fazer por mim, porque isso é tão importante quanto as ideias
00:06:09que estou compartilhando. Vou explicar um pouco sobre isso depois também. E, a propósito, você pode fazer
00:06:13tudo isso com qualquer assistente de IA. Então, vamos lá. Quero construir um criador de páginas de links na bio.
00:06:20Tipo um Linktree, onde os usuários criam uma conta. Eles podem criar sua própria
00:06:24landing page onde especificam os links. Podem mudar a ordem. Quero que eles tenham
00:06:29análises para ver as taxas de cliques nos links também. E podem customizar o
00:06:33tema. Para a stack, estou pensando em algo como Next.js, gostaria de usar Neon para
00:06:37meu banco de dados e autenticação Neon. Então, com certeza peça para um subagente pesquisar
00:06:43sobre isso. E para a arquitetura, não sou super exigente. Quero as suas recomendações
00:06:48para isso. E também sobre como vamos lidar com a tematização e a construção dos links, tudo isso. E
00:06:55eu quero que você também use um agente para pesquisar na web as melhores práticas para
00:07:00criar esse tipo de aplicativo estilo Linktree. E depois quero que você volte para mim
00:07:04com uma série de perguntas para que possamos alinhar até os pequenos detalhes do que estamos
00:07:10construindo aqui. Certo, muito bem. Vou enviar isso e a transcrição será feita
00:07:14em alguns segundos. Pronto, e já começamos com tudo. E a coisa mais importante
00:07:20que eu fiz ali foi bem no final, quando eu disse para ele me fazer um monte de perguntas
00:07:25depois de terminar a pesquisa. Isso é realmente importante de enfatizar aqui. Seu objetivo número um
00:07:32em qualquer planejamento com agentes de codificação é reduzir o número de suposições que seu agente
00:07:37está fazendo. Porque, no fim das contas, quando um agente comete um erro na sua base de código, metade
00:07:42das vezes não é que o código seja ruim, é que vocês não estavam alinhados sobre o que exatamente deveria ser
00:07:48construído. O ditado comum é que uma linha de código ruim é apenas uma linha de código ruim. Uma linha de um
00:07:54plano ruim pode gerar cem linhas de código ruim. Mas uma linha ruim em um PRD pode resultar em mil
00:08:02linhas de código ruins por causa do desalinhamento. Eu tenho feito muitos experimentos
00:08:08com formas de reduzir suposições ao longo do tempo. E fazer o agente de codificação realmente
00:08:13me mandar uma enxurrada de perguntas tem funcionado incrivelmente bem para mim. Especialmente
00:08:17o Claude Code, com sua ferramenta de perguntas ao usuário, onde ele pode dar múltipla escolha ou deixar você escrever a resposta.
00:08:23Veremos isso em um segundo. É muito poderoso. Eles fazem um ótimo trabalho pensando em todos os casos
00:08:28extremos e pequenos detalhes que talvez a gente nem esteja considerando. É difícil para nós raciocinarmos
00:08:33sozinhos sobre quais suposições o agente pode fazer. Então é muito, muito poderoso. E
00:08:38a outra coisa que eu fiz, como podem ver aqui, é que temos diferentes subagentes
00:08:42rodando para a pesquisa. Eu amo usar subagentes para qualquer tipo de planejamento, criando o PRD,
00:08:48ou até para o processo de planejamento dos loops PIV que falaremos daqui a pouco. No caso do
00:08:53Claude Code, eu não preciso criar meus próprios subagentes porque as funções de exploração e
00:08:59pesquisa já estão integradas na ferramenta. Para outros agentes, você talvez tenha que criar
00:09:04os seus, por isso quis mencionar aqui. Mas praticamente todo bom agente de codificação
00:09:08hoje em dia suporta a ideia de subagentes. E eu adoro usá-los para pesquisa. O motivo
00:09:14disso é o isolamento de contexto. Novamente, um dos temas principais aqui é que queremos proteger muito o
00:09:20contexto do nosso agente principal. E a razão pela qual a pesquisa é um caso de uso tão bom para subagentes
00:09:26é que, quando eles exploram, eles olham para tudo. Estão explorando a base de código ou pesquisando na web.
00:09:32Estão carregando dezenas, até centenas de milhares de tokens no seu trabalho.
00:09:36Mas, na verdade, tudo o que nos importa são as descobertas deles, o resumo final
00:09:41que eles retornam ao nosso contexto principal. Assim, mantemos nosso contexto principal limpo. Não recomendo
00:09:46usar subagentes para a implementação porque, nela, geralmente nos importamos com todo o
00:09:51contexto dos arquivos que editamos e criamos. Caso contrário, isso leva a muitas alucinações,
00:09:57pela minha experiência. É por isso que o Claude Code não tem agentes integrados para implementação.
00:10:01É só para pesquisa. E é exatamente o que estamos vendo aqui. Vou deixar
00:10:06tudo terminar e volto quando ele tiver as perguntas para nós. Certo, toda a pesquisa do
00:10:12subagente terminou e agora temos o conjunto inicial de perguntas para responder. Conforme eu
00:10:17passo por isso, acho que vocês vão gostar tanto quanto eu, porque estamos esclarecendo um monte
00:10:22de coisas. Cada pergunta que respondemos aqui está removendo uma suposição do agente de
00:10:26codificação. E como é múltipla escolha e geralmente uma das opções sugeridas é boa, podemos
00:10:31passar por isso rapidinho. Assim, podemos ir para a implementação confiantes de que
00:10:36temos todos os detalhes definidos. Por exemplo, como deve ser a estrutura da URL da página pública?
00:10:41Eu gostei da opção número um aqui, e pronto, próxima. Quantas páginas
00:10:46cada usuário deve poder criar? Vamos deixar uma página por usuário. Em alguns casos, vou
00:10:50manter os padrões, mas há muitas instâncias onde ele realmente entende algo errado
00:10:54de forma fundamental, e é aí que eu digito minha própria resposta para esclarecer. Não sei
00:10:59se encontrarei um exemplo aqui agora, mas o que vou fazer é passar por
00:11:03todas as perguntas e responder. Volto quando terminar. Vocês não precisam me ver respondendo cada
00:11:07uma das perguntas porque podem ser umas 20 ou 25. Ele leva isso bem a sério.
00:11:14Novamente, é preciso ter um pouco de paciência, mas cada pergunta respondida pode
00:11:19poupar você de centenas de linhas de código ruins. Na verdade, aqui está um bom exemplo onde eu quero
00:11:24esclarecer algo totalmente diferente do sugerido. Ele está perguntando — este é o segundo
00:11:30pacote de perguntas do Claude, aliás — se o editor de links deve ter uma visualização em um frame de celular?
00:11:35Tipo o Lovable ou Bolt.new, onde você vê o que está criando e
00:11:39tem o construtor à esquerda, ou se deve ser em linha? Eu quero ter
00:11:44as duas opções aqui. Então posso conversar com ele sobre isso. Ele vai me fazer as outras perguntas
00:11:49depois, mas agora temos uma pequena conversa sobre esse ponto específico. Eu
00:11:53diria aqui: quero ter um editor em linha, mas quero a opção de poder ver
00:11:58a prévia também. Basicamente, quero ter três botões: um para ver só o editor, um
00:12:03para ver ambos e um para ver só a prévia. Envio isso, ele voltará
00:12:08com mais perguntas e eu continuarei o processo. Aqui estamos. O Claude terminou de me fazer
00:12:13um monte de perguntas, provavelmente mais do que o necessário, mas você pode ajustar isso como quiser.
00:12:18Agora é hora de criar nosso PRD porque, como podem ver no resumo final das especificações,
00:12:23ele realmente tem uma compreensão clara do que exatamente vamos construir,
00:12:28até mesmo onde vou fazer o deploy. Vou fazer o deploy na Vercel depois de construir.
00:12:31Isso é fantástico. Sinto que ele não está mais presumindo quase nada. Então o que vou fazer agora
00:12:36é rodar meu comando create PRD. Vou salvar em .claude/prd.md. Você pode colocar
00:12:43onde quiser, e chamar do que quiser. Estou usando o comando que
00:12:47mencionei antes porque, voltando às nossas quatro regras de ouro, uma das principais
00:12:53é "comandarizar" tudo. Se você faz algo mais de duas vezes — e eu já comecei
00:12:59vários projetos — você deve criar um comando. Ou então uma "habilidade" (skill),
00:13:03já que o Claude Code fundiu comandos com habilidades recentemente, mas eu ainda gosto da distinção de que
00:13:10comandos são coisas que você invoca, como /commit. E habilidades são quando o agente
00:13:15decide ler o contexto, tipo entender como fazer algo novo. Estou criando um comando
00:13:20aqui porque decidi que, neste ponto da conversa, quero rodar esse comando para
00:13:27gerar um PRD estruturado. Como parte deste comando, estou dando a estrutura exata,
00:13:32todas as seções que eu quero no PRD. Assim, torno todo o meu processo repetível,
00:13:38certo? Uma grande parte deste sistema que estou mostrando é que você pode criar algo que funcione
00:13:42para você e depois repetir várias vezes para novos recursos e bases de código.
00:13:48Vou dar um /create PRD, deixar rodar e volto quando tivermos
00:13:53nosso PRD final. Pronto, nosso PRD foi criado e está bem completo, mas isso é bom
00:14:00porque não vamos simplesmente mandar tudo isso para o agente implementar de uma vez. Em vez disso,
00:14:04vamos construir as coisas em fases descritas pelo PRD. Não vou fazer
00:14:09muita validação na frente da câmera agora, não valeria o seu tempo, mas quero dizer que
00:14:14é importante ler tudo e garantir que vocês estão realmente alinhados. Caso contrário,
00:14:18isso levará a muito código ruim no futuro. A primeira coisa que quero destacar
00:14:22rapidamente aqui é que temos nosso escopo do MVP e nele podemos ver todas as nossas perguntas ganhando vida
00:14:29no PRD. Isso é importante porque a conversa que acabamos de ter foi apenas um contexto
00:14:34não estruturado para alimentar o PRD. O PRD é a única coisa que vai sobreviver. Precisamos garantir
00:14:40que toda a conversa com o agente esteja de fato aqui. Temos o que está
00:14:44fora do escopo, que é tão importante quanto o que queremos construir agora. Temos toda a
00:14:49estrutura de diretórios. Ele já entende geralmente o que vai na nossa base de código,
00:14:53o que é bom porque já estabelecemos nossa stack e arquitetura. E o mais importante
00:14:58disso é que temos nossas fases de trabalho. A partir disso, quando usamos nosso comando principal
00:15:04que falaremos daqui a pouco, conseguimos estabelecer: ok, o que já construímos
00:15:09na nossa base de código? O que precisamos construir a seguir baseado no PRD? Isso será
00:15:13uma peça importante de contexto no início de cada conversa enquanto construímos nosso MVP. E
00:15:19a propósito, aqui está a seção onde eu defino as fases. Cada uma delas será uma
00:15:24implementação granular, um de nossos loops PIV. Construímos a base, depois o gerenciamento de links.
00:15:29Depois fazemos o tema e vamos planejar cada um individualmente. Assim, nunca tentamos
00:15:33fazer com que o agente de codificação faça demais de uma vez só. Certo. Acabamos de criar nosso PRD e isso
00:15:38é realmente o passo principal. Estamos quase lá para a primeira implementação. A próxima coisa que
00:15:43precisamos configurar são nossas regras. Isso vai ser bem básico no início porque nossas regras
00:15:48certamente vão evoluir conforme evoluímos nossa base de código real. Eu estou usando
00:15:53o Claude Code, então me refiro a .agents e agents.md porque este é o padrão mais
00:15:58universal para nomear regras globais. O importante aqui é que as restrições
00:16:04e convenções que sempre queremos que o agente siga vão para o nosso arquivo de regras globais.
00:16:10São coisas como os comandos para rodar o app, nossa estratégia de testes, estratégia de
00:16:16logs. Não importa o que estejamos construindo, sempre queremos que o agente veja isso. Por isso queremos
00:16:20criar isso agora, pelo menos uma versão inicial para começar. E o outro
00:16:25componente que tenho aqui é a pasta de referência. Você também pode usar as habilidades do Claude Code para isso,
00:16:30mas este jeito é mais universal porque muitas vezes temos outros contextos que queremos que o agente
00:16:35tenha em mente, mas apenas quando estiver trabalhando em partes específicas da aplicação, como um guia
00:16:40para construir componentes de front-end se estivermos no front-end. O motivo de não jogarmos
00:16:44tudo no agents.md é que ele é carregado no contexto do agente
00:16:49em cada conversa. E lembre-se, o contexto é precioso. Queremos manter isso bem conciso
00:16:55e apenas apontar para cada um desses arquivos. Podemos dizer ao agente: se você estiver trabalhando
00:17:00no front-end, leia este arquivo. Ou se estiver criando novos endpoints de API, leia
00:17:04Isso é essencialmente uma divulgação progressiva. Temos diferentes camadas de contexto
00:17:09que o agente pode descobrir com o tempo para garantir que carregue apenas o necessário
00:17:14com base na tarefa atual. E para isso, tenho mais um comando. Novamente, transforme
00:17:20tudo em comando. Assim como tenho um modelo para meus PRDs, tenho um para criar
00:17:25minhas regras globais. Primeiro, vamos descobrir o que já temos na base de código.
00:17:30Pois criei isso para funcionar em bases de código existentes e novas. Para isso, o que
00:17:35ele vai explorar é o PRD. Ele vai descobrir nossa stack tecnológica, nossa
00:17:38arquitetura, pesquisar estratégias de teste e log na web e reunir tudo isso
00:17:43com minha orientação para criar as regras globais. Tenho a estrutura exata aqui.
00:17:50Ele será baseado neste modelo que eu tenho. Vou mostrar isso rapidamente também,
00:17:55porque este é o modelo que eu adoro usar para todas as minhas regras globais. Veja
00:17:59que tudo aqui é importante para nossa agência. Tipo: ok, aqui está nossa stack,
00:18:04os comandos para rodar e testar coisas, nossa estrutura de projeto. Ele tem
00:18:08basicamente um índice da base de código, arquitetura, padrões como convenções de nomes,
00:18:13estratégias de teste e validação. É bem básico, mas vamos criar isso primeiro,
00:18:17e depois darei exemplos de documentos de referência como nosso contexto secundário sob demanda.
00:18:22Vou ao Claude e, na mesma conversa onde criei meu PRD, vou apenas
00:18:27digitar "create rules", pois posso usar toda essa conversa como contexto
00:18:33de ajuda. Ele já sabe: ok, aqui está o PRD, a stack tecnológica e tudo mais.
00:18:38O comando de criar regras terminou e agora temos nossas regras globais. Já as abri aqui.
00:18:43Bem padrão. Temos a stack, os comandos... como o uso do Drizzle ORM para o banco,
00:18:47por exemplo, estrutura do projeto, arquitetura, padrões de código.
00:18:52Para ser breve, não estou customizando muito nem aplicando minhas próprias
00:18:57ideias aqui, mas dependendo do seu nível técnico, esta é a hora de garantir
00:19:03que as restrições e convenções estejam alinhadas com como você deseja
00:19:07criar suas bases de código. Você pode gastar muito tempo nisso se quiser. Eu não vou
00:19:12fazer isso agora porque estou focando nas ideias de alto nível com vocês.
00:19:16Também pedi uma pesquisa web sobre boas práticas para criar componentes de front-end e APIs.
00:19:21E com base nisso, criei alguns contextos sob demanda. Novamente,
00:19:24estes poderiam ser "Claude code skills", se você preferir. Se voltarmos às regras globais
00:19:29e descermos até a seção de contexto sob demanda, aqui está. Ao trabalhar no front-end,
00:19:34leia este arquivo. Ao trabalhar em rotas de API, leia este arquivo. O claud.md é a única coisa
00:19:40carregada de início, mas ele decide trazer o resto quando precisa. Na minha experiência,
00:19:45ele é muito bom em referenciar isso, especialmente se nossas regras globais forem concisas.
00:19:50Não temos nem 240 linhas aqui. São 233 linhas de regras globais. E temos api.md e
00:19:58components.md. Estes são bem maiores porque, quando a tarefa é específica,
00:20:03tudo bem trazer muito mais informação para garantir que o agente de código tenha boa orientação.
00:20:08Voltando ao nosso diagrama: as regras dizem como queremos construir as coisas.
00:20:14O PRD diz exatamente o que vamos construir. Com essas duas coisas em mente,
00:20:19a última coisa que quero falar aqui são os comandos, especificamente o comando "prime".
00:20:23Depois, vamos planejar a primeira fase e criar o código. A este ponto,
00:20:29temos a camada inicial de IA. Temos o PRD, as regras e os comandos genéricos
00:20:34que eu trouxe e que você pode usar. Vamos para a implementação agora. Mas
00:20:39há um detalhe: no início de cada nova conversa com um assistente de IA,
00:20:44precisamos que ele se atualize sobre a base de código. O que estamos construindo? O que vem a seguir?
00:20:50É aí que entra o comando "prime". Rodaremos /prime no início de cada
00:20:56nova sessão. É um processo guiado para ele explorar nossa base de código e chegar
00:21:02ao ponto de ter o modelo mental pronto para a próxima implementação de funcionalidade.
00:21:06Faremos ele ler a documentação e explorar a estrutura. Ele pode usar subagentes para isso.
00:21:11Verificar o log do git é outra coisa que falarei mais adiante,
00:21:15usar o log do git como nossa memória de longo prazo. Assim ele vê como o código evoluiu,
00:21:21o que o ajudará a decidir o que construir a seguir. Após este comando,
00:21:26ele nos dará seu entendimento da base de código. Assim validamos se ele sabe
00:21:31o que está acontecendo e podemos seguir adiante. Sem detalhar demais o comando prime,
00:21:36fazemos operações com o git para aproveitar o histórico. Depois, lemos
00:21:40os arquivos principais e identificamos pontos de atenção especial, como os
00:21:45principais pontos de entrada da aplicação. Esse relatório de saída é como
00:21:49validamos o entendimento dele. Podemos evoluir isso com o tempo para tornar
00:21:55específico para o projeto. Um pequeno exemplo: para ler a documentação principal,
00:22:01eu poderia dizer "leia as migrações do drizzle para entender o esquema do banco",
00:22:08certo? Ele até completou com tab. Sabia exatamente o que eu queria. Conforme você
00:22:12entende as coisas essenciais que quer que o agente foque nesta base de código,
00:22:16como outras documentações na pasta de referência, podemos adicionar aqui.
00:22:20Agora vou ao Claude, mas iniciarei uma conversa totalmente nova,
00:22:25pois vamos entrar no nosso primeiro ciclo PIV. Explicarei o ciclo PIV daqui a pouco,
00:22:30mas vejam só: vou apenas rodar "Prime". Isso será o começo da conversa.
00:22:34Neste caso, ele vai perceber: ok, é um projeto novo. Deixe-me checar o PRD.
00:22:39E vai recomendar: vamos fazer a fase um primeiro. Vamos criar a base do projeto.
00:22:44O Prime terminou. Aqui está a visão geral: página de links na bio. O estado atual
00:22:49é um repositório vazio apenas com documentação. Eu fiz um teste antes, por isso
00:22:54ele diz isso, mas limpei tudo por enquanto. Ele pegou a primeira fase, a fundação,
00:22:59do nosso PRD. É isso que ele recomenda construir, e é exatamente o que eu
00:23:04quero aqui. Quero que ele pegue as fases uma por uma do PRD, para termos
00:23:10implementações granulares em nossos ciclos PIV, que vamos detalhar agora.
00:23:14PIV é a sigla para Planejar, Implementar, Validar. Pegamos um trabalho focado,
00:23:20geralmente uma fase do PRD, e passamos por todo este processo. Criamos um plano
00:23:29estruturado sobre o que vamos enfrentar. Este processo é bem similar ao de
00:23:34criar um PRD. Depois vamos para a implementação. Nosso objetivo é delegar toda
00:23:38a codificação para o agente. E depois fazemos a validação. Vou mostrar rapidamente
00:23:44como é o processo e depois o veremos em ação. Primeiro, no planejamento,
00:23:50temos duas camadas: o planejamento de projeto de alto nível, que já fizemos
00:23:55ao criar o PRD e as regras, e agora o planejamento específico da tarefa.
00:24:00Como mencionei, são parecidos. Criar um plano estruturado é similar a criar
00:24:07nosso PRD estruturado. A diferença é que o plano estruturado é focado
00:24:13em uma funcionalidade individual e em todas as tarefas que vêm com ela. Agora
00:24:19estamos chegando ao código. Não é tão alto nível, mas vamos começar com
00:24:24uma conversa bem desestruturada. Gosto de chamar de "planejamento de vibe",
00:24:30onde exploramos ideias gerais. Qual a arquitetura do que estamos construindo,
00:24:35usando subagentes para análise de código e documentação, e descobrindo
00:24:40quais são as tarefas específicas que precisamos realizar para essa funcionalidade.
00:24:44Temos essa conversa, vou mostrar um exemplo, e a transformamos em um documento estruturado,
00:24:50assim como o PRD. O objetivo é criar um plano de ataque detalhado para o assistente
00:24:56de IA baseado na nossa conversa. A conversa faz parte do contexto, mas aqui
00:25:02temos seções específicas que quero criar no plano: o objetivo e critérios de sucesso,
00:25:09qualquer documentação de referência que um subagente tenha encontrado, nossa lista
00:25:13de tarefas, que pode incluir até os arquivos individuais a serem criados ou atualizados.
00:25:18E provavelmente a parte mais importante do plano é a estratégia de validação.
00:25:23É como o desenvolvimento orientado a testes, onde queremos ser específicos em como
00:25:27validar a funcionalidade antes mesmo de escrever uma linha de código. Isso nos obriga," e
00:25:33ao agente, a sermos muito específicos sobre os critérios de sucesso. Criamos nosso
00:25:38plano estruturado, participamos dele, mas delegamos toda a codificação ao agente.
00:25:45Isso não é codificação por "vibe", no entanto. A única razão pela qual confio no agente,
00:25:51mas verifico, é porque cerco a implementação com o planejamento e a validação
00:25:56dos quais participo ativamente. Teremos o agente de código verificando seu próprio
00:26:01trabalho com testes unitários, de integração e de ponta a ponta. Veremos isso.
00:26:06Mas eu também farei meu próprio code review e testarei a aplicação manualmente.
00:26:11Eu mesmo farei o envio. Vou navegar pela aplicação como um usuário faria,
00:26:16garantindo que tudo esteja certo antes de fazer o commit para produção ou staging.
00:26:20O importante aqui é que, entre o planejamento e a implementação, eu vou resetar o contexto.
00:26:26Esta é uma das regras de ouro. Contexto é precioso. Tenho uma conversa longa e
00:26:32detalhada para definir a funcionalidade, e o plano estruturado que crio aqui
00:26:38deve ser todo o contexto que o agente precisa para que eu possa ter uma
00:26:44conversa limpa onde o plano é a única coisa enviada, pois contém todas as referências.
00:26:50Tem a lista de tarefas, sabemos o que fazer e como validar. Assim podemos focar
00:26:55na execução, mantendo as coisas bem direcionadas, certo? Não queremos um
00:27:00contexto inchado na conversa quando começarmos a escrever o código real.
00:27:06Dito isso, vamos ao nosso primeiro ciclo PIV. Será muito mais simples
00:27:12do que você imagina, pois colheremos os frutos de todo o planejamento feito
00:27:16antecipadamente. Estamos alinhados com o agente, confiantes de que ele entende
00:27:22o que queremos construir. Não haverá tanto planejamento para cada fase, pelo menos no início.
00:27:27Voltando aqui, terminamos o prime. Estamos na mesma página que o agente de código.
00:27:31E eu apenas dei um comando simples: "sim, a fase um parece boa. Confirme tudo
00:27:36o que vamos construir". Geralmente, nos ciclos PIV posteriores, é mais detalhado.
00:27:40Tipo: "vamos olhar a base de código para ver como construir isso". Mas aqui é simples.
00:27:44Parece bom. E lembre-se: transforme tudo em comando. Quero transformar essa fase um
00:27:49em um plano estruturado com tarefas e validação. Tenho outro comando para isso.
00:27:53Chama-se "create or plan feature" ou "/plan-feature". Vou enviar e agora o plano,
00:27:59assim como a criação do PRD, já traz a ideia de plano estruturado embutida.
00:28:04Vou mostrar esse comando também: "plan feature". Ele aceita um argumento opcional
00:28:10onde especifico o que construir. Neste caso, uso o histórico da conversa. Ele já sabia,
00:28:17mas passamos por um processo em fases: entendimento da funcionalidade mergulhando
00:28:23no código, o que é mais útil em ciclos PIV futuros, muita pesquisa, busca de
00:28:28documentação, garantindo um contexto rico antes da execução. E o que você
00:28:33está vendo aqui é o modelo. Queremos descrever o problema, referências,
00:28:38plano de implementação com a lista de tarefas e, claro, a estratégia de testes.
00:28:44Definimos a validação antecipadamente. Após criar o plano, nós o validamos.
00:28:49Garantimos que seja específico: o passo a passo de como validar a aplicação.
00:28:55Estou usando a skill Vercel agent browser CLI, sobre a qual fiz um vídeo que
00:29:00linkarei aqui. Vamos construir com automação total de navegador. O agente vai
00:29:05subir o back-end e front-end, rodar as migrações, criar sua própria árvore de links
00:29:11e garantir que tudo funcione como um usuário real usaria. Muito empolgante.
00:29:17A validação será bem detalhada para que, quando o controle voltar para nós,
00:29:21possamos estar confiantes. Ainda validaremos nós mesmos, mas dará muito menos trabalho.
00:29:26E nosso plano foi criado. Vamos dar uma olhada. Eu fiz uma validação
00:29:31fora da gravação e mostrarei em breve. Geralmente você vai iterar bastante
00:29:36porque quer garantir que o entendimento da fase um esteja alinhado com o PRD
00:29:42e com o que você quer construir. Recomendo passar por todas as seções.
00:29:47Aqui está o plano com a lista de tarefas. Está bem detalhado, o que é ótimo
00:29:52agora que focamos em uma única funcionalidade. Temos a validação com a pirâmide completa:
00:29:56verificação de tipos, linting e testes unitários. E somos específicos nos testes
00:30:01de ponta a ponta, em todas as jornadas do usuário que o agente deve percorrer.
00:30:05Assim ficamos confiantes na implementação. No começo, ele não era tão bom nisso.
00:30:10Então eu fiz um prompt de acompanhamento aqui, só para dar um exemplo rápido
00:30:15de como podemos refinar o plano antes de enviá-lo para a implementação.
00:30:20Outra dica de ouro — prometo que já vamos para a implementação — mas isso é vital:
00:30:24agentes de código geralmente não lidam bem com variáveis de ambiente. Eles se perdem.
00:30:29Se você não as configurar antes da implementação, ele fará testes simulados
00:30:34e dirá que tudo está validado sem estar de verdade, o que é frustrante.
00:30:38Então, geralmente, em paralelo ao planejamento, criamos um .env.example e
00:30:43peço para ele olhar ali. Assim ele conhece as variáveis que defini e eu configuro
00:30:48as minhas também. Obviamente não mostrarei este arquivo por causa dos segredos do
00:30:53banco de dados e tudo mais. Mas como já está tudo pronto, agora podemos passar
00:30:57por toda a implementação: ele escreve o código, roda as migrações, sobe o back e
00:31:03o front, usa o browser CLI para testar tudo. E ele não precisa me interromper
00:31:09para configurar variáveis. O palco está montado e estou feliz com o plano.
00:31:13Agora, reset de contexto, pois contexto é precioso. Estou em uma janela nova
00:31:19onde uso meu comando de execução apontando para o plano. É só disso que ele precisa.
00:31:23Vou pausar e volto quando ele terminar tudo. Estamos delegando tudo ao agente,
00:31:29colhendo os frutos do planejamento. Cada ciclo PIV daqui para frente será muito
00:31:34rápido devido a este esforço inicial. Certo, nossa implementação está completa.
00:31:40Vemos pelos prints que ele fez testes de ponta a ponta. Dá para confiar bastante
00:31:45na implementação, pois o agente já cuidou de tudo, mas a validação humana ainda é vital.
00:31:51Temos que confiar, mas verificar. O code review é bem minucioso, não farei agora,
00:31:56mas se você for técnico, é importante fazer. O que eu vou fazer é testar a aplicação
00:32:01ao vivo com vocês. A única coisa que fiz fora da gravação foi criar uma conta
00:32:06para garantir que a autenticação básica estivesse funcionando. E olha só isso.
00:32:11Que legal. Já está com uma aparência muito boa. Posso definir meu nome de exibição,
00:32:16colocar uma bio tipo "um construtor de IA legal". Posso definir a URL do avatar,
00:32:21subi uma imagem no Imgur. Ficou ótimo. Posso adicionar links, como o do YouTube.
00:32:26https [youtube.com/@colemedine](https://www.google.com/search?q=https://youtube.com/%40colemedine). Perfeito. Vou adicionar outro link, o LinkedIn.
00:32:30Não tenho a URL agora, então vou colocar apenas linkedin.com. Tanto faz.
00:32:35Legal. Vou adicionar mais um, o X. x.com. Muito bom. E eu posso
00:32:39arrastar para reordená-los, e isso reflete automaticamente aqui. Posso ver o editor
00:32:43e ajustar a prévia. O tema não está incrível, está só branco, mas acho que isso
00:32:49vem numa fase posterior, pois agora estamos apenas fazendo a fundação.
00:32:55Não está perfeito ainda, mas é um excelente ponto de partida. Posso clicar em salvar
00:32:59e... ok, vamos carregar os endpoints da API rodando localmente. Pronto.
00:33:08Alterações salvas com sucesso. Se eu atualizar, tudo continua lá.
00:33:11Incrível. Está ficando muito bom. Agora que temos uma base sólida construída,
00:33:18quero falar rapidamente sobre a mensagem de commit. Tenho outro comando
00:33:24chamado "/commit", que é bem básico. Você pode detalhar mais se quiser,
00:33:28mas essencialmente você dá instruções ao agente de como criar a mensagem de git,
00:33:32pois vamos usar isso como memória de longo prazo. Voltando ao diagrama,
00:33:37esta é uma regra de ouro: seu histórico de commit é sua memória de longo prazo.
00:33:42Padronizando a mensagem com o comando "/commit" para torná-la reutilizável,
00:33:46nosso agente, ao passar pelo "prime", pode olhar o log do git e ver o histórico
00:33:51do que foi construído recentemente, guiando os próximos passos e padrões a seguir.
00:33:57Esse é o poder desta mensagem de commit. Vou rodar o "/commit". Eu mesmo
00:34:01poderia fazer o git commit, mas isso garante consistência. No caso, não há
00:34:06nada para commitar pois já o fiz antes, mas é vital fazer após cada implementação.
00:34:11regra de ouro aqui. Seu histórico de commits é sua memória de longo
00:34:17prazo. Por isso estamos padronizando nossa mensagem e usando o comando /commit para
00:34:22tornar isso reutilizável, assim nosso agente, ao processar o prompt, pode olhar o log do git para ver
00:34:28um histórico do que construímos recentemente, o que guiará os próximos passos e talvez padrões que
00:34:32queiramos que ele siga. Esse é o poder dessa mensagem de commit aqui. Vou dar um /commit,
00:34:38embora eu pudesse rodar o git commit eu mesmo. É muito fácil, mas isso garante
00:34:43que a mensagem seja sempre do mesmo tipo para manter a consistência. Neste caso, não há nada para commitar porque
00:34:48eu já rodei isso fora da gravação também, mas é importante cuidar disso após cada
00:34:53implementação. Agora, outra coisa super importante para cobrir depois de termos a base do
00:34:58projeto definida é configurar uma estrutura para testes de regressão. Queremos garantir
00:35:04que, conforme passamos por futuros ciclos PIV — repetindo esse processo repetidamente para todos
00:35:09os recursos que queremos criar — as funcionalidades antigas não quebrem. Vou
00:35:14cobrir isso com mais detalhes em outro vídeo, todas as estratégias que tenho para implementar esse tipo
00:35:19de arnês de teste você mesmo, porque essencialmente você vai ao agente e diz: "ok, o que
00:35:25temos agora é ótimo, mas eu também poderia ir aqui no Aqua Voice e dizer: quero que você liste todos
00:35:31os testes de ponta a ponta que você fez e coloque isso em um comando para mim. Assim posso rodar depois de
00:35:36criar outros recursos para garantir que tudo o que construímos anteriormente ainda
00:35:41esteja funcionando", certo? Algo desse tipo. Novamente, não vou entrar em detalhes sobre isso
00:35:46agora. Leva um tempo para configurar e criar um arnês de teste, mas é assim que você garante
00:35:50que sua aplicação fique estável enquanto continua construindo sobre ela. E realmente dá
00:35:55muito trabalho criar e manter isso, pois você precisa atualizar constantemente. Por isso, também existem
00:36:00soluções prontas que cuidam disso para você. E elas são muito poderosas. Uma dessas
00:36:05aplicações é a QA tech. Eles têm agentes de teste de IA que evoluem e se adaptam à sua base de código.
00:36:11Assim, conforme você adiciona mais recursos, eles adicionam mais casos de teste para garantir que
00:36:16tudo em sua aplicação esteja funcionando bem enquanto você a expande. Vou mostrar
00:36:22um exemplo disso rapidinho. É muito fácil começar. Você entra na QA tech, eles têm um
00:36:26plano gratuito para você testar. Vou criar um projeto aqui e basta
00:36:30colar a URL que você quer testar. Como eu já fiz um commit
00:36:35e dei push para o GitHub, fiz o deploy em apenas um minuto na Vercel. É o lugar mais fácil para hospedar
00:36:40sites de graça, especialmente com Next.js. Então vou ao meu projeto aqui
00:36:45e colo esta URL. Vai levar um tempinho para criar seu projeto e analisar
00:36:50seu código. O que podemos fazer é dizer: "Quero uma boa configuração de teste para o meu site. Me ajude a criar
00:36:55os primeiros três a cinco casos de teste". É algo como o bolt.new ou o Lovable,
00:36:59onde você dá um prompt para o que deseja fazer para configurar a suíte de testes do seu
00:37:04projeto. Isso é o que eles recomendam para começar. Vou enviar.
00:37:08É muito legal porque ele vai vasculhar seu site, vai realmente rastreá-lo, mas você
00:37:12não precisa gerenciar a infraestrutura. Ele analisa o site e sugere os casos de
00:37:16teste. Volto quando terminar. Durante a execução, só quero mostrar rapidinho
00:37:21que ele rastreou meu site em apenas alguns minutos. Um dos pontos cruciais
00:37:25é que precisamos de uma forma de logar no site. Queremos que a automação consiga fazer isso. E
00:37:29eles oferecem um modo de inserirmos usuário e senha, que serão armazenados de
00:37:34forma segura. Criei uma conta de teste aqui. Vou salvar. E então
00:37:38ele usará isso para entrar no site, explorar e entender todas as jornadas do usuário que
00:37:43queremos testar. E pronto. Ele gerou vários casos de teste para nós, e podemos
00:37:48até clicar em cada um deles. Podemos ver o fluxo exato que ele percorreu. Agora
00:37:53temos todos esses testes configurados. E os agentes de teste de IA da QA tech vão evoluir esses
00:37:59casos de teste com o tempo para garantir a cobertura contínua da nossa base de código. À medida que criamos
00:38:04mais recursos, fica cada vez mais incrível. De novo, poderíamos criar nosso próprio sistema de
00:38:09comandos para fazer algo assim. Mas eu prefiro ter uma plataforma que cuida de tudo
00:38:14para mim. Há agentes por trás com os quais posso conversar para ajustar os testes
00:38:19e garantir que estou realmente fazendo testes de regressão em tudo. Assim, sempre que
00:38:24algo quebrar, posso vir aqui e dizer: "ok, há um bug na aplicação agora,
00:38:28crie um teste que aponte essa falha. Deixe-me resolver o problema". E então o teste deverá
00:38:33passar. Isso nos leva à última regra de ouro que tenho aqui: a mentalidade de evolução do sistema.
00:38:40Sempre que encontrarmos um bug em nosso código, é importante não apenas corrigi-lo,
00:38:46mas pensar no que podemos ajustar em nossa camada de IA para que isso não se repita. Talvez
00:38:51precisemos ser mais específicos em nosso guia de estilo e regras, ou criar um novo contexto sob demanda.
00:38:57Talvez precisemos de mais testes de ponta a ponta definidos em nossos comandos, fluxos de trabalho,
00:39:02o que for necessário para evitar esse problema no futuro. E também podemos
00:39:06fazer o que mostrei na QA tech ou em nosso sistema de comandos, adicionando um teste para garantir que
00:39:12não tenhamos esse erro novamente no código. O poder disso, embora leve
00:39:16tempo, é que tornamos nosso agente de codificação mais confiável e consistente, evoluindo-o
00:39:21junto com nossa base de código. Estamos fazendo três coisas em paralelo: enquanto construímos
00:39:26nosso código, evoluímos nossa base de testes, nossa base de código e nossa camada de IA. E isso
00:39:32se acumula imensamente com o tempo. Voltando ao Cloud Code, vou dar um exemplo simples
00:39:37disso. Uma coisa que fiz para iterar fora da gravação foi trabalhar no estilo do site.
00:39:43Pois se voltarem ao início do vídeo, verão que esqueci de falar sobre o
00:39:47estilo, exatamente como eu queria o visual. O Cloud Code acabou fazendo suas próprias
00:39:51suposições. E não ficou muito bom. Tive que iterar nisso. Uma coisa que posso fazer
00:39:56aqui é: "no início, não gostei do estilo que você implementou no front-end. Com certeza
00:40:01não temos o suficiente na camada de IA, em nossas regras e contexto sob demanda, para uma diretriz de
00:40:06estilo. Quero que você faça um raciocínio meta aqui. Não mude nada, mas me ajude a pensar
00:40:10agora: o que poderíamos mudar em nossas regras ou contexto sob demanda, algo que pudéssemos
00:40:15adicionar ou atualizar para termos estilos mais consistentes enquanto continuamos a
00:40:20construir as análises e outras páginas desta aplicação".
00:40:25O importante aqui é dizer para não mudar nada ainda,
00:40:29porque geralmente quero ter muito mais controle ao alterar a camada de IA, enquanto para o
00:40:34código, prefiro delegar o máximo possível ao agente. Peço para ele raciocinar comigo,
00:40:39mas gosto de fazer essas mudanças pequenas e focadas eu mesmo. Veja que ele
00:40:44recomenda criar um style.md na pasta de referência. Um terceiro contexto sob demanda para
00:40:50nós. Isso acompanharia o components.md. Aquele é mais sobre "como
00:40:54organizar as coisas". O styles.md é sobre "como deve funcionar", como trabalhar
00:40:58com Tailwind CSS e provavelmente ShadCN, por exemplo. Não vou passar pela
00:41:03implementação completa e corrigir tudo agora, mas quero dar um bom exemplo de
00:41:06como, ao encontrar bugs ou desalinhamentos — como este aqui — temos sempre uma
00:41:11oportunidade de evoluir a camada de IA. Assim ficamos cada vez mais
00:41:16sintonizados com nosso agente de codificação para este projeto específico conforme avançamos.
00:41:20E essa, meu amigo, é a parte de maior impacto de todo o processo; deixei o melhor para
00:41:26o final. É isso. É realmente um processo bem simples para obter resultados confiáveis e
00:41:32consistentes com seus agentes de codificação ao iniciar novos projetos, pois após a
00:41:35evolução do sistema, voltamos ao topo e passamos por mais ciclos PIV seguindo
00:41:40exatamente o mesmo processo para construir as fases do PRD, adicionar recursos ou o que for
00:41:45necessário para chegar ao produto mínimo viável. Isso nos levará ao desenvolvimento Brownfield
00:41:49em um dos próximos vídeos que lançarei no canal. Se tudo isso faz sentido para você
00:41:54e quer mergulhar fundo com minha biblioteca completa de comandos e regras, ou
00:41:59ver como a evolução do sistema realmente funciona na prática, não deixe de conferir o
00:42:04curso de codificação agente na comunidade Dynamics. Vou deixar o link na
00:42:08descrição e no comentário fixado. Por enquanto é tudo o que tenho para vocês. Se você
00:42:13gostou do vídeo e quer ver mais sobre codificação agente e o vídeo de
00:42:17desenvolvimento Brownfield, eu agradeceria muito o seu like e inscrição. Com isso, vejo você
00:42:22no próximo vídeo.