00:00:00Embora o Claude Code seja uma das ferramentas mais poderosas para o desenvolvimento de IA,
00:00:03por que ele falha em certas tarefas? Entre os recursos que a Anthropic tem
00:00:08lançado recentemente e os fluxos de trabalho que criamos, a maneira como você deve
00:00:12usar essa ferramenta parece completamente diferente de poucas semanas atrás. Nossa equipe usa o Claude
00:00:16Code todos os dias e não apenas para desenvolvimento, mas também para pesquisa, gestão do nosso pipeline
00:00:21de produção e automação de tarefas que não têm nada a ver com código. Vou mostrar tudo
00:00:26o que descobrimos. A Anthropic adicionou recentemente o comando insights para o Claude Code. Ele analisa
00:00:31todas as suas sessões anteriores do Claude Code em um período e gera um relatório. O relatório
00:00:36analisa seu estilo de trabalho, critica seus padrões, destaca o que você acertou e
00:00:40o que errou, e ensina como melhorar. O que mais nos interessou foi identificar
00:00:45onde as coisas deram errado, pois é aí que podemos aprender e evoluir. O relatório destacou
00:00:49as áreas com mais atrito e sugeriu recursos que poderíamos adicionar para tornar o
00:00:54fluxo de trabalho melhor. Por exemplo, lembramos de uma sessão onde o agente principal consultou repetidamente
00:00:58a lista de tarefas por muito tempo ao usarmos equipes de agentes. Isso atrasou a sessão e
00:01:03tivemos que encerrá-la manualmente. Para evitar que isso se repita, podemos copiar este prompt
00:01:07no cloud.md para que, ao usar o Claude Code com multiagentes, o Claude não fique consultando
00:01:12indefinidamente e tome uma atitude. Podemos importar essas dicas para futuros fluxos de trabalho para que
00:01:17nossa experiência com o Claude Code melhore com o tempo. Nossa equipe passou muito tempo trabalhando
00:01:22com o Claude Code e o passo mais importante ainda é quão bem você fornece contexto ao agente.
00:01:26Isso pode incluir requisitos do projeto detalhados ou documentação dos frameworks e
00:01:30bibliotecas usadas, pois com o contexto certo, os erros praticamente somem,
00:01:35já que ele sabe o que fazer. Para a documentação do projeto, preferimos usar o Claude para escrevê-la
00:01:39em vez de fazermos nós mesmos. Demos ao Claude um prompt específico com toda a informação
00:01:44necessária para dividir a ideia do projeto nos documentos exigidos. Pedimos para ele criar
00:01:48quatro documentos, cada um focado em um aspecto específico do app. O mais importante é o PRD,
00:01:53que contém informações sobre os requisitos e escopo do projeto. Depois temos o architecture.md,
00:01:57com formatação de dados, estrutura de arquivos, APIs e todos os detalhes de arquitetura.
00:02:02Em seguida, o decision.md, com todas as decisões que o Claude tomou durante a criação deste projeto,
00:02:08servindo de referência futura. E o mais importante de todos é o feature.json, que contém
00:02:12todas as funcionalidades em formato JSON. Ele traz os detalhes de cada recurso de forma eficiente em tokens
00:02:17e inclui critérios de conclusão, junto com uma chave de confirmação para
00:02:22rastrear o que já foi implementado. Agora que sua grande tarefa está dividida em
00:02:27seções menores, precisamos fornecer documentação sobre quais ferramentas ele precisa para a implementação via
00:02:31Context 7 MCP. Ele possui documentação de todas as bibliotecas e frameworks e é atualizado
00:02:36frequentemente para que os agentes usem as docs mais recentes e preencham a lacuna entre o conhecimento do modelo e
00:02:41a atualização atual. Configurar o MCP leva poucos passos. Uma vez instalado, ele
00:02:46usou as ferramentas do Context 7 e buscou as informações da biblioteca diretamente. Isso permite usar
00:02:50a documentação mais recente, evitar erros de código por incompatibilidade de dependências e obter uma
00:02:55implementação mais precisa. Hooks são outro recurso pouco explorado. Os hooks no Claude Code
00:03:00são comandos de shell disparados em pontos específicos do ciclo de vida. Há vários tipos que ativam em
00:03:05momentos como o início da sessão, antes ou depois do uso de uma ferramenta. Mas o mais importante
00:03:11é configurá-los com códigos de saída específicos. Eles dizem ao Claude Code se deve prosseguir,
00:03:16bloquear ou ignorar uma ação. Um código 0 significa sucesso. O código 2 significa um erro de bloqueio. Então,
00:03:22sempre que o Claude tenta fazer algo indevido, ele atinge o código 2, recebe uma mensagem de erro
00:03:27e pode se corrigir. Qualquer outro código é não-bloqueante, exibido no modo detalhado,
00:03:32e a execução continua. Esse código 2 é vital pois, com ele, você controla o
00:03:37comportamento do agente. Se você já trabalhou com TDD (Desenvolvimento Orientado por Testes) usando o Claude Code,
00:03:41deve ter notado que ele tende a modificar os testes se falhar em cumpri-los. Para evitar
00:03:46isso, configuramos um hook personalizado que dispara antes do uso da ferramenta. O hook protege os scripts de teste
00:03:50ele exibe uma mensagem de erro proibindo modificações em pastas de teste e retorna
00:03:55it shows an error message saying modifications to test folders are not allowed and returns
00:04:00o código de saída 2. Com este hook, quando pedimos ao Claude para rodar os testes e eles
00:04:05falharam, ele tentou modificar os arquivos de teste. Mas o script o bloqueou e uma mensagem de
00:04:10bloqueio de modificação apareceu. Isso impediu o Claude de editar arquivos indevidos. Se você já trabalhou
00:04:15com MCPs, sabe que eles inflam a janela de contexto. Em projetos de grande escala,
00:04:19o número de MCPs conectados aumenta. Assim, todas as ferramentas de MCP acabam ocupando a janela de contexto
00:04:25e ela fica sobrecarregada. Para resolver isso, o Claude Code tem um modo experimental de MCP via CLI.
00:04:31Ativamos a flag experimental de MCP CLI. Feito isso, todos os MCPs que apareciam
00:04:36no contexto sumiram e nenhum espaço da janela de contexto foi ocupado pelas ferramentas de MCP. A questão era
00:04:41como acessar as ferramentas se elas não estavam mais na memória. Em vez de carregar todos os
00:04:45esquemas de ferramentas de antemão, o Claude Code usa o MCP CLI info e chamadas de MCP CLI para rodar os MCPs
00:04:52conectados através dessas ferramentas via bash. Com a flag ativa, ao enviarmos um prompt, em vez de chamar
00:04:56a ferramenta MCP diretamente, ele a chamou via ferramentas de CLI e as executou como comandos bash.
00:05:03Dessa forma, ele só carregava a ferramenta necessária sob demanda, evitando o inchaço do contexto. Além disso,
00:05:08se estiver gostando do conteúdo, considere clicar no botão de hype, pois isso nos ajuda a criar mais
00:05:13vídeos como este e alcançar mais pessoas. Em vídeos anteriores, enfatizamos o uso do
00:05:18git para rastrear o trabalho dos agentes no controle de versão. Você também pode reverter as mudanças se os agentes
00:05:23não implementarem as coisas corretamente. Também fizemos um vídeo usando git para rodar um agente em uma tarefa de longo
00:05:28prazo, que você pode conferir no canal. Usamos agentes paralelos para trabalhar em diferentes “worktrees”
00:05:32para que pudessem criar todos os recursos do projeto de forma isolada entre si.
00:05:37Assim, pudemos mesclar o resultado depois sem interferências, já que agentes trabalhando
00:05:41nos mesmos arquivos causam conflitos. Branches não são ideais pois geram conflitos. Agentes têm
00:05:46dificuldade em alternar entre branches, pois elas compartilham o mesmo diretório, mas as worktrees não.
00:05:50Então, demos um prompt com vários recursos a serem implementados e especificamos
00:05:55que cada agente deveria trabalhar em uma worktree separada. Ele usou um agente para cada
00:05:59worktree e implementou os recursos isoladamente, mesmo que as descrições das tarefas
00:06:03se sobrepusessem em alguns pontos. Após o Claude implementar tudo corretamente em
00:06:08branches separadas, pedimos para ele mesclar tudo em um único diretório de trabalho.
00:06:13O modo estrito é essencial para transferir a responsabilidade da verificação de erros para o agente. Isso é
00:06:18algo que você deve configurar em qualquer linguagem, pois detecta bugs
00:06:22no momento do build, antes de chegarem ao usuário final. Como nossa linguagem principal é TypeScript,
00:06:26sempre ativamos o modo estrito nos projetos. Isso ativa verificações de valores nulos e tipos
00:06:31implícitos, garantindo tipagem forte e menos erros em tempo de execução. Isso é crucial
00:06:36para agentes de IA, pois eles não têm uma forma nativa de capturar erros de runtime. O modo estrito minimiza
00:06:41falhas e garante que o compilador lide com esses problemas. Agentes podem
00:06:46contar com logs de erro no terminal para aplicar correções conhecidas. Além de testar o projeto
00:06:51apenas com scripts, vale a pena adicionar uma camada extra de testes. Você escreve histórias de usuário
00:06:56descrevendo como o usuário interage com o sistema para guiar o processo de teste após a
00:07:00construção do app. Definimos as histórias antes da implementação, pois isso estabelece
00:07:05um padrão a ser seguido. Com um prompt, o Claude escreveu várias histórias
00:07:10dentro de uma pasta contendo todas as formas possíveis de interação com o sistema. Cada história
00:07:15apresenta um aspecto do app, sua prioridade e os critérios de aceitação para o agente testar.
00:07:21As histórias cobriram todos os cenários, incluindo casos ideais e casos extremos. Essas
00:07:26histórias dizem aos agentes como interagir com o sistema que acabamos de construir. Com as
00:07:31instruções certas, qualquer agente pode aplicar os mesmos princípios ao app e atender
00:07:35melhor às expectativas do usuário. Com as histórias documentadas, pedimos ao Claude para
00:07:40implementá-las uma a uma, começando pelo caminho ideal e garantindo que os casos
00:07:45extremos fossem cobertos. Assim, a implementação teve menos falhas e maior satisfação do usuário.
00:07:50Todas as dicas mencionadas estão disponíveis como templates prontos no AI Labs Pro.
00:07:55Para quem não conhece, é nossa comunidade recém-lançada onde você encontra templates, prompts,
00:08:00comandos e habilidades que pode plugar direto nos seus projetos. Se você vê valor no
00:08:05que fazemos e quer apoiar o canal, esta é a melhor forma. Links na descrição.
00:08:10Devemos aproveitar a paralelização ao máximo, pois é assim que o agente acelera
00:08:14seu fluxo e implementa coisas que não dependem uma da outra. Sabemos que o Claude detecta
00:08:20automaticamente se uma tarefa pode ser paralela ou sequencial e decide sozinho, mas
00:08:25não custa criar os agentes nós mesmos. Também cobrimos essas capacidades no vídeo anterior,
00:08:29onde falamos sobre como usar agentes para agilizar seu fluxo, mas essa velocidade tem
00:08:34um custo de maior uso de tokens. Ainda assim, o esforço de paralelização vale a pena. Certa vez,
00:08:39estávamos pesquisando o impacto das melhorias do Opus 4.6 e o modelo continuava
00:08:43alucinando fatos, mesmo fornecendo as fontes. Ele escrevia informações incorretas e tínhamos que
00:08:49corrigi-lo repetidamente. A pesquisa parecia inútil, pois tínhamos que consertar tudo sozinhos.
00:08:54Para evitar isso, usamos agentes paralelos. Configuramos uma tarefa de pesquisa para
00:08:58comparar as capacidades de enxame de agentes do KimiK 2.5 e do Claude.
00:09:03Usamos dois agentes: um para pesquisar e outro para verificar os fatos do primeiro. A ideia
00:09:09era fazer os dois se comunicarem para garantir a precisão dos dados, poupando nosso trabalho.
00:09:14Nesse setup, um agente executa a tarefa enquanto o outro analisa criticamente, em um modelo adversarial.
00:09:19O agente de pesquisa começou primeiro e o verificador ficou bloqueado até o primeiro rascunho
00:09:24ficar pronto. Assim que terminou, o verificador começou a validar as informações. Ele identificou
00:09:28várias imprecisões nos dados do pesquisador e não precisamos mais pegá-las manualmente.
00:09:33Ambos mantiveram a comunicação e o processo de verificação foi rigoroso. Um agente dedicado
00:09:38apenas a apontar erros no outro. Muitas tarefas podem rodar nesse modelo adversarial,
00:09:43não só pesquisas, mas desenvolvimento também, onde um agente implementa e
00:09:47outro revisa a implementação conforme o planejado. Segundo o criador do Claude Code,
00:09:52o agente funciona melhor se tiver uma forma de verificar o próprio trabalho. A ideia central
00:09:57é dar “olhos” ao agente, ou seja, a habilidade de checar se o recurso atende às expectativas.
00:10:02Como esses agentes rodam no terminal, eles não veem problemas que ocorrem no lado do cliente
00:10:07em tempo de execução. Usamos várias formas de verificar o trabalho do agente. A primeira
00:10:12é a extensão do Claude para Chrome, com ferramentas de captura de DOM, logs de console e mais.
00:10:17Outra ferramenta é o Puppeteer MCP. Ele é útil pois roda em um navegador separado que não
00:10:21contém suas sessões atuais, ao contrário da extensão do Chrome. Ele é isolado e oferece
00:10:26uma camada extra de privacidade. Mas nossa opção preferida é o agent browser da Vercel. Não é um MCP,”
00:10:31mas uma ferramenta de CLI que dá aos agentes capacidades de teste em navegador. Ele permite navegar,
00:10:36capturar prints e mais. Diferente de outros, ele não navega apenas por capturas de tela.
00:10:41Ele usa a árvore de acessibilidade, onde cada elemento tem uma referência única. Isso reduz o DOM
00:10:46de milhares de tokens para cerca de 200 a 400, sendo muito mais eficiente. Esse era o problema
00:10:51da extensão do Chrome que o agent browser resolveu: ela carregava o DOM inteiro no contexto
00:10:56e o esgotava rápido. Adicionamos instruções no Claude.md para o Claude priorizar o agent browser
00:11:01antes de recorrer a testes baseados em MCP. Assim, o Claude o usa como método principal.
00:11:07Mas há outro ângulo: testar é importante, mas há uma forma de reduzir erros sem envolver testes
00:11:12ou revisões de código. Pedimos ao Claude para prever coisas que ainda não aconteceram.
00:11:17Pedimos para ele checar a implementação e identificar onde o app poderia falhar. Isso funciona
00:11:23porque damos ao Claude a chance de prever problemas por reconhecimento de padrões de falhas
00:11:28que já existiram em outros apps, mesmo que ainda não os tenhamos encontrado nos testes.
00:11:33Isso força o Claude a olhar o código sob uma perspectiva diferente. Ao pedirmos isso,
00:11:38ele identificou falhas críticas que passaram pelo nosso processo de testes em várias camadas
00:11:43e encontrou 18 problemas que seriam prejudiciais em produção. Nossos testes não os pegaram.
00:11:47Eles só foram identificados quando forçamos o Claude a olhar o projeto por outro ângulo.
00:11:52Chegamos ao fim deste vídeo. Se quiser apoiar o canal e nos ajudar a continuar criando vídeos
00:11:57como este, você pode fazê-lo usando o botão de Valeu Demais abaixo. Como sempre,
00:12:01obrigado por assistir e vejo você no próximo vídeo.
00:12:06project from another angle. That brings us to the end of this video. If you'd like to support the
00:12:10channel and help us keep making videos like this you can do so by using the super thanks button
00:12:15below. As always thank you for watching and I'll see you in the next one.