Uso intenso de IA para programar pode gerar uma codebase frágil

O texto publicado no evanxmerz.com vem de um engenheiro que diz ter sido demitido da Meta em maio e que hoje gera 100% do código com IA, porque é a expectativa no emprego atual. Ele lista quatro mecanismos de fragilidade. Testes rasos: agentes escrevem muitos testes de get/set e e2e que só cobrem casos já cobertos, deixando lacunas que a métrica de cobertura por linha não mostra. Código complexo demais: dois ou três métodos auxiliares onde um bastaria, e DRY aplicado ao extremo, o que dificulta depuração. Menos compreensão humana da codebase. Velocidade: cada pull request chega mais rápido que o anterior e tem menos tempo de revisão.

O autor também descreve sintomas: mais incidentes (p0 e SEVs em sequência), recuperação mais lenta porque os humanos conhecem menos o código, e erros que só os usuários enxergam, já que ninguém garante a instrumentação de analytics e o tratamento de erros. Um exemplo concreto que ele dá: um bom programador tentou fazer merge de código com eventos JavaScript para efeitos de mouseover, em vez do seletor :hover do CSS. Vale lembrar que é um relato de experiência pessoal, sem dados medidos.

O tema já vinha sendo coberto. Em 26 de março de 2026, o CEVIU publicou "Reflexões sobre a importância de desacelerar ao programar", sobre agentes que amplificam erros e carecem de pontos de verificação humanos. Em 24 de julho de 2026, veio "Qualidade do código em xeque: O impacto da IA no desenvolvimento de software", e em 8 de setembro de 2026, "O Abismo da IA: Por Que Codebases Escondem Falhas Profundas?". Em 5 de novembro de 2026, o teste com o Composer 2.5 mostrou agentes rápidos fazendo testes passarem sem exercitar o comportamento pretendido. O novo texto não traz fato novo sobre um produto, mas soma um relato em primeira pessoa e uma lista de sintomas operacionais (incidentes, tempo de recuperação) a um debate que já tinha o lado da qualidade e da revisão.

Para quem revisa código, a leitura é que o gargalo deixou de ser escrever e passou a ser entender e verificar. Se a sua cobertura por linha está alta mas os testes só repetem caminhos já cobertos, o número engana. Vale olhar métricas de incidente e tempo de mitigação junto com a cobertura, além de reservar tempo de revisão proporcional ao volume que os agentes geram.