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 auto-verificar:

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

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

A boa notícia é que o Claude já se auto-verifica contra sinais determinísticos como erros de tipo, erros de lint, testes com falha e erros em tempo de execução. E à medida que os modelos melhoram, isso só vai melhorar.

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

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

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

Documente seus processos

Um bom ponto de partida é documentar a versão de melhores práticas do que você ou sua equipe já fazem.

Para frontend, geralmente é: executar o servidor de desenvolvimento, abrir o navegador, verificar o console em busca de erros, clicar como o usuário faria e ficar atento a 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

Depois 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ê estiver tendo dificuldades para colocar seu processo em palavras, peça primeiro ao Claude as melhores práticas do domínio 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 do 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: Verificar 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 verificação em duas etapas em um navegador real.
9- Corrija problemas e re-verifique antes de responder ao usuário.
10
11## Etapa 1 — Verificar se a alteração se comporta conforme o 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 que ele renderiza e se comporta conforme o esperado.
17
18## Etapa 2 — Verificar se a alteração passa em uma auditoria móvel
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 mesclar, onde você pode pedir a outro agente para revisar.

Um novo agente não carregará os mesmos vieses daquele 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, do manual ao automatizado:

• /review (skill integrada) – uma leitura rápida 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 os achados por confiança e publica o resultado no PR.
• Claude Code Review – um serviço gerenciado que é executado automaticamente em cada PR via GitHub, para planos Team e Enterprise.

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

Juntando tudo

Você agora tem duas camadas:

• verificação que é executada 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 nas suas etapas manuais atuais: você faz uma alteração, limpa, confirma que funciona, commita, abre um PR, obtém revisão e acompanha o CI.

Você pode agrupar todas essas etapas em um único fluxo de trabalho escrevendo uma skill que chama outras skills. Por exemplo, a equipe do Claude Code tem uma skill que executa ao trabalhar em funcionalidades, que inclui:

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 afetou a UI
4. Uma etapa para abrir e se inscrever em um PR
5. Uma skill para acompanhar o CI e corrigir falhas à medida que 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.