Quando eu rejeito código de IA mesmo quando ele funciona

Quando código “funcionando” ainda é rejeitado

• Muitos argumentam que “ele roda e os testes estão verdes” é apenas um critério mínimo.
• Motivos comuns para rejeição: não conseguir explicar a abordagem, o diff ser maior que o problema, abstrações prematuras, raciocínio/manutenibilidade mais difíceis, ou confiar mais na saída da IA do que na própria compreensão.
• Vários observam que isso é idêntico a como bons revisores deveriam tratar código escrito por humanos (por exemplo, de juniores ou contratados).

Risco, responsabilidade e domínios

• É exigido maior rigor para sistemas críticos para segurança ou de alto valor (pagamentos, infraestrutura, backends centrais) do que para ferramentas internas, projetos hobby ou sites estáticos simples.
• Expectativas de plantão e suporte: se você não consegue depurar ou explicar o código às 3 da manhã, não deveria colocá-lo em produção.
• Alguns consideram antiético fazer merge de código de IA que não revisaram de verdade em sistemas críticos.

Qualidade do código gerado por IA

• Reclamações frequentes: abstrações excessivas, overengineering, utilitários duplicados, colunas/campos desnecessários, munging de dados no front-end em vez de uso adequado do backend/DB e “code salad” em domínios complexos.
• Os LLMs são descritos como aumentando a entropia, divergindo em vez de convergir sem fortes restrições.
• Bugs sutis (por exemplo, vazamento de dados em ML, casos-limite de contabilidade) são fáceis de passar despercebidos pela IA e difíceis de detectar por novatos.
• Outros contrapõem que agentes médios já superam muitos programadores “enterprise” em estrutura básica e limpeza.

Fluxos de trabalho e guardrails

• Alguns constroem harnesses elaborados: linters personalizados para “AI-isms”, verificações rígidas de pre-commit, TDD imposto por scripts, revisão cruzada com múltiplos modelos e auditorias periódicas assistidas por IA.
• Outros usam IA principalmente como um pair programmer: planos, pequenos trechos, ajuda com sintaxe, porting entre linguagens/frameworks ou expansão de pseudocódigo em nível de comentários.
• Alguns assumidamente fazem merge de código de IA que não entendem completamente, confiando em testes e na reação rápida a falhas; outros classificam isso como arriscado ou irresponsável.

Dinâmicas organizacionais e incentivos

• Incentivos ruins já existentes—recompensar commits grandes e rápidos e comportamento cowboy—são vistos como amplificados pela IA, levando a uma acumulação mais rápida de dívida técnica.
• Alguns preveem falhas no estilo “falência de software”, ou ao menos entrega mais lenta, alta rotatividade de seniors e tentativas de reescrita que também podem falhar.

Meio-termo e preocupações de longo prazo

• Debate sobre se existe um “meio-termo” estável entre nenhum uso de IA e desenvolvimento totalmente agentic.
• Preocupações com deskilling, dívida de compreensão e futuros sistemas que ninguém entende.
• Outros veem a IA como um “teclado mais rápido” e argumentam que a verdadeira limitação continua sendo a compreensão e a arquitetura humanas, que não devem ser terceirizadas.