Durante anos, ferramentas de inteligência artificial ajudaram desenvolvedores a completar linhas, explicar erros e gerar pequenas funções.

Os agentes de IA representam uma mudança de escala.

Eles podem explorar um repositório, localizar arquivos relacionados, alterar diferentes partes do sistema, executar comandos, criar testes, corrigir falhas e abrir uma pull request para revisão.

Em vez de sugerir a próxima linha, recebem uma tarefa.

“Implemente esta funcionalidade.”

“Atualize esta dependência.”

“Investigue por que os testes estão falhando.”

“Corrija esta vulnerabilidade.”

O desenvolvedor deixa de pedir apenas uma resposta e passa a delegar uma sequência de ações.

Isso cria uma promessa poderosa:

produzir mais software com menos tempo de execução humana.

Mas também cria um risco proporcional.

Um agente capaz de trabalhar em dezenas de arquivos consegue acelerar uma boa decisão.

E consegue espalhar uma decisão ruim com a mesma eficiência.

Por isso, a pergunta não é apenas se os agentes aumentam a produtividade.

A pergunta correta é:

Eles aumentam a capacidade de entregar software sustentável ou apenas antecipam o momento em que teremos de pagar pela velocidade?

Um agente não é apenas um autocomplete melhor

Assistentes tradicionais trabalham próximos ao desenvolvedor.

Sugerem uma linha.

Completam uma função.

Explicam um trecho.

O profissional permanece conduzindo quase todos os passos.

Os agentes recebem mais autonomia.

Podem decidir quais arquivos precisam ser lidos, quais comandos devem ser executados e quais alterações são necessárias para concluir uma tarefa.

Em plataformas como o GitHub, agentes já podem trabalhar em ambientes próprios, explorar o repositório, executar testes, modificar código em branches específicas e criar pull requests para revisão humana. A documentação oficial do GitHub Copilot descreve essas capacidades e alerta que esse tipo de agente possui acesso ao código, pode realizar alterações e exige controles de permissão, rastreabilidade, revisão e segurança.

A diferença parece pequena quando descrita em uma apresentação comercial.

Na prática, é enorme.

Uma sugestão ruim afeta uma linha até que alguém a aceite.

Uma tarefa mal delegada a um agente pode afetar dezenas de arquivos antes que alguém perceba que a interpretação inicial estava errada.

O agente amplia a unidade de trabalho.

Consequentemente, amplia a unidade de erro.

A produtividade é real

Seria um erro tratar os ganhos como ilusão.

Agentes podem executar tarefas repetitivas, criar estruturas iniciais, atualizar dependências, escrever testes, corrigir problemas simples e investigar partes de um sistema com enorme velocidade.

Eles também reduzem interrupções.

Em vez de abandonar uma tarefa importante para fazer uma alteração mecânica, o desenvolvedor pode delegar o trabalho, acompanhar o resultado e manter sua atenção em decisões mais complexas.

O relatório DORA de 2025 encontrou uso de IA entre aproximadamente 90% dos profissionais de tecnologia pesquisados. Mais de 80% perceberam ganhos de produtividade.

Mas a principal conclusão foi mais importante do que esses percentuais: a IA funciona como um amplificador.

Ela amplia as boas práticas de organizações maduras e também amplia os problemas de organizações desorganizadas.

Isso significa que um agente inserido em uma equipe com bons testes, arquitetura compreensível, documentação adequada e processos de revisão pode aumentar significativamente a capacidade de entrega.

O mesmo agente, colocado em uma base de código confusa, sem testes e sem critérios claros, pode apenas produzir confusão com maior velocidade.

A ferramenta não substitui a maturidade da engenharia.

Ela multiplica seus efeitos.

Produzir mais não significa entregar melhor

Muitas empresas medem o impacto da IA por meio de indicadores fáceis:

mais código produzido;

mais pull requests abertas;

mais tarefas concluídas;

menos tempo entre o início e o fim da implementação.

Esses números podem demonstrar atividade.

Não demonstram necessariamente valor.

Uma equipe pode aumentar o número de pull requests enquanto também aumenta o retrabalho.

Pode concluir tarefas mais rapidamente e gerar mais incidentes.

Pode produzir mais código e tornar o sistema mais difícil de manter.

Pode economizar duas horas na implementação e gastar dois dias investigando uma consequência inesperada.

Produtividade em engenharia de software não é a quantidade de código que entra no repositório.

É a capacidade de transformar uma necessidade em uma solução confiável, mantendo um custo sustentável ao longo do tempo.

O código representa apenas o início desse custo.

Depois de criado, ele precisa ser compreendido, testado, operado, corrigido, atualizado e eventualmente removido.

Um agente torna a criação mais barata.

Não garante que o restante do ciclo também ficará mais barato.

Dívida técnica em alta velocidade

Dívida técnica não significa simplesmente código ruim.

Ela aparece quando uma decisão facilita a entrega no presente, mas cria um custo adicional para o futuro.

Às vezes, a decisão é consciente.

A equipe sabe que está utilizando uma solução provisória para cumprir um prazo e pretende revisá-la depois.

O problema é a dívida invisível.

A solução parece correta.

Os testes passam.

A pull request é aprovada.

Mas o agente introduziu duplicação, dependências desnecessárias, abstrações inconsistentes, tratamentos incompletos de erro ou decisões que não combinam com o restante da arquitetura.

Um preprint publicado em março de 2026 analisou 304.362 commits identificados como produzidos por cinco assistentes de IA em 6.275 repositórios.

Os pesquisadores encontraram 484.606 problemas atribuídos às alterações analisadas. Odores de código representaram 89,1% do total. Em todas as ferramentas avaliadas, mais de 15% dos commits introduziram pelo menos um problema, e 24,2% dos problemas acompanhados ainda existiam na versão mais recente do respectivo repositório.

Como se trata de um preprint baseado em análise estática e em métodos de identificação de código produzido por IA, os resultados não devem ser interpretados como uma medida definitiva de toda utilização de agentes. Ainda assim, eles mostram um risco plausível: parte do custo introduzido pelo código gerado não é corrigida rapidamente e pode permanecer na base.

O agente acelera a entrega.

Se os controles não evoluírem na mesma velocidade, também acelera o acúmulo.

O problema não é apenas o código incorreto

A dívida mais perigosa pode não aparecer em uma ferramenta de análise estática.

Ela aparece quando o sistema possui código que funciona, mas poucas pessoas compreendem.

Imagine que um agente altere quinze arquivos para implementar uma nova regra.

Os testes passam.

A funcionalidade funciona.

O desenvolvedor revisa rapidamente as diferenças e aprova.

Meses depois, a regra precisa mudar.

A equipe descobre que ninguém compreendeu completamente por que determinadas decisões foram tomadas.

O código existe.

O conhecimento que deveria acompanhá-lo não.

Esse fenômeno vem sendo descrito como dívida de compreensão ou dívida de conhecimento.

Um estudo qualitativo de 2026, baseado em 621 diários reflexivos produzidos por 207 estudantes, identificou padrões como aceitação do código da IA como uma caixa-preta, incompatibilidade de contexto, dependência da ferramenta e ausência de verificação. Os autores definem dívida de compreensão como a distância crescente entre aquilo que uma equipe sabe sobre sua base de código e aquilo que precisaria saber para mantê-la corretamente.

Como o estudo acompanhou estudantes, não equipes profissionais, seus resultados não devem ser generalizados diretamente para toda a indústria. Ainda assim, o mecanismo descrito é relevante: a dependência da ferramenta pode reduzir o esforço de compreensão independente e acumular dívida de conhecimento mesmo quando o código permanece tecnicamente aceitável.

A equipe não precisa apenas possuir o software.

Precisa possuir a compreensão do software.

O agente conhece padrões, não conhece sua história

Uma base de código é formada por mais do que arquivos.

Ela possui decisões antigas.

Restrições que não aparecem na documentação.

Dependências mantidas por razões específicas.

Soluções aparentemente estranhas que existem para impedir problemas já enfrentados.

Acordos entre equipes.

Exigências jurídicas.

Limitações operacionais.

Clientes que dependem de comportamentos não documentados.

O agente trabalha com o contexto que consegue acessar.

Quando esse contexto está incompleto, ele preenche os espaços utilizando padrões gerais.

O resultado pode ser tecnicamente razoável e localmente errado.

Ele pode criar uma nova abstração sem perceber que a empresa já possui outra para o mesmo propósito.

Pode substituir um comportamento estranho por uma solução mais elegante e reintroduzir uma falha antiga.

Pode selecionar uma biblioteca popular incompatível com restrições internas.

Pode criar uma arquitetura adequada para uma empresa hipotética, mas excessiva para a equipe real.

Quanto pior for a documentação da organização, maior será a distância entre o sistema verdadeiro e o sistema que o agente acredita estar modificando.

O problema não é que a IA não possua contexto infinito.

É que muitas empresas nunca organizaram o contexto que seus próprios profissionais precisavam.

O código quase correto é especialmente perigoso

Um erro evidente costuma ser identificado rapidamente.

O sistema não compila.

O teste falha.

A aplicação não inicia.

O código quase correto é mais perigoso.

Ele funciona na demonstração.

Passa pelos cenários esperados.

Parece consistente durante uma revisão superficial.

Mas falha em uma condição rara, em um volume maior, em uma permissão diferente ou em uma integração que não foi mencionada na tarefa.

Esse tipo de erro não interrompe a entrega.

Ele entra em produção.

Agentes são particularmente eficientes em produzir soluções plausíveis.

Plausibilidade, porém, não é correção.

Um agente pode demonstrar confiança ao propor uma biblioteca inexistente, interpretar incorretamente um requisito ou alterar um comportamento que deveria permanecer compatível.

Quanto mais convincente for a resposta, maior poderá ser a tentação de reduzir a revisão.

É justamente nesse momento que a revisão se torna mais necessária.

Mais autonomia significa mais segurança

Quando um modelo apenas sugere texto, seu poder está limitado.

Quando recebe acesso a arquivos, terminal, dependências, serviços e credenciais, pode realizar ações.

Essa capacidade cria riscos que vão além da qualidade do código.

O OWASP Top 10 para aplicações com LLM descreve a agência excessiva como uma combinação de funcionalidade excessiva, permissões excessivas ou autonomia excessiva.

Um agente pode executar uma ação prejudicial por causa de uma resposta incorreta, de uma instrução ambígua ou de uma injeção de prompt encontrada em conteúdo externo.

Por isso, agentes não deveriam receber automaticamente todas as permissões de quem os utiliza.

O princípio deve ser o mesmo aplicado a qualquer sistema:

o menor acesso necessário para concluir a tarefa.

A documentação de riscos e mitigações do GitHub descreve algumas das proteções aplicadas ao seu agente: restrição a branches específicas, revisão humana antes da mesclagem, limitações de credenciais, controle sobre a execução de workflows, análise com CodeQL, verificação de dependências e detecção de segredos. Também reconhece riscos de injeção, vazamento de informações e geração de código incorreto.

Essas proteções mostram algo importante.

Até mesmo quem desenvolve os agentes não considera seguro tratá-los como profissionais autônomos sem limites.

Revisão humana não pode ser uma cerimônia

Muitas ferramentas afirmam manter o humano no processo.

Mas existe uma diferença entre o humano estar presente e o humano exercer controle real.

Uma pull request com três arquivos pode ser revisada cuidadosamente.

Uma pull request com cinquenta arquivos, centenas de alterações e explicações extensas aumenta a carga cognitiva.

O desenvolvedor pode começar a procurar apenas sinais evidentes de erro.

Os testes passaram?

O código compila?

A descrição parece coerente?

Então, aprova.

Nesse cenário, a revisão humana existe formalmente.

Na prática, o agente se torna a principal autoridade sobre a alteração.

Revisar código gerado por IA exige disciplina adicional, não menos disciplina.

Alterações devem ser pequenas.

A intenção deve estar clara.

As decisões importantes precisam ser explicadas.

Testes precisam cobrir comportamento, não apenas linhas.

O revisor deve conseguir descrever o que mudou sem depender do resumo produzido pelo próprio agente.

Caso contrário, o humano não está revisando.

Está apenas autorizando.

O agente também pode gerar os testes errados

Uma estratégia comum é pedir ao agente que implemente a funcionalidade e escreva os testes.

Isso parece eficiente.

Mas cria um problema de independência.

A mesma interpretação equivocada pode aparecer na implementação e nos testes.

Se o agente entendeu o requisito errado, pode produzir um sistema e um conjunto de testes perfeitamente consistentes com o mesmo erro.

Tudo fica verde.

O problema continua sem solução.

Por isso, critérios de aceitação não deveriam nascer apenas depois que o código foi gerado.

Precisam existir antes.

Testes de comportamento crítico devem ser derivados da necessidade do usuário, dos riscos e das regras do negócio.

Em sistemas sensíveis, diferentes mecanismos de verificação também são necessários:

testes automatizados;

análise estática;

verificação de dependências;

revisão de segurança;

testes de integração;

observabilidade;

validação humana.

Nenhuma técnica isolada oferece confiança suficiente.

Nem toda tarefa deveria ser delegada da mesma maneira

Agentes funcionam melhor quando a tarefa possui limites claros.

Atualizar uma dependência específica.

Adicionar testes a um comportamento conhecido.

Corrigir um erro reproduzível.

Migrar uma API bem documentada.

Alterar uma interface seguindo um padrão existente.

Nesses casos, existem critérios objetivos para avaliar o resultado.

O risco cresce quando a tarefa é ambígua.

“Melhore a arquitetura.”

“Otimize o sistema.”

“Corrija os problemas de segurança.”

“Modernize este módulo.”

“Deixe o código mais limpo.”

Essas solicitações exigem decisões sobre prioridades, compatibilidade, custo, risco e contexto organizacional.

Um agente pode produzir alterações impressionantes.

Mas não possui necessariamente a autoridade nem o conhecimento para decidir quais compromissos a empresa deveria assumir.

Quanto mais ampla for a tarefa, menor deveria ser a autonomia inicial.

A qualidade da especificação determina o raio do erro

Delegar a um agente não elimina a necessidade de especificar.

Aumenta essa necessidade.

Uma instrução vaga para uma pessoa gera uma conversa.

A pessoa pergunta.

Negocia.

Percebe contradições.

Uma instrução vaga para um agente pode gerar centenas de linhas antes que a ambiguidade fique visível.

Por isso, uma boa tarefa precisa descrever:

o problema que deve ser resolvido;

o comportamento esperado;

aquilo que não deve ser alterado;

as restrições técnicas;

os riscos conhecidos;

os testes necessários;

o limite da atuação.

Quanto maior a autonomia, mais claros devem ser os limites.

Prompts não substituem especificações.

São apenas uma nova interface para elas.

Como utilizar agentes sem acelerar a dívida

A resposta não é impedir o uso.

É construir um sistema de trabalho no qual velocidade e controle cresçam juntos.

O primeiro princípio é limitar a tarefa.

Agentes devem começar por alterações pequenas, reversíveis e fáceis de validar.

O segundo é limitar as permissões.

O agente não precisa de acesso irrestrito ao ambiente de produção, a todos os repositórios ou a todos os segredos para alterar uma função.

O terceiro é definir critérios antes da execução.

O que significa concluir a tarefa?

Quais comportamentos precisam permanecer?

Quais testes devem passar?

O quarto é preservar a revisão humana real.

Quem aprova precisa compreender a alteração e assumir responsabilidade por ela.

O quinto é automatizar a verificação.

Testes, análise estática, verificação de dependências, detecção de segredos e políticas de arquitetura precisam executar de forma consistente.

O sexto é manter rastreabilidade.

Deve ser possível identificar o que foi produzido pelo agente, quem solicitou a alteração, quais instruções foram fornecidas e quais verificações foram realizadas.

O sétimo é medir consequências, não volume.

Tempo de ciclo importa.

Mas retrabalho, falhas, vulnerabilidades, tempo de revisão, complexidade e custo de manutenção também importam.

O oitavo é preservar o conhecimento.

Decisões relevantes precisam ser documentadas, e profissionais devem conseguir explicar o código que aprovam.

O melhor uso do agente não é eliminar o desenvolvedor

É eliminar partes do trabalho que consomem tempo sem exigir o melhor do desenvolvedor.

Um agente pode preparar uma alteração.

Investigar arquivos relacionados.

Criar uma primeira versão.

Executar verificações.

Apontar inconsistências.

O profissional pode concentrar sua atenção em requisitos, arquitetura, risco, qualidade e impacto.

Essa combinação é mais valiosa do que tentar transformar o agente em substituto completo.

O agente possui velocidade.

O desenvolvedor deve oferecer contexto e julgamento.

O agente explora alternativas.

O desenvolvedor decide quais compromissos são aceitáveis.

O agente produz.

O desenvolvedor responde pelo que entra no sistema.

Quando cada parte assume o papel adequado, a produtividade pode ser real.

Quando a empresa utiliza o agente apenas para aumentar o volume, o ganho de curto prazo pode esconder uma conta crescente.

Produtividade real ou dívida técnica acelerada?

As duas possibilidades existem.

Agentes podem reduzir trabalho repetitivo, acelerar investigações, ampliar testes e permitir que equipes pequenas realizem tarefas antes inviáveis.

Também podem introduzir código inconsistente, aumentar a superfície de ataque, esconder decisões e criar sistemas que ninguém compreende completamente.

A diferença não está somente na qualidade do modelo.

Está na maturidade da equipe que o utiliza.

Uma organização sem testes não se torna disciplinada porque adotou IA.

Uma base de código sem arquitetura não se torna compreensível porque um agente consegue modificá-la.

Uma equipe sem revisão não se torna segura porque a ferramenta gera um resumo convincente.

A IA não resolve automaticamente problemas de engenharia.

Ela permite produzi-los em outra escala.

Agentes não deveriam ser avaliados pela quantidade de código que conseguem escrever.

Deveriam ser avaliados pela quantidade de trabalho sustentável que ajudam a concluir.

Velocidade é uma forma de produtividade.

Conseguir continuar avançando depois da velocidade é outra.

O agente pode entregar hoje aquilo que a equipe levaria uma semana para produzir.

A pergunta é quem entenderá, manterá e corrigirá essa entrega daqui a um ano.

Quando essa pergunta possui uma boa resposta, temos produtividade.

Quando ninguém sabe responder, provavelmente estamos apenas gerando dívida mais rápido.