IA agêntica já está no seu codebase — e a maioria dos times não está preparada
Dois anos de evidências da indústria mostram que a disciplina de engenharia importa muito mais do que a escolha de ferramentas.
Agentes de IA que escrevem código de produção, abrem pull requests e gerenciam tickets deixaram de ser curiosidade de laboratório. Estão em operação agora, em empresas de todos os tamanhos. Mas o retrato pintado pelas evidências acumuladas é bem mais complicado do que o hype sugere: desenvolvedores individuais ficam mais rápidos enquanto seus times não ficam, bases de código parecem mais limpas enquanto acumulam dívida técnica em silêncio, e os times que se sentem mais produtivos podem ser exatamente os mais enganados sobre isso.
O paradoxo de produtividade é real e mensurável
Ganhos de velocidade individual de 20–55% consistentemente falham em se traduzir em melhoria de entrega organizacional. O motivo é estrutural: à medida que as ferramentas de IA multiplicam o volume de código produzido, a revisão humana vira o gargalo.
Um estudo com mais de 10.000 desenvolvedores constatou que, embora a adoção de IA tenha aumentado os pull requests mesclados em 98%, o tempo de revisão de código subiu 91% e o tamanho dos PRs cresceu 154% — deixando as métricas de entrega no mesmo lugar.
O dado mais perturbador vem de um RCT conduzido pela METR em julho de 2025: desenvolvedores que estavam 19% mais lentos com assistência de IA acreditavam estar 20% mais rápidos. Pesquisas de percepção de produtividade são não confiáveis quando IA está envolvida. Times que medem resultados objetivos — taxas de retrabalho, churn de código, taxa de falha em mudanças — enxergam um quadro completamente diferente dos times que medem sentimentos.
O relatório DORA 2025 resume bem: "AI doesn't fix a team; it amplifies what's already there." Para cada aumento de 25 pontos percentuais na adoção de IA, a estabilidade de entrega caiu 7,2% em média.
Gerenciamento de contexto é a nova engenharia de performance
O desafio técnico central dos sistemas agênticos não é a qualidade do prompt — é a qualidade do contexto. Modelos de fronteira degradam com o comprimento do input bem antes dos limites de contexto anunciados. A pesquisa "Lost in the Middle" de Stanford encontrou quedas de precisão acima de 30% para informações posicionadas no meio de uma janela de contexto longa.
Na prática, isso significa que três servidores MCP conectados podem consumir 143.000 de 200.000 tokens disponíveis antes de uma única linha de trabalho começar.
O padrão que emergiu entre times experientes é o "Document and Clear": ao atingir cerca de 60% da capacidade de contexto, o estado do agente é salvo em um arquivo markdown, o contexto é limpo e uma nova sessão começa do zero.
# agent-checkpoint-2025-05-14.md
## Objetivo da sessão
Refatorar módulo de autenticação para suportar OAuth 2.1
## Decisões tomadas
- Mantida interface pública do `AuthService`
- Removida dependência de `legacy-jwt` (v1.x)
- Testes de integração passando em `auth/`, `session/`
## Próximos passos
- Implementar refresh token rotation
- Revisar middleware de rate limiting
A recomendação é clara: reinicie a sessão com 60% de capacidade, não com 90%.
Os riscos de segurança estão subestimados
Um estudo da USENIX Security 2025 analisou 2,23 milhões de recomendações de pacotes feitas por IA e encontrou uma taxa de alucinação de 19,7% — quase um em cada cinco pacotes sugeridos simplesmente não existe. Atores maliciosos já perceberam isso: um pacote alucinado publicado no PyPI recebeu mais de 30.000 downloads em três meses depois que um repositório popular referenciou o comando de instalação inventado pela IA. Não é risco teórico. Está acontecendo em produção.
Revisão de segurança feita puramente por LLM produziu 88% de falsos positivos em benchmarks independentes. O consenso da indústria convergiu para um padrão híbrido:
# Ferramentas determinísticas encontram candidatos
semgrep --config=p/owasp-top-ten ./src
bandit -r ./src -f json -o bandit-report.json
# O LLM triaga e explica — não decide sozinho
Ferramentas determinísticas como Semgrep e Bandit identificam os candidatos; o LLM triaga e explica. O LLM sozinho não é um revisor de segurança.
O que realmente funciona
Os times que extraem valor genuíno e sustentável compartilham um perfil comum: disciplina de engenharia sólida preexistente, bases de código orientadas a domínio, práticas de commit atômico, fluxos de trabalho guiados por especificações e cultura de revisão crítica.
Eles tratam agentes de IA como desenvolvedores juniores poderosos, mas não confiáveis — dando a eles especificações claras, tarefas com escopo abaixo de 400 linhas e revisão humana obrigatória para qualquer coisa que toque autenticação, pagamentos ou segurança.
Os arquivos de instrução de agente (AGENTS.md, CLAUDE.md) ficam abaixo de 200 linhas — arquivos superlotados diluem o sinal em vez de melhorar o comportamento. Servidores de ferramentas MCP são carregados seletivamente por tipo de sessão, não todos de uma vez. Agentes especialistas com prompts focados superam agentes de propósito geral com grandes dumps de contexto, mas apenas quando as fronteiras de tarefa estão bem definidas.
O erro mais comum é tratar IA agêntica como solução para problemas de disciplina de engenharia. A evidência é inequívoca: ela é um amplificador, não um corretivo. Times com cobertura de testes fraca, especificações vagas ou arquiteturas monolíticas não vão se curar com agentes de IA — vão acelerar exatamente esses problemas enquanto ficam mais difíceis de enxergar.
A pergunta relevante não é "qual agente de IA devo adotar?". É "minha engenharia está boa o suficiente para que um amplificador me ajude?".