Claude Code no trabalho de plataforma: o que mudou depois de 6 meses de uso real
Seis meses usando Claude Code como ferramenta diária de trabalho em platform engineering — não como curiosidade, mas como colaborador. O que mudou, o que permaneceu e onde ainda prefiro trabalhar sem ele.
Seis meses de Claude Code como ferramenta diária. Não testando — usando. Em código que vai para produção, em infraestrutura que serve centenas de engenheiros, em decisões que têm consequência real.
O que posso dizer com dados é diferente do que eu poderia dizer com impressões iniciais.
O primeiro mês foi de descoberta de padrão. Eu testava tudo: Terraform, Go, scripts de automação, análise de logs, revisão de PRs. A qualidade era variável — excelente em algumas áreas, fraca em outras. O que ficou claro: o resultado é função da qualidade do contexto que você fornece, não só da qualidade da tarefa.
Em Terraform, por exemplo, o resultado é consistentemente bom quando eu descrevo o estado atual do módulo, as restrições de compatibilidade e o que quero adicionar. Quando digo apenas "adicione um recurso de autoscaling", o resultado tecnicamente correto ignora as especificidades da nossa conta — limites de instância, tags obrigatórias, nomenclatura dos nossos módulos internos. O Claude Code não tem esse contexto a menos que eu forneça.
O padrão que desenvolvi: antes de qualquer tarefa de infraestrutura, eu escrevo um parágrafo de contexto. Não como comentário de código — como prompt de trabalho. "Estamos no módulo X, que usa o provider Y na versão Z. Temos convenções de nomenclatura W. A restrição é R. O que quero é Q." Isso parece overhead. Na prática, economiza 80% das iterações de correção.
A segunda descoberta foi sobre tarefas de análise. Claude Code é muito bom em raciocinar sobre logs, traces e métricas quando você mostra o dado. "Aqui está o stack trace, aqui está a configuração do serviço, aqui está o comportamento esperado — o que pode estar errado?" Esse ciclo de apresentar dado + contexto + hipótese é mais rápido do que muitas sessões de debugging que eu faria sozinho.
Mas há um limite claro: o raciocínio é sobre o que está visível. Se o problema é um comportamento de rede que só aparece sob carga específica, ou um race condition que depende de timing não reproduzível em logs, ou um efeito de calor em hardware específico — o Claude Code não vai encontrar porque não tem acesso ao estado real do sistema em tempo de execução.
Onde prefiro trabalhar sem ele: decisões de arquitetura que envolvem múltiplos times e contexto político. Não porque o Claude Code seja ruim em arquitetura — é bom. Mas porque essas decisões dependem de relacionamentos, de histórico de conflitos entre times, de dívida política que não está em nenhum documento. Ele me ajuda a estruturar as opções técnicas, mas a decisão final exige contexto humano que só eu tenho.
Também prefiro trabalhar sem ele em code reviews de impacto alto. Ele é excelente para encontrar bugs e inconsistências de estilo. Mas code review de impacto alto é uma oportunidade de conversa sobre design — de perguntar "por que você fez assim?" e criar espaço para o autor pensar em voz alta. Isso é desenvolvimento de pessoas, não análise de código.
O que mudou de forma mais profunda não é a velocidade de escrita de código. É a disposição de explorar. Antes, quando eu tinha uma ideia de automação que levaria 3 horas para implementar, eu avaliava: vale 3 horas? Muitas ideias boas eram descartadas por esse filtro de custo de implementação. Agora o filtro é diferente: vale 1 hora de contexto + revisão? A barra caiu, e algumas ideias que ficavam na gaveta estão sendo testadas.
O lado não óbvio disso: algumas dessas ideias estão sendo testadas e confirmadas como ruins. O que antes eu descartava por intuição, agora às vezes eu implemento e descubro que a intuição estava certa. Isso tem valor — aprendo mais quando tenho evidência do que quando tenho apenas hipótese.
Essa semana: Se você usa Claude Code (ou similar), experimente este padrão por uma semana: antes de qualquer tarefa de código, escreva 3-4 frases de contexto sobre o sistema que você está tocando. Constraints, convenções, o que não deve mudar. Compare a qualidade do output com sessões sem esse contexto. O delta vai ser significativo.