Loops de feedback: ajude o Claude Code a concluir tarefas ambiciosas com menos supervisão

À medida que delegamos tarefas mais ambiciosas ao Claude, torna-se cada vez mais importante que ele verifique seu próprio trabalho.

Quanto mais o Claude puder se autoverificar:

• mais independentemente ele poderá trabalhar em tarefas de longa duração
• melhor será a qualidade do resultado final
• menos idas e vindas serão necessárias para chegar lá

Quando as verificações dependem de você, as sessões de codificação se tornam um jogo de turnos, e você perde o que torna os agentes úteis: autonomia.

A boa notícia é que o Claude já se autoverifica contra sinais determinísticos como erros de tipo, erros de lint, testes falhando e erros em tempo de execução. E, conforme os modelos melhoram, isso só vai melhorar.

O que o Claude nem sempre consegue inferir são as verificações manuais que você executa após ele responder e, mais tarde, antes de mesclar o código em produção.

Quanto mais dessas verificações você puder codificar, mais a primeira resposta do Claude se aproximará do resultado final que você tinha em mente.

Você gasta menos tempo monitorando, e o Claude pode continuar enquanto você trabalha em outra coisa.

Escreva seus processos

Um bom lugar para começar é escrever a versão de melhores práticas do que você ou sua equipe já fazem.

Para frontend, geralmente é: iniciar o servidor de desenvolvimento, abrir o navegador, verificar o console em busca de erros, navegar como o usuário faria e observar coisas como mudanças de layout ou navegações lentas.

Cada domínio tem sua própria versão. Para cada uma dessas etapas, provavelmente existe uma ferramenta que o Claude pode usar para verificação:

Codifique seu processo como uma skill

Assim que o processo estiver claro, codifique o máximo possível dele como uma skill. Instale o plugin skill-creator e peça ao Claude para entrevistá-lo:

1/skill-creator Crie uma skill para verificar alterações de frontend de ponta a ponta. Entreviste-me sobre meu fluxo de trabalho.

Se você está com dificuldade para colocar seu processo em palavras, peça ao Claude as melhores práticas do domínio primeiro e deixe que ele mostre como seria um fluxo de verificação de ponta a ponta.

Gosto e julgamento são difíceis de codificar, mas muitas verificações têm critérios que o Claude pode medir: um orçamento de performance, uma lista de verificação de acessibilidade, regras de sistema de design, exemplos bons vs ruins.

Por exemplo, uma skill de frontend pode incluir instruções para capturar um trace de performance através do Chrome DevTools MCP ou Agent browser.

1---
2name: frontend-verify
3description: Verifique alterações de frontend em um navegador. Execute sempre que uma alteração de UI (página, componente, tipografia, estilo CSS) for feita.
4---
5
6# Verificação de frontend
7
8- Execute uma passagem de verificação em duas etapas em um navegador real.
9- Corrija problemas e reverifique antes de responder ao usuário.
10
11## Etapa 1 — Verifique se a alteração se comporta como esperado
12
131. Abra a URL em um navegador:
14   - No aplicativo de desktop Claude Code, use a pré-visualização incorporada.
15   - No CLI, use o Chrome DevTools MCP.
162. Interaja com o novo elemento e confirme se ele renderiza e se comporta como esperado.
17
18## Etapa 2 — Verifique se a alteração passa em uma auditoria mobile
19
201. Abra a URL em uma nova página através do Chrome DevTools MCP
212. Execute um trace de performance e audite os Core Web Vitals

Outras verificações são mais qualitativas do que aprovado/reprovado, como comparar dados com normas históricas. Para essas, você pode trabalhar com o Claude para definir uma rubrica para avaliar a saída.

Revise o código antes de mesclar com um segundo agente

Tudo acima acontece dentro do loop agentivo. Há uma segunda etapa de verificação, o momento antes de você mesclar, onde você pode pedir a outro agente para revisar.

Um novo agente não carregará os mesmos vieses que aquele que escreveu o código. Ele tem seu próprio contexto e não é influenciado pela conversa anterior. Esse isolamento torna a revisão mais honesta e captura coisas que o primeiro agente pode ter perdido.

Algumas opções, de manual a automatizada:

• /review (skill embutida) - uma leitura rápida de passagem única de um PR no seu terminal.
• /code-review (plugin instalável) - inicia vários subagentes em paralelo, cada um lendo o diff de um ângulo diferente, pontua descobertas por confiança e publica o resultado no PR.
• Claude Code Review - um serviço gerenciado que é executado automaticamente em cada PR através do GitHub, para planos Team e Enterprise.

Qualquer que você escolha, é útil ter uma última linha de defesa antes de mesclar em produção.

Juntando tudo

Você agora tem duas camadas:

• verificação que executa enquanto o Claude está construindo
• uma revisão antes da mesclagem de um agente que não escreveu o código.

Ambas pertencem ao mesmo ciclo de vida de desenvolvimento. Pense nos seus passos manuais atuais: você faz uma alteração, limpa, confirma que funciona, commita, abre um PR, obtém revisão e observa o CI.

Você pode agrupar todos esses passos em um único fluxo de trabalho escrevendo uma skill que chama outras skills. Por exemplo, a equipe do Claude Code tem uma skill que eles executam ao trabalhar em funcionalidades, que agrupa:

1. A skill /simplify para limpar o diff
2. Uma skill personalizada /verify para confirmar que a alteração funciona de ponta a ponta
3. Uma verificação de design se o diff tocou na UI
4. Uma etapa para abrir e se inscrever em um PR
5. Uma skill para monitorar o CI e corrigir falhas conforme elas aparecem

Embora seu fluxo de trabalho possa ser diferente, criar loops de feedback e agrupar skills permite que o Claude verifique e execute mais trabalho de ponta a ponta.