O Loop ShadCN É A Melhor Solução Para Sua UI Quebrada

O vídeo apresenta o problema central: embora o ShadCN seja uma das bibliotecas de interface mais populares, usar agentes de IA para desenvolver com ela é problemático. Páginas de destino simples funcionam bem, mas ao desenvolver aplicativos complexos ou implementar novas funcionalidades, as coisas quebram e afetam outras partes do aplicativo. Os agentes de IA testam o código que escrevem, mas se tornam não confiáveis com contextos grandes. A solução apresentada envolve o conceito de loops agênticos para garantir que os agentes completem o trabalho que lhes é dado.

O loop RALF é explicado como um novo plugin lançado pela Anthropic, baseado em uma técnica de outra pessoa e disponibilizado como código aberto. Funciona usando hooks de parada do Claude Code que são executados quando o Claude para de gerar uma resposta. Assim que para, o agente de IA recebe seu arquivo de prompt inicial novamente, permitindo que melhore seu trabalho iterativamente. O conceito de 'promessa de conclusão' é introduzido - uma palavra específica que o Claude emite quando sente que sua tarefa está concluída, fazendo com que o loop pare de executar.

Após instalar o plugin, três comandos ficam disponíveis: o comando do loop RALF, um comando de cancelamento e um comando de ajuda. No comando do loop, é necessário fornecer o prompt que é alimentado repetidamente ao agente. Uma prática recomendada importante é definir uma contagem máxima de iterações, pois o agente pode receber uma tarefa impossível e ficar preso em um loop infinito. O apresentador menciona que o repositório contém boas práticas para prompts, mas o vídeo focará especificamente no fluxo de trabalho de interface.

Dois recursos de exemplo são introduzidos: uma paleta de comandos e uma visualização em quadro no banco de dados. O desenvolvimento orientado a testes (TDD) é apresentado como a abordagem fundamental, onde os testes são escritos antes do código ser implementado. O Claude Code pode configurar a estrutura de TDD automaticamente, criando pastas de testes ponta a ponta e capturas de tela para verificação de interface. Na abordagem TDD, os testes iniciais sempre falham, depois escreve-se o código mínimo necessário para passar nos testes, e finalmente refatora-se enquanto garante que os testes ainda passem.

O vídeo esclarece que não está usando o MCP do Playwright para verificação autônoma através do navegador. Em vez disso, com TDD, para cada comportamento funcional, capturas de tela são tiradas automaticamente. Por exemplo, se o comportamento funcional é adicionar um cartão, a captura de tela mostraria um cartão adicionado ao quadro. O agente de IA precisa apenas olhar essas capturas de tela e garantir que não há problemas na forma como os componentes ShadCN foram implementados. Esses arquivos de teste garantem que todos os requisitos comportamentais sejam atendidos sempre que algo novo é adicionado.

Embora TDD seja útil, o loop RALF ainda é necessário porque com tarefas maiores e janelas de contexto quase cheias, os modelos desistem abruptamente de suas tarefas e exigem entrada humana constante. Com testes escritos antecipadamente para qualquer função desejada, o loop pode instruir o agente sobre o que fazer para trabalhar autonomamente. O prompt define qual fluxo de trabalho seguir e a condição para emitir a promessa de conclusão. No exemplo dado, a promessa é emitida quando o agente passa em todos os 25 testes únicos.

Usando o comando /ralf, foi dado um prompt para construir iterativamente o recurso da paleta de comandos. O prompt incluía requisitos básicos e delineava todo o fluxo de trabalho: começar rodando os testes (que sabidamente falharão), depois implementar os componentes para fazê-los passar. Se fosse uma tarefa mais ampla, quando a janela de contexto enchesse ou o Claude ficasse confuso, ele não emitiria a promessa de conclusão e o prompt seria realimentado, fazendo-o continuar trabalhando iterativamente. Como era uma tarefa menor, o agente conseguiu implementar tudo de uma vez, escrever todos os componentes e fazer todos os testes passarem.

Após os testes passarem, o fluxo de trabalho instruía o agente a revisar todas as capturas de tela da paleta de comandos em diferentes estágios para garantir que a interface estivesse implementada corretamente. Depois deveria rodar os testes novamente para garantir que ainda passassem após as mudanças de interface. Como tudo estava correto, o agente emitiu a promessa de conclusão. No entanto, um problema grande não foi notado neste recurso porque havia poucas chances de erros de interface. Ao implementar a visualização em quadro com o mesmo prompt, um erro enorme no sistema foi revelado.

Na implementação do quadro, o agente garantiu que todos os testes estavam passando, mas havia casos em que o número de testes bem-sucedidos diminuía porque ao mudar algo quebrava outra coisa, demonstrando a importância do TDD. O problema principal era que após o agente verificar que estava pronto, a interface tinha erros significativos que apareciam nas capturas de tela mas foram ignorados. O agente passou em todos os testes porque deveria rodar os arquivos de teste repetidamente, mas não havia teste específico para a interface além das capturas de tela. Ele deu uma olhada rápida em algumas capturas, ignorou erros de interface e até pulou alguns arquivos completamente.

Após brainstorming sobre como corrigir o problema usando as melhores práticas do repositório, chegaram a regras específicas e uma mudança no processo. A primeira foi o protocolo de verificação de capturas de tela: adicionar um prefixo simples a cada imagem dizendo ao Claude se ele havia lido a captura ou não. Na primeira implementação, ele ainda não lia todas as imagens - lia algumas, escrevia 'verified' nelas e desistia cedo. Para resolver isso, o prompt foi modificado para encorajar o agente a pensar diferente: após renomear todas as capturas de tela, não deveria emitir a promessa ainda, deixando a próxima iteração confirmar a conclusão, garantindo pelo menos dois loops.

Na próxima verificação, o Claude verifica se todos os arquivos têm o prefixo 'verified'. Isso exigiu separar a verificação de imagem dos testes funcionais. A próxima iteração garante que todas as imagens tenham resultados verificados e se o Claude perder alguma, olha para elas novamente e corrige a saída. Com essa mudança, os pequenos erros de interface foram finalmente corrigidos e o agente implementou todos os recursos corretamente. No próximo loop, rodou os testes novamente, encontrou alguns erros, os corrigiu e porque todos os arquivos tinham a palavra 'verified', rodou um teste final. A tarefa foi completada em dois loops com todos os principais erros de interface corrigidos.

O vídeo conclui com uma promoção da Automata, a empresa do apresentador que implementa esses fluxos de trabalho de IA para construir produtos. Após ensinar milhões de pessoas como construir com IA, descobriram que podiam construir produtos melhores mais rápido do que nunca. A Automata ajuda a dar vida a ideias, sejam aplicativos ou sites, servindo como copiloto técnico para quem tem ideias mas não tem equipe técnica. Aplicam os mesmos fluxos de trabalho ensinados a milhões diretamente aos projetos dos clientes, transformando conceitos em soluções funcionais sem as dores de cabeça de contratar ou gerenciar equipe de desenvolvimento. Informações de contato e agradecimentos encerram o vídeo.