O e-mail que dividiu equipes de engenharia

Boris Cherny, criador do Claude Code na Anthropic, recebe diariamente mensagens de desenvolvedores com a mesma dúvida: como lidar com código gerado por IA quando metade da equipe confia cegamente e a outra metade rejeita por completo?

Em 12 de setembro de 2026, ele publicou no X a resposta a um e-mail que capturou bem o dilema. O desenvolvedor anônimo descrevia dois campos em conflito:

Campo 1 — código revisável: "Criamos código similar ao anterior, acelerado por IA. Pode não ser revisado completamente, mas deveria ser revisável. A pessoa que submete o código deveria conseguir explicá-lo."

Campo 2 — caixa-preta: "Não nos preocupamos com a revisão. Apenas verificamos o resultado. O código pode ser incompreensível — tudo bem, desde que funcione."

O desenvolvedor relatou que muitos colegas adotam a segunda abordagem por pressão de prazo, com medo de que isso gere consequências na carreira.

Dois contextos, dois padrões para código gerado por IA

A resposta de Cherny não escolheu um lado — mas separou claramente os contextos:

Para protótipos descartáveis: o tratamento como caixa-preta é aceitável quando "o código será descartado em breve e nada quebra gravemente quando falha". A rastreabilidade importa menos quando o raio de impacto é baixo.

Para código de produção: "Código de produção escrito por Claude deveria ter padrão mais alto do que se fosse escrito por humano." A razão é direta: quando a IA gera código, o desenvolvedor não passa pelo processo mental de entender cada linha — o que significa que erros sutis passam invisíveis.

Na Anthropic, o código gerado por IA em produção passa por um pipeline obrigatório: linting automatizado, testes abrangentes, fuzzing contínuo e revisão assistida por IA. Nenhum desses passos é opcional. Estudos clássicos de engenharia de software indicam que bugs detectados em produção custam em média 10x mais para corrigir do que na fase de revisão de código — e com IA gerando mais código mais rápido, esse custo escala proporcionalmente.

Por que isso importa para o seu negócio

A mudança que Cherny descreve é profunda: o desenvolvedor moderno deixou de ser quem digita código para ser quem garante a qualidade do código gerado por IA.

Essa virada tem implicações diretas para qualquer empresa incorporando ferramentas de IA no time de tecnologia:

Primeiro, revise seus critérios de code review. Se o time aceita código gerado por IA sem revisão estruturada, o risco técnico cresce silenciosamente. O pull request que "funciona nos testes" não é suficiente.

Segundo, invista em automação de qualidade. Linting, cobertura de testes e fuzzing não são luxo — são o mínimo para rodar IA em produção de forma responsável. Esses investimentos pagam dividendos mesmo sem IA.

Terceiro, reconheça o novo perfil de senioridade. O engenheiro mais valioso não é o que escreve código mais rápido — é o que sabe direcionar a IA, validar a saída e rejeitar o que não presta. Esse é o gerente de qualidade que Cherny descreve.

A discussão reflete uma mudança documentada no setor: conforme o relatório de risco da METR sobre agentes de fronteira, a qualidade do output depende diretamente da qualidade do direcionamento humano — seja um prompt ou uma spec técnica.

Para empreendedores, a mensagem prática é clara: adotar código gerado por IA sem critérios de qualidade definidos é o mesmo que contratar um desenvolvedor júnior e não revisar nenhum pull request. A velocidade é real — mas o custo oculto também.

Conteúdo reescrito e traduzido para PT pela redação luiscortex, revisado por humano.

Fonte: Google News — AI (EN)