O investimento que não deprecia com o modelo

produtividadeai-nativeengenharia

A METR rodou um estudo controlado com 16 desenvolvedores experientes de repositórios open source relevantes. Repositórios com 22 mil stars de média. Código de produção real, tarefas reais, distribuídas aleatoriamente: metade podia usar ferramentas de IA, metade não. Foram 246 tarefas ao longo de cinco meses.

Os que usaram IA levaram 19% mais tempo para completar as tarefas do que os que não usaram.

A parte mais reveladora do estudo não é esse número. É o que aconteceu nas estimativas. Antes de começar, os participantes esperavam que IA reduziria o tempo em 24%. Depois de terminar, ainda achavam que tinham sido 20% mais rápidos.

Existe um gap de 39 pontos percentuais entre o que sentiram e o que foi medido. Isso não é expectativa mal calibrada apenas. É percepção que não se alinha com realidade enquanto o trabalho acontece. O desenvolvedor está mais ocupado, mais ativo na sessão, com mais código passando pelos dedos, e mais lento no relógio.

A conta que não fecha no time

O estudo da METR isolou o impacto individual em tarefas complexas. Mas o que acontece na escala de um time é outra medição.

O Faros AI acompanhou mais de 10 mil desenvolvedores em 1.255 equipes empresariais e o resultado é aparentemente contraditório. Desenvolvedores com alta adoção de IA completaram 21% mais tarefas e fizeram merge de 98% mais pull requests. O volume individual cresceu muito.

O tempo de revisão de cada PR subiu 91%.

O tamanho médio das PRs cresceu 154%. Os bugs por desenvolvedor subiram 9%. E quando olham para a correlação entre adoção de IA e resultados no nível da empresa, a correlação não é significativa. O volume individual quase dobrou. O resultado do time ficou onde estava.

O gargalo se moveu. Não desapareceu.

O que fica para o revisor

Quando um desenvolvedor com agentes produz o dobro de PRs, cada uma 154% maior, o trabalho de revisão não cresce linearmente. Ele explode. E não tem como resolver isso com um modelo melhor no lado de quem gerou o código.

O que acontece na prática é previsível. Revisões ficam mais superficiais porque o volume não cai. Código passa pelo merge sem a inspeção que teria antes. Refatoração vira luxo quando o tempo disponível mal cobre o que chegou para aprovar. A manutenção do codebase, o trabalho de deixar o sistema entendível para quem vem depois, vai para o final da fila onde fica para sempre.

O paradoxo do METR e o paradoxo do Faros AI são o mesmo fenômeno em escalas diferentes. No nível individual, o desenvolvedor sente que está produzindo mais enquanto o relógio diz o contrário. No nível do time, o volume de output cresceu enquanto o resultado da empresa ficou estável. A sensação de aceleração existe. O ganho mensurável, não.

Dois harnesses, uma escolha

Há uma distinção que o paper de Diaz et al. sobre Spec-Driven Development, publicado no arXiv em agosto de 2026, torna explícita e que me parece o núcleo do problema.

Quando times adotam agentes, investem em um harness técnico: orquestração, gerenciamento de contexto, guardrails, verificação automatizada, pipelines de CI adaptados para volume agêntico. Esse investimento faz sentido e tem resultado. Mas ele deprecia com o modelo. Quando o próximo frontier sai, parte do scaffolding que você construiu fica obsoleto ou pode ser simplificado. O harness técnico tem vida útil amarrada à geração de modelo em que foi construído.

Há outro tipo de harness. O paper chama de metodológico. É o conjunto de mecanismos que governa como o time trabalha em volta dos agentes: como a intenção de uma tarefa é explicitada antes de ser delegada, como specs funcionam como contrato entre quem especifica e quem revisa, como a aceitação de output se baseia em evidência verificável em vez de impressão, como o contexto acumulado fica acessível para quem entra no processo depois.

Esse harness não deprecia. Aprecia. A cada ciclo de trabalho, o conjunto de specs, normas e padrões codificados fica mais rico. A capacidade do time de absorver o que os agentes produzem fica maior. O revisor tem menos trabalho de interpretação porque a intenção estava explícita desde o início. O novo membro do time encontra contexto documentado em vez de ter que reconstruir do zero.

Na minha leitura, o dado do Faros AI, 91% de aumento no tempo de revisão sem correlação com resultado de empresa, é o sintoma de times que investiram só na metade técnica. A velocidade individual subiu. A capacidade coletiva de absorver o que foi produzido ficou onde estava.

O gap do METR, a lentidão que o desenvolvedor não percebe, fecha quando o harness metodológico reduz o overhead de coordenação com o agente. Quando a spec já está lá, quando o padrão de revisão já está estabelecido, quando a delegação tem critérios que o agente consegue seguir sem precisar de interpretação em tempo real, a geração e a absorção começam a andar juntas.

O investimento que não fica obsoleto quando o próximo modelo sair não está no scaffolding em volta do agente. Está na disciplina que o time construiu ao redor de como ele trabalha com agentes. Essa parte fica mais valiosa com o tempo, não menos.

O investimento que não deprecia com o modelo

A conta que não fecha no time

O que fica para o revisor

Dois harnesses, uma escolha

Referências