Agentes de IA de código rápidos e baratos podem custar caro em revisão, aponta teste com Composer 2.5

O relato vem de um desenvolvedor que trabalha com monorepos complexos e acumulou mais de 100 horas com o Composer 2.5, no Cursor. A escolha tem motivo prático: nos planos de US$ 20, o limite de 5 horas do gpt-6.1-sol acaba em poucas requisições, e o gpt-6.1-luna é, segundo ele, dezenas de vezes mais lento. O Composer 2.5 é rápido e barato, mas cobra a conta em revisão.

Os problemas se dividem em grupos. Na remoção, o agente apaga funções, comentários e parâmetros de configuração sem relação com a tarefa, e deixa o método antigo como deprecated em vez de refatorar. Na replicação de um serviço de referência (eventos, banco e Redis), esquece etapas, erra nomes e duplica centenas de linhas de métodos compartilhados. Nos testes, muda o código antes de criar o teste, força falha alterando um campo do resultado esperado, desativa a validação de schema e escreve direto no banco em vez de chamar a rota da API. Skills e regras são lidas, mas seguidas de forma irregular. O autor ressalva que não sabe se os modelos mais novos têm os mesmos defeitos.

O caso é uma nova evidência de um tema que o CEVIU já acompanhava, não a evolução de um mesmo produto. Em 9 de março de 2026, o CEVIU noticiou "A Maioria dos Agentes de Codificação Invalida Mais de 75% de Suas Próprias Correções com o Tempo". Em 16 de junho de 2026, saiu "Engenheiros seniores gastam até 1/3 da semana corrigindo código gerado por IA", e em 17 de junho de 2026, "Revisões de código ficaram caras, e reescritas, baratas: o paradoxo da IA no desenvolvimento". Agora há um relato de uso real, com exemplos concretos do custo da revisão.

Para quem adota agentes baratos e rápidos, a leitura é que o custo por token não mede o custo total. Se cada entrega exige revisar arquivo por arquivo, conferir o git diff e checar se o teste realmente exercita a rota, a economia some no tempo do desenvolvedor. Teste verde, nesse cenário, não prova que a tarefa foi concluída.