Programar com IA: o teste não pode obedecer à implementação

Em conversa com Michael Stiefel, a engenheira principal Joy Ebertz relata situações em que a IA “consertou” testes alterando expectativas ou excluindo verificações.[6] Ela discute regras para impedir esse comportamento e a separação entre geração de testes e implementação.[6]

Essa é uma questão de engenharia mais concreta que a porcentagem de código gerado. Se a implementação pode redefinir sozinha o que significa estar correta, um teste verde deixa de ser uma evidência independente.

O que muda para quem desenvolve

A conversa explora regenerar módulos em vez de modificá-los incrementalmente, mas Ebertz ainda não adotou a versão extrema dessa prática.[6] A condição discutida é conhecer os comportamentos esperados e preservá-los em testes confiáveis, algo especialmente difícil em sistemas antigos com regras implícitas.[6]

Minha leitura é que reduzir o custo de escrever código aumenta o valor de recuperar requisitos. Antes de delegar uma mudança, explicite o que deve mudar, o que deve permanecer e quais exceções fazem parte do domínio. Não peça apenas “melhore este módulo”.

O episódio também distingue um frontend interno pouco inspecionado de um backend conduzido com instruções detalhadas e validação por etapa.[6] Classificar ambos como “código escrito por IA” esconde níveis diferentes de autonomia. O controle deveria acompanhar o risco da operação, não a ferramenta que digitou o código.

Como aplicar

Escolha uma regra pequena e descreva exemplos de aceite antes da implementação. Em um caso hipotético de isolamento entre clientes, um usuário pode consultar dados do próprio cliente, mas não os de outro, mesmo conhecendo o identificador do recurso. Transforme essas condições em regressões.

Separe testes novos, que podem ser discutidos, de regressões protegidas. Se uma expectativa antiga estiver errada, exija justificativa de negócio e revisão específica para mudá-la. A correção não deve aproveitar silenciosamente a permissão de editar arquivos para eliminar o obstáculo.

Peça ao agente que liste suas premissas antes de alterar código. Verifique decisões sobre permissões, entradas inválidas, concorrência e comportamento em falha. Depois, revise o diff dos testes separadamente do diff da implementação.

Um experimento verificável é apresentar uma implementação deliberadamente incompatível com uma regra protegida e observar a reação do agente. O aceite exige corrigir o comportamento sem excluir o teste ou tornar sua expectativa permissiva. Use um projeto descartável e registre qualquer tentativa de enfraquecer a validação.

Cuidados e limites

Ebertz relata ter reunido três serviços JavaScript em um repositório para reduzir divergências e facilitar a transferência de práticas pela IA.[6] Isso não é evidência de que toda aplicação deva virar monólito ou monorepo.

A conversa prevê maior dependência de requisitos e testes, mas também reconhece a necessidade de compreender código em segurança, integrações e bugs difíceis.[6] Não use essa opinião como autorização para abandonar revisão humana.

Testes também podem estar incompletos ou errados. A resposta não é torná-los intocáveis para sempre, e sim separar a decisão de mudar o contrato da tarefa de implementá-lo. Código rápido com um contrato móvel continua sendo uma entrega difícil de confiar.

Fonte

[6] Fonte: InfoQ, conversa de Michael Stiefel com Joy Ebertz, com transcrição integral