00:00:00Nos últimos meses, cobrimos muitos frameworks de codificação por IA, incluindo BMAD, GSD, Speckit e Superpowers,
00:00:08e muitos de vocês realmente começaram a usá-los. Mas a Anthropic acabou de realizar experimentos em seu próprio equipamento,
00:00:14removendo componentes um por um e medindo o que realmente importava. A conclusão deles foi que a maior parte disso agora é peso morto.
00:00:17Cada componente em um framework codifica uma suposição sobre o que o modelo não consegue fazer sozinho,
00:00:25e com o Opus 4.6, essas suposições ficaram obsoletas. Analisamos tudo e mapeamos o que ainda importa,
00:00:32o que você pode remover e como sua configuração deve realmente ser agora. Os suportes de agentes desempenham um papel
00:00:37importante para fazer os agentes funcionarem substancialmente melhor em longos horizontes. A Anthropic já lançou um suporte de agente,
00:00:43que cobrimos em detalhes em um vídeo anterior, explicando como configurar e usar. Também cobrimos outros frameworks
00:00:50nesse mesmo contexto e, embora suas implementações difiram, todos tentam fazer a mesma coisa. Mas quando esses frameworks
00:00:55foram lançados, os modelos não eram tão capazes quanto o Opus 4.6 é agora. Por exemplo, frameworks como GSD
00:01:01focam no isolamento de contexto, mas isso não é um problema com o Opus 4.6. Não apenas pela janela de contexto de um milhão de tokens,
00:01:06mas por outro motivo que falaremos em breve. Portanto, muitos frameworks implementados anteriormente são agora
00:01:11um excesso para as novas capacidades do modelo. A Anthropic realmente realizou experimentos testando diferentes aspectos
00:01:17do suporte, removendo cada um e medindo seu impacto. A partir de suas descobertas, eles concluíram que tudo o que um suporte de agente
00:01:24realmente precisa são agentes para planejamento, geração e avaliação. O resto são apenas formas de fazer as coisas
00:01:29que se tornam peso morto, dada a capacidade atual dos modelos. A teoria central é que cada componente em um suporte de agente,
00:01:35não importa qual você esteja usando, depende do mesmo princípio. Cada componente codifica uma suposição
00:01:38sobre o que o modelo pode fazer por conta própria. Essas suposições devem ser testadas sob estresse porque podem estar incorretas,
00:01:46e ficarão obsoletas à medida que o modelo melhora, e foi isso que fizeram ao longo do artigo. Portanto, com a evolução dos modelos,
00:01:54seu suporte também deve evoluir, e se você estiver trabalhando com os mesmos princípios estabelecidos meses atrás, não está acompanhando.
00:02:01O planejamento é o primeiro passo que permanece inalterado em todos os frameworks, mas a forma como você planeja tem que mudar
00:02:06para modelos mais capazes. Os suportes de longa duração anteriores da Anthropic exigiam que o usuário fornecesse uma especificação detalhada antecipadamente.
00:02:14Frameworks como BeMad e SpecKit literalmente fragmentam a tarefa em pedaços menores e microtarefas que ajudam o agente de IA
00:02:20a implementá-la com facilidade. E não eram apenas tarefas pequenas, eram literalmente passos detalhados que os agentes
00:02:27tinham que seguir sem pensar. Isso ocorria porque, naquela época, os modelos não eram capazes o suficiente e precisavam
00:02:30ser microguiados para que pudessem atuar da forma desejada. Mas com o Opus 4.5 e 4.6, isso mudou. Quando a Anthropic testou isso,
00:02:43descobriram que, se o planejador tentasse especificar detalhes micro-técnicos antecipadamente, um único erro causaria uma cascata
00:02:45em todos os níveis de implementação, dificultando o desvio e a correção de problemas pelo agente. Tudo dependia de quão bem escrito
00:02:50estava o plano. Portanto, o planejamento agora tornou-se de alto nível, em vez de uma implementação técnica detalhada.
00:02:55Os agentes são muito mais espertos por conta própria agora e você só precisa dizer quais entregáveis são necessários.
00:02:57Eles conseguem descobrir o caminho para isso sozinhos. Com essa mudança, abordagens de planejamento como as do BeMad e SpecKit
00:03:02não são mais tão relevantes. Você pode limitar o BeMad à fase de planejamento até a geração do PRD, sem necessidade de entrar no processo
00:03:08de fragmentação técnica. Como mencionamos antes, a geração de PRD com o BeMad é eficaz porque possui agentes especializados
00:03:18para entender os requisitos do produto melhor do que o Claude faria sozinho. Isso ocorre porque esses agentes têm o contexto externo
00:03:23para tarefas específicas adicionadas pelo autor. Alternativamente, você pode usar a sessão de perguntas do Superpowers,
00:03:32já que foi realmente destinada a identificar casos extremos, o que pode ser mais eficaz do que documentação de tarefas multinível.
00:03:40Mas o problema central com o planejamento excessivamente detalhado é que ele bloqueia o agente e não deixa espaço para a IA
00:03:46fazer descobertas e resolver as coisas por conta própria. A Anthropic também forneceu um exemplo de plano gerado pelo agente planejador,
00:03:52que você pode usar para configurar seu próprio agente. Ele descreve claramente que o plano deve focar no escopo e expandir os limites
00:03:56de qualquer ideia de aplicativo que você fornecer. A ideia central é manter o projeto no nível do produto, não no nível da implementação.
00:04:06Isso importa porque, se ele tentar planejar a implementação dentro do plano do projeto, torna-se focado demais em detalhes técnicos
00:04:12e pode falhar em entregar o que é realmente necessário para um produto completo. Agora você pode pensar que o próprio modo de plano
00:04:22do Claude já faz um planejamento semelhante ao fazer perguntas e fornecer um plano detalhado. Mas aqui está a diferença:
00:04:31embora o Claude tenha um agente de planejamento, ele ainda foca muito em detalhes de implementação e não opera verdadeiramente
00:04:40no nível do produto, o que vai contra as descobertas da Anthropic. Portanto, uma vez que você tenha isso configurado, pode simplesmente pedir
00:04:44ao Claude para usar o agente que você criou para planejar seu app, e ele gerará um plano completo e o documentará em sua pasta.
00:04:47Este plano inclui uma quebra total de recursos no nível do produto e, em cada fase, inclui histórias de usuários que mostram
00:04:56como é a perspectiva do usuário. Isso ajuda o Claude a implementar os fluxos de trabalho corretos que os usuários realmente esperam.
00:04:59Mas antes de prosseguirmos, uma palavra do nosso patrocinador, Minimax. Configurar agentes de IA é um pesadelo: chaves de API,
00:05:02configurações de servidor, setups de Docker... e depois de tudo isso, seu assistente esquece tudo no momento em que você fecha a aba.
00:05:12A solução é o MaxClaw, uma IA poderosa na nuvem ao seu alcance. Sem configuração, sem dores de cabeça, você pode implantar seu próprio OpenClaw.
00:05:21Basta clicar em implantar e você estará no ar em menos de 10 segundos. Ele constrói sites, escreve código, faz pesquisas e automatiza
00:05:27seu trabalho chato, tudo a partir de comandos de texto simples. O MaxClaw se conecta diretamente ao Telegram, Slack, Discord e mais,
00:05:33permitindo automatizar fluxos, navegar na web e até gerar imagens ou vídeos, tudo a partir de um simples chat. Faz parte do Minimax Agent,
00:05:39um espaço de trabalho nativo de IA onde todos se tornam designers de agentes. Funciona em Mac, Windows, alimentado pelo M 2.7,
00:05:42que iguala o Claude Opus 4.6 no Sweetbench. Pare de lutar com configurações complexas, deixe o MaxClaw cuidar disso,
00:05:46e clique no link no comentário fixado para começar. O agente que escreve o código não deve ser o mesmo que o avalia.
00:05:56Este é o segundo problema mais comum e geralmente não é muito discutido. A autoavaliação é problemática porque,
00:06:03se você usar o mesmo agente que escreveu o código para avaliá-lo, ele tende a responder com muita confiança e elogiar o próprio trabalho,
00:06:08mesmo quando a qualidade é claramente inferior. Isso pode ser mais fácil de gerenciar para tarefas que possuem métricas quantitativas,
00:06:10como se as APIs implementadas estão realmente funcionando. Mas este problema torna-se muito mais pronunciado para tarefas
00:06:15que não possuem resultados claramente verificáveis. O maior exemplo disso é a interface do usuário (UI). O que constitui uma boa UI
00:06:19é subjetivo, e a IA pode não compreender totalmente suas intenções. Ela pode considerar sua própria implementação como bem feita,
00:06:26mesmo que não atenda aos seus padrões. Esse problema já era reconhecido pelos criadores de vários frameworks, e eles implementaram
00:06:34seus próprios mecanismos de avaliação para resolvê-lo. Todos os frameworks que cobrimos, como GSD, BMAD e Superpowers,
00:06:39garantem que o mesmo agente que escreveu o código não avalie sua qualidade. Essa abordagem melhora significativamente a precisão
00:06:47e a confiabilidade das avaliações do agente. Portanto, seja usando um framework existente ou construindo o seu próprio,
00:06:54você precisa garantir que o avaliador seja completamente separado do implementador. Antes da implementação começar, tanto o agente gerador
00:06:58quanto o avaliador negociam um contrato, concordando sobre como deve ser o trabalho "concluído". Isso ajuda porque ambos os agentes
00:07:02sabem claramente o que alcançar e o que verificar. Com o planejamento de alto nível, ainda precisa haver etapas acionáveis e implementáveis.
00:07:06Mas durante os testes com o suporte, eles tentaram remover o contrato de sprint. Eles descobriram que o Opus 4.5 era menos eficiente
00:07:12nesse cenário porque o avaliador ainda precisava intervir para capturar problemas. Mas com o Opus 4.6, as capacidades do modelo
00:07:18melhoraram tanto que o contrato não era necessário. O agente generativo era capaz o suficiente para lidar com a maior parte do trabalho sozinho.
00:07:22Portanto, para modelos menores como Sonnet ou Haiku, você ainda precisa documentar as tarefas. Divida-as adequadamente
00:07:27em estruturas de sprint e faça cada agente concordar com o que parece ser "completo". Mas com modelos mais capazes,
00:07:32você pode confiar no Opus para executar o plano de alto nível sem essas etapas adicionais. Agora, dissemos que há uma razão
00:07:38pela qual o isolamento de contexto importa. Isso ocorre porque modelos menores sofrem de ansiedade de contexto,
00:07:42um fenômeno onde os modelos começam a perder a coerência em tarefas longas à medida que sua janela de contexto se enche.
00:07:51Quando isso acontece, eles encerram o trabalho prematuramente e afirmam ter implementado as tarefas corretamente, mesmo quando não o fizeram.
00:07:57A solução que ajudou foi um reset de contexto, limpando suas janelas de contexto antes de iniciar a implementação. Como o contexto
00:08:02era limpo, eles podiam confiar em uma quebra de tarefas documentada externamente, que persistia através dos resets de contexto.
00:08:08Mas os modelos exibiam tanta ansiedade de contexto que a compactação sozinha não era suficiente. Eles precisavam de medidas adicionais
00:08:13para evitar problemas em tarefas mais longas. A partir do Opus 4.5, no entanto, os modelos não exibem mais esse comportamento.
00:08:17Esses agentes podem rodar continuamente em uma sessão inteira, e a forma como o Claude lida com a compactação é suficiente
00:08:21para o seu funcionamento. Portanto, os resets de contexto não são mais necessários, e quebras detalhadas de tarefas como as do BMAD
00:08:28e SpecKit também não são precisas, bastando apenas uma orientação de alto nível. O agente gerador é o principal implementador
00:08:37que realmente constrói o app recurso por recurso. Ele pega as especificações do plano e as implementa continuamente,
00:08:42integrando-se com o Git para controle de versão. O gerador trabalha em coordenação com o agente avaliador. Após construir um recurso,
00:08:47ele o entrega para testes e recebe feedback para melhorar sua implementação. Seu fluxo de trabalho é organizado em várias etapas:
00:08:50entender a tarefa, implementá-la e refinar a implementação. Mesmo dentro da fase de implementação, o trabalho é dividido em quatro subfases
00:08:56que cobrem diferentes aspectos. Ele segue a direção do design, verifica seu trabalho e então o entrega ao avaliador.
00:09:02Isso cria um padrão estruturado, passo a passo, permitindo que o agente implemente um aplicativo inteiro de forma independente e sistemática.
00:09:07O agente avaliador atua como o adversário do gerador. Seu trabalho é garantir que o app seja implementado corretamente, não fazendo
00:09:11uma busca genérica por erros, mas abordando-o criticamente sob a perspectiva de que bugs existem. Ele pode usar ferramentas como o PlayWright
00:09:18para testar o app simulando interações do usuário, identificar bugs com base em critérios predefinidos e enviar o feedback de volta ao gerador.
00:09:21Ao ler o plano, o avaliador obtém uma compreensão clara do que deve ser o resultado final e verifica tudo minuciosamente antes de aprovar.
00:09:30Cada framework possui seu próprio validador, mas as abordagens diferem significativamente. O BMAD usa agentes especializados de revisão
00:09:39de código e QA que geram e executam testes, avaliando o código sob múltiplos ângulos. O GSD usa um subagente verificador
00:09:46que checa a implementação contra o plano existente e produz um relatório de documentação. O Superpowers conta com novos subagentes
00:09:50e impõe um TDD rigoroso, onde nenhum código pode ser escrito antes dos casos de teste. Se o agente tentar ignorar isso, ele é bloqueado.
00:09:57O SpecKit trata as especificações como a fonte da verdade e permite que o agente verifique o código contra a documentação.
00:10:04Mas nenhum desses frameworks fornece um mecanismo de pontuação com o nível de rigor que a Anthropic buscava. Portanto,
00:10:10o avaliador no suporte da Anthropic é o mais próximo da aplicação rigorosa de Ralph Loop para o Claude, garantindo que o agente realmente
00:10:13entregue o que é necessário com um mecanismo de avaliação devidamente graduado. Além disso, se você estiver gostando do nosso conteúdo,
00:10:18considere apertar o botão de "hype", pois isso nos ajuda a criar mais conteúdos como este e a alcançar mais pessoas. O agente não tem meios
00:10:24de saber qual é o resultado certo para você, especialmente em casos onde a implementação não é quantificável. Portanto,
00:10:35você usa mecanismos de avaliação graduados para que eles saibam qual é o resultado ideal para você. Quando a Anthropic deu um exemplo
00:10:43das métricas de avaliação para o front-end, eles mencionaram que a IA tende a convergir para resultados semelhantes na maioria das vezes.
00:10:49Eles estabeleceram quatro critérios de avaliação tanto para o agente gerador quanto para o avaliador. O primeiro é a qualidade do design,
00:10:54instruindo-o a verificar se o campo é coerente ou apenas componentes separados agrupados. Depois, a originalidade,
00:11:02que é um dos principais, porque a IA tende a usar por padrão o mesmo padrão de gradiente roxo e branco para a maioria das UIs.
00:11:06Isso vai contra a forma como os humanos desenham, porque para um humano, cada escolha de design é deliberada e isso torna fácil
00:11:12identificar quando o site não parece bom. O terceiro é o acabamento: os pequenos detalhes como tipografia, consistência de espaçamento
00:11:19e harmonia de cores, onde a taxa de contraste é tecnicamente equilibrada em vez de dar um visual mais criativo. E o último é a funcionalidade,
00:11:27porque em termos de UI, cada componente desempenha um papel visual na melhoria da experiência do usuário. O Claude já pontua bem
00:11:37em acabamento e funcionalidade, mas os outros pontos são as dificuldades mais comuns, e os prompts precisam levá-lo ao seu melhor
00:11:44enfatizando que o melhor design vem da qualidade. Portanto, ao construir seu app, você pode configurar critérios semelhantes para quantos
00:11:54recursos desejar, como arquitetura de código, front-end, fluxos de usuários de UX e muito mais. Faça com que cada parte mencionada
00:12:02nos critérios tenha uma pontuação dedicada para que o modelo identifique sua importância com base em quão bem ele atua.
00:12:10Esses arquivos são referenciados no agente avaliador porque o trabalho do avaliador é pontuar, então ele sabe qual rubrica deve seguir.
00:12:17Dado tudo o que cobrimos, você pode se perguntar o que deve realmente fazer agora. Se você quer um framework para facilitar sua configuração,
00:12:21vá de GSD, porque o GSD inerentemente usa o ciclo planejador-gerador-avaliador por padrão, mas seu avaliador apenas compara o código
00:12:35com os planos existentes e conta com testes de aceitação do usuário. Ele usa um mecanismo de passar ou falhar, não uma implementação
00:12:49pontuada. Portanto, você pode pegar as melhores partes do framework da Anthropic e combiná-las com o GSD, por exemplo,
00:12:58alterando o agente avaliador e combinando-o com os critérios para que o agente saiba qual é a implementação correta. Mas se você quiser
00:13:03usar o framework da Anthropic e configurá-lo por conta própria, pode implementá-lo criando agentes baseados em seus respectivos papéis
00:13:10e fazê-los trabalhar juntos usando equipes de agentes. Você pode usar um membro da equipe de agentes como gerador e outro como avaliador.
00:13:24A razão para usar equipes de agentes é que eles podem se comunicar entre si, enquanto subagentes não podem e teriam que escrever
00:13:33em um documento, criando um excesso de trabalho. Portanto, o Claude cria as tarefas a partir do plano de alto nível e cria ambos os agentes
00:13:43ao mesmo tempo, onde um está implementando enquanto o outro está executando testes usando o Playwright MCP com o navegador, aguardando
00:13:48atualizações do gerador para que possa iniciar o processo de teste. O avaliador continua verificando o trabalho e comunica os problemas
00:13:57ao gerador e eles trabalham em coordenação para implementar todo o aplicativo que corresponda aos seus padrões. Agora, todos os agentes