O paradoxo do desenvolvimento com IA: por que em código novo a velocidade sobe 55% e em código maduro cai 19%

• Desaceleração em código maduro (METR, 246 tarefas): +19% no tempo por tarefa entre desenvolvedores com experiência média de 5 anos no repositório
• Erro de autoavaliação (cegueira de calibração): diferença de quase 40 p.p. entre a sensação de aceleração (-20%) e a desaceleração real (+19%)
• Aceleração em folha em branco (Microsoft/GitHub): -55,8% de tempo (71,2 contra 160,9 min) num servidor HTTP típico feito do zero
• Crescimento oculto da árvore de pacotes e das alucinações: 14 dependências diretas se desdobram em 492 pacotes (e até 1.442 num projeto web)

Em algumas conferências mostram slides sobre o dobro de velocidade com assistentes de IA, enquanto em outras citam relatórios de que as redes neurais atrapalham os seniores. O paradoxo é que ambas as afirmações se apoiam em testes controlados randomizados (RCT) rigorosos, com medição de tempo ao segundo, e ambas estão certas.

No experimento de Peng e colegas da Microsoft Research, GitHub e MIT Sloan (`arXiv:2302.06590`), 95 desenvolvedores receberam a tarefa de escrever do zero um servidor HTTP em JavaScript seguindo testes automatizados prontos. Com o autocompletar por IA, os participantes concluíram em 71,2 minutos contra 160,9 minutos no grupo de controle — 55,8% mais rápido.

Já em julho de 2025, a equipe da METR (`arXiv:2507.09089`) conduziu um RCT espelhado com 16 mantenedores experientes e 246 tarefas reais de produção em seus próprios repositórios maduros (em média 1,1 milhão de linhas de código, 10 anos de histórico do projeto e 5 anos de experiência pessoal do participante — cerca de 1.500 commits).

Com as ferramentas de IA, os desenvolvedores gastaram 19% mais tempo na tarefa, e 75% dos participantes ficaram no vermelho.

Por que desenvolvedores experientes erraram a avaliação da própria

velocidade em quase 40 pontos percentuais?

O número mais assustador no relatório da METR não é nem os próprios +19% de tempo, mas o colapso da calibração humana. Antes do início, especialistas externos (34 economistas e 54 pesquisadores de ML) previam uma aceleração de 38–39%, e os próprios desenvolvedores, de 24%. Mas depois de terminar, tendo concluído todas as 246 tarefas e registrado os tempos, os participantes estavam sinceramente convencidos de que a IA havia economizado cerca de 20% do tempo.

A sensação e o cronômetro divergiram em 39 pontos percentuais (com calibração normal da previsão de duração das tarefas de 0,64 e 0,59). A IA quebra a percepção de esforço: ficar na cadeira de revisor observando o texto rodar é psicologicamente mais fácil do que se enfiar sozinho num legado. Daí a conclusão gerencial: qualquer relatório sobre o 'efeito da adoção de IA' construído com base em pesquisas com funcionários mede dopamina, não produtividade.

Onde passa a 'fronteira irregular' das capacidades do modelo entre

novato e especialista?

Ao combinar os dados da METR e da Microsoft com estudos de Harvard sobre 758 consultores da BCG (`Navigating the Jagged Technological Frontier`, 2026) e o trabalho de Brynjolfsson na QJE sobre 5.172 operadores de suporte, surge um quadro unificado:

1. Efeito da novidade do contexto: no suporte, a IA deu em média +15%, mas nos novatos o ganho foi de +30–36%, enquanto nos veteranos foi praticamente nulo. Numa folha em branco, qualquer um de nós é um novato, por isso ali obtemos -55% de tempo. Num repositório de cinco anos, a principal dificuldade é manter os invariantes implícitos da arquitetura, que não estão nos pesos do modelo. 2. Armadilha da persuasão: dentro da fronteira de capacidades do modelo, os consultores com IA realizaram 12,2% mais tarefas e 25,1% mais rápido. Mas fora da fronteira, a proporção de soluções corretas caiu de 84,5% para 60–70,6%, enquanto juízes externos avaliaram a persuasão desses textos equivocados como 17,9–25,1% mais alta.

Para não cair nos +19%, mantenho quatro regras: nunca delegar a compreensão (indicar no requisito o arquivo exato, a linha, a causa e o critério de aceitação), bloquear com hooks `PreToolUse` apenas 25 comandos irreversíveis entre 424 permitidos (com desempacotamento de wrappers como `ssh`, `python -c` e `base64`), manter 93 KB de regras modulares de arquitetura em disco e separar os níveis de delegação `Level 0–3`.

Como 14 pacotes declarados se transformam em 492 e qual o perigo do

slopsquatting?

Segundo dados do USENIX Security 2025 (`arXiv:2406.10279`) sobre 576.000 fragmentos de código, os modelos inventam nomes de bibliotecas inexistentes em 5,2% dos casos nas LLMs comerciais e em 21,7% nas abertas (205.474 nomes fantasmas únicos), do que os atacantes se aproveitam (`slopsquatting`). É possível verificar a árvore real de dependências do próprio projeto em um segundo:

```python import json, sys

lock = json.load(open(sys.argv[1], encoding="utf-8")) root = lock["packages"][""] direct = len(root.get("dependencies", {})) + len(root.get("devDependencies", {})) total = len([k for k in lock["packages"] if k]) print(f"Declarados manualmente: {direct} | Reais na árvore: {total}") ```

No meu bot, 14 bibliotecas declaradas se desdobraram em 492 pacotes, e num projeto web, em 1.442 pacotes. O mínimo obrigatório de higiene é fazer commit dos arquivos lock, rodar `trufflehog`, `trivy fs --scanners vuln,secret` e `syft`.

Hooks de segurança, níveis de delegação e controle de dependências já estão reunidos no stack da [Nomad AI](https://nomadnet.ai) e na plataforma [agent.nomadnet.ai](https://agent.nomadnet.ai). É possível aprender vibe coding de engenharia sem perder o controle sobre a arquitetura na [Hamidun Academy](https://academy.hamidun.com) (72 horas de teste gratuito), e as regras e guardas de combate estão disponíveis no [Vibe Club](https://hamidun.com/club).