Executando o Claude Code como um Motor de Julgamento Puro em Todo o Ciclo de Vida do Desenvolvimento de Software

Um desenvolvedor no r/ClaudeAI detalhou sua configuração de meses usando o Claude Code (o runtime com uso de ferramentas e loop multi-turn) em todo o ciclo de vida de desenvolvimento de software — tickets, implementação entre repositórios, revisão de código, MRs e uma camada de conhecimento persistente.

Decisão arquitetural chave: Manter o Claude Code fora da orquestração. Python puro lida com todo o trabalho mecânico: chamadas à API do Jira, operações git, execução de testes, lint, movimentação de arquivos. O Claude Code é invocado apenas para julgamento — escrever código, avaliar descobertas de revisão, escolher entre opções arquiteturais. O autor descobriu que misturar os dois (deixando o agente orquestrar via uso de ferramentas) tornou a primeira versão lenta, cara e não determinística.

Ciclo de vida concreto de um ticket:

• Orquestrador Python: Puxa o ticket do Jira, pesquisa no wiki local por decisões arquiteturais relacionadas, configura uma worktree em uma branch nova, monta um resumo de implementação de 30 a 50 linhas (critérios de aceitação, arquivos alvo, chamadores de funções compartilhadas modificadas, padrões relevantes). Gera um pacote JSON.
• Claude Code: Lê o resumo e escreve o código. Esta é a única etapa com consumo significativo de tokens.
• Python + subagente de revisão: Executa testes, lint, formatação. Em caso de falha, retorna ao agente de implementação (máximo de 3 tentativas). Em seguida, despacha um subagente de revisão de código configurado com nenhuma permissão de Editar ou Escrever — ele só pode ler e relatar descobertas.
• Python: Cria uma proposta em um painel. Após aprovação manual, o orquestrador faz push e cria o MR.

Técnicas específicas do Claude Code que importaram:

• Isolamento de subagentes. O agente de revisão roda em sua própria janela de contexto com uma lista de negação (Editar, Escrever). Separar revisão e implementação capturou mudanças comportamentais em código compartilhado que o agente de implementação continuava perdendo.
• Briefings pré-montados superam exploração dinâmica. No início, deixar o Claude Code explorar o código antes da implementação consumia visivelmente mais tokens do que entregar um briefing focado montado pelo Python (busca no Jira, pesquisa no wiki, análise de dependências).
• Roteamento de habilidades/comandos via YAML em vez de deixar o agente decidir. O mapeamento de /ticket, /review, /standup etc. para orquestradores é explícito, então as capacidades são inspecionáveis em vez de emergentes.
• Hooks bloqueiam commits. Um hook pre-commit executa lint e formatação antes de qualquer commit que o Claude Code tente. Violações bloqueiam o commit; o agente deve corrigi-las.

Camada Wiki: Páginas Markdown com três níveis de confiança (verificado, inferido, fornecido por humano) e limites de desatualização por campo. Sem a hierarquia, os agentes tratam suas próprias inferências passadas como verdade e compõem alucinações em conhecimento com aparência autoritativa.

Dificuldades ainda sendo enfrentadas:

• Funcionalidades entre repositórios: o agente perde coerência quando uma funcionalidade abrange serviços, mesmo com rastreamento estruturado de conjuntos de mudanças.
• Tickets vagos: o agente produz implementações razoáveis mas frequentemente erradas a partir de especificações ambíguas. O autor agora marca tickets ambíguos como bloqueadores.
• Escopo excessivo: o instinto de superengenharia requer calibração constante por meio de padrões e do agente de revisão.
• Sessões longas: contexto anterior sai do alcance de atenção efetiva; a reinicialização no início da sessão mitiga mas não elimina o problema.