A velocidade para gerar código pode desaparecer quando equipes precisam revisar, corrigir e integrar uma quantidade maior de mudanças.
Agentes de programação conseguem ler arquivos, alterar várias partes de um projeto, executar testes e abrir pull requests a partir de uma instrução. A promessa é reduzir o tempo entre uma ideia e uma implementação. Uma análise publicada pela Ars Technica apresenta um contraponto essencial: organizações passaram a produzir mais linhas, commits e pull requests, mas isso não se transformou automaticamente em mais software entregue.
O motivo está em uma etapa menos chamativa do desenvolvimento. O código precisa ser revisado por pessoas, testado, ajustado e integrado ao produto. Quando a geração acelera e a revisão não acompanha, o gargalo apenas muda de lugar. Para profissionais brasileiros que usam Copilot, agentes de código ou ferramentas semelhantes, a notícia oferece uma forma concreta de avaliar produtividade: medir o que chega ao usuário, não apenas o que foi produzido no repositório.
O que diferencia um assistente de um agente
Um assistente de código costuma sugerir trechos enquanto o programador trabalha. A pessoa mantém o contexto, escolhe aceitar ou rejeitar a proposta e continua responsável por organizar a mudança. Um agente recebe uma tarefa mais ampla e pode executar várias etapas. Ele lê arquivos, escolhe uma abordagem, altera diferentes partes do projeto e tenta validar o resultado.
A autonomia economiza tempo em tarefas bem definidas, como criar testes repetitivos, atualizar chamadas de uma biblioteca ou gerar uma estrutura inicial. Também amplia o risco de uma mudança grande demais. O agente pode interpretar uma instrução de maneira literal, alterar uma dependência importante ou resolver um problema local criando uma dívida técnica que aparece depois.
A diferença não está apenas no modelo usado. Permissões, ferramentas, contexto, regras do repositório e processo de revisão determinam o que o agente consegue fazer. Um sistema bem configurado restringe acesso, registra ações e pede confirmação para operações perigosas. Um sistema aberto demais transforma uma tarefa simples em uma sequência de mudanças difíceis de rastrear.
Os números mostram uma troca de gargalo
Segundo a Ars Technica, o estudo analisado reuniu dados de centenas de empresas e observou centenas de milhões de eventos de trabalho. Depois da adoção de agentes de código, a quantidade de linhas geradas aumentou cerca de 30%, os commits subiram 20% e os pull requests cresceram 23%. Esses dados mostram atividade, mas não provam que o produto ficou melhor ou que mais funcionalidades chegaram ao usuário.
O tempo médio entre a abertura e a integração de um pull request aumentou 49%. Também cresceram a proporção de solicitações que pediam mudanças e o número de comentários por pull request. A consequência é intuitiva: quanto mais alterações chegam para revisão, mais tempo uma equipe precisa gastar entendendo o que mudou, verificando os testes e avaliando efeitos colaterais.
Esse resultado não significa que agentes de código sejam inúteis. Significa que a velocidade da geração depende da capacidade de absorção do restante do processo. Uma equipe pode escrever dez vezes mais rápido e ainda entregar no mesmo ritmo se o teste, a revisão, a documentação ou a aprovação permanecerem iguais.
Por que mais código pode ser um problema
Código é uma forma de manutenção futura. Cada função criada precisa ser entendida, testada e atualizada. Quando um agente produz uma solução mais longa do que o necessário, o custo não aparece apenas no pull request. Ele pode reaparecer quando outra pessoa corrigir um bug, trocar uma biblioteca ou investigar um incidente.
Também há uma questão de coerência. Um projeto tem padrões de nomes, arquitetura, tratamento de erros e segurança. O agente conhece apenas o contexto fornecido. Se a equipe aceitar mudanças sem uma revisão cuidadosa, partes diferentes do sistema podem seguir regras incompatíveis. A quantidade de commits sobe, mas o projeto fica mais difícil de navegar.
Para sistemas que lidam com pagamentos, dados pessoais ou serviços essenciais, o risco é maior. Um teste que passa não garante que a permissão está correta, que o log não expõe informações ou que a entrada foi validada. A revisão humana precisa olhar para o comportamento e para o contexto do produto, não apenas para a sintaxe.
Revisão de código precisa mudar junto
A primeira reação de uma empresa pode ser pedir que revisores trabalhem mais rápido. Isso cria pressão sem resolver o problema. A revisão precisa receber ferramentas que ajudem a organizar mudanças, agrupar arquivos relacionados, indicar áreas de maior risco e mostrar quais testes foram executados.
Uma política útil também define o tamanho máximo de uma tarefa entregue ao agente. Mudanças menores são mais fáceis de revisar e reverter. O agente pode preparar um pull request para cada unidade lógica, explicar decisões e apontar trechos que não conseguiu validar. A equipe deve ser capaz de rejeitar a alteração sem perder horas tentando descobrir o que aconteceu.
Testes automatizados ajudam, mas não devem ser escritos apenas pelo mesmo agente que produziu o código. Se o modelo repetir o mesmo entendimento errado, os testes podem confirmar a falha em vez de encontrá-la. Revisões independentes, análise estática e testes de segurança ampliam a chance de detectar problemas diferentes.
Como medir produtividade de verdade
Linhas de código, commits e pull requests são métricas de atividade. Elas ajudam a acompanhar o processo, mas não representam sozinhas o resultado. Uma equipe deve observar tempo para concluir uma funcionalidade, quantidade de falhas após a entrega, retrabalho, tempo de revisão, facilidade de manutenção e satisfação de quem usa o produto.
Também é importante separar tarefas. Um agente pode ser excelente para migrações mecânicas, documentação e testes repetitivos, mas ruim para decisões de arquitetura. A empresa precisa medir onde o uso ajuda e onde cria trabalho adicional. O objetivo não é provar que a IA funciona em qualquer situação, mas identificar os fluxos em que ela reduz esforço sem diminuir qualidade.
O desenvolvedor continua responsável por formular o problema. Uma solicitação vaga tende a produzir código genérico. Um pedido com critérios de aceite, limites de dependência e exemplos facilita a revisão. Mesmo assim, uma boa instrução não elimina a obrigação de entender o resultado.
O impacto para quem programa no Brasil
O debate vale para equipes de todos os tamanhos. Uma startup pequena pode usar um agente para construir uma primeira versão, mas precisa evitar que a pressa crie uma base impossível de manter. Um profissional autônomo pode economizar horas em tarefas repetitivas, desde que revise licenças, dependências e segurança antes de entregar o projeto ao cliente.
Em times brasileiros que trabalham em fusos diferentes, a revisão pode ser o ponto mais lento do ciclo. Se o agente abre dezenas de pull requests durante a madrugada, o trabalho não está concluído pela manhã. A equipe precisa combinar horários, limites e responsáveis para que a automação não transforme a fila de revisão em um estoque invisível de trabalho.
Também há uma questão de formação. Profissionais iniciantes podem aprender com exemplos gerados, mas correm o risco de aceitar padrões que não compreendem. A ferramenta deve ser usada para explicar decisões, comparar alternativas e criar testes, não para eliminar o aprendizado. Quanto mais autonomia o agente recebe, maior deve ser a capacidade humana de questionar o resultado.
Uma conclusão menos espetacular e mais útil
Agentes de código são uma tecnologia relevante porque reduzem o tempo de certas tarefas e permitem que uma pessoa explore uma ideia mais rapidamente. A reportagem da Ars Technica mostra que esse ganho não aparece automaticamente na entrega final. O sistema de desenvolvimento tem outras etapas, e a revisão humana pode absorver toda a eficiência criada na geração.
Para usar a tecnologia melhor, equipes devem limitar permissões, reduzir o tamanho das mudanças, medir o tempo de revisão e acompanhar defeitos depois do lançamento. O indicador mais importante é a capacidade de transformar uma necessidade em software confiável. Escrever mais código é fácil de contar. Entregar algo que continue funcionando é o trabalho que ainda exige engenharia.
A fila de revisão virou uma métrica de produto
Uma equipe que adota agentes deveria acompanhar quantas mudanças aguardam revisão, quanto tempo cada uma permanece aberta e quantas voltam para correção. Esses indicadores mostram se a automação está reduzindo trabalho ou apenas mudando sua localização. Também ajudam a identificar tarefas em que a autonomia é útil e tarefas em que o contexto de negócio ainda exige orientação próxima.
O limite de tamanho é tão importante quanto o limite de permissão. Um agente pode preparar pequenos pull requests, explicar os testes executados e interromper a tarefa quando encontrar uma decisão de arquitetura. Essa disciplina torna o resultado mais fácil de revisar e de reverter, especialmente em equipes pequenas ou em projetos que lidam com dados pessoais.
Fonte original: https://arstechnica.com/ai/2026/10/ai-coding-agents-generate-more-code-but-not-more-software/
