Eu achava que a IA me deixava mais rápido. Aí eu medi

Tem uma sensação que quase todo mundo conhece depois de alguns meses usando agentes de IA no dia a dia: a de estar voando. Pedir uma feature, o agente cuspir o código, ajustar um detalhe ou outro e seguir. Produtividade nas alturas, certo?

Foi aí que um estudo da METR apareceu no meu feed e me fez coçar a cabeça. Eles recrutaram 16 desenvolvedores experientes (gente que contribuía há anos para repositórios com mais de 22 mil estrelas e 1 milhão de linhas de código) e pediram pra eles resolverem 246 issues reais dos próprios projetos. Pagaram US$ 150 por hora. Metade das issues com IA liberada (Cursor Pro + Claude 3.5/3.7 Sonnet, o estado da arte na época), metade sem.

Resultado: com IA, os devs foram 19% mais lentos. O detalhe cruel é que esses mesmos desenvolvedores juravam ter sido 20% mais rápidos. Quarenta pontos percentuais entre a percepção e a realidade.

O estudo tem ressalvas (a amostra é pequena, o cenário é específico), mas o padrão apareceu de novo em escala. O AI Engineering Report 2026 da Faros AI, com telemetria de 22 mil desenvolvedores em mais de 4 mil times ao longo de dois anos, mostra um retrato mais nítido ainda:

• Code churn (linhas deletadas vs. adicionadas) subiu 861% em times com alta adoção de IA
• Bugs por desenvolvedor subiram 54% (eram 9% no relatório de 2025 — a curva está se acentuando, não achatando)
• Incidentes em produção por PR mergeado mais que triplicaram (+242,7%)
• Tempo mediano em code review subiu 441,5%
• PRs mergeados sem revisão nenhuma cresceram 31,3%

E as boas notícias? Também existem. Epics completados por dev subiram 66%, a taxa de merge de PRs subiu 16,2%, e a entrega de fato acelerou. O problema não é que IA não produza, é que ela produz mais rápido do que você consegue conferir, e a conferência virou o gargalo. Ou pior: ela simplesmente deixou de acontecer.

O buraco era mais embaixo. Não era um problema do modelo. Era a ausência de estrutura em volta dele.

Um exemplo rápido

Imagina um desenvolvedor que pede pra um agente refatorar uma função de validação de CPF num sistema de cadastro. O agente devolve o código lindo: testes unitários passando, cobertura em dia, tudo nos conformes. O desenvolvedor mergeia e vai dormir tranquilo.

No dia seguinte, a fila de cadastro está lotada de exceções. O agente tinha substituído a validação oficial por uma regex mais elegante, que aceitava CPF inválido em dois formatos de entrada diferentes. O teste unitário passava porque testava com o formato esperado. O problema estava nos dados reais, que chegam em formato imprevisível.

Ninguém revisou a transformação porque o diff parecia óbvio demais pra precisar de revisão. E é exatamente aí que a IA te pega: ela não erra no óbvio, erra no quase certo que parece certo.

O que é um harness, em bom português

A palavra harness não possui tradução para o pt-BR, mas podemos fazer uma comparação com aquele equipamento que prende o alpinista na corda. No mundo dos agentes, o termo virou shorthand para tudo que cerca o modelo, menos o modelo: o contexto que você entrega, as ferramentas que ele pode usar, as verificações que rodam no trabalho dele e as regras do jogo. Agente = Modelo + Harness.

Imagine uma cozinha profissional. O modelo é um cozinheiro talentoso que acabou de chegar. Se você só apontar o fogão e disser "faz aí", vai sair prato bom e vai sair desastre, em proporções imprevisíveis. Uma cozinha de verdade tem ficha técnica de cada prato, mise en place organizado e, principalmente, alguém no passe conferindo cada prato antes de ir pra mesa (se você já comeu num restaurante que virou notinha do iFood por causa de um prato que saiu errado no meio do serviço, sabe do que eu tô falando). É exatamente isso que um harness faz: a ficha técnica é o arquivo de regras do projeto, o mise en place é o contexto, e o sujeito no passe são os sensores que verificam o resultado antes de chegar em você.

Como a maioria usa (e por que dói)

O fluxo padrão até pouco tempo atrás era: abrir o chat, pedir, colar o código, rodar na mão e torcer. Funciona no começo. O problema aparece na escala.

O relatório da Faros é especialmente cruel com a tese de que "é só ter processos sólidos que a IA não quebra nada". Não quebra. A conclusão deles é direta: times com engineering foundations maduras (ou seja: DORA metrics altas, DevOps disciplinado, delivery enxuto) estão experimentando a mesma deterioração que todo mundo. Pesquisas de opinião (como o DORA State of DevOps 2025) mostram que desenvolvedores se sentem mais produtivos. E de fato são, no nível individual. O que a pesquisa não captura é o que acontece no downstream: as filas de review acumulando, os incidentes aumentando, os bugs chegando em produção que nunca deveriam ter passado. Percepção sempre atrasa em relação à realidade. É por isso que friso: Telemetria não é exagero, é fundamental.

15 anos de mercado me ensinaram que tudo que depende de disciplina heroica falha numa terça-feira qualquer. A solução não é revisar com mais atenção. É fazer a máquina revisar primeiro.

Como montar um harness na prática

Dá pra montar um harness em cima de um modelo mental simples, emprestado da Birgitta Böckeler (Thoughtworks): guias orientam o agente antes de agir, sensores verificam depois.

Os sensores têm dois sabores. Os computacionais (linter, testes, análise estática) são baratos e determinísticos, então rodam sempre. Os inferenciais (um segundo modelo julgando o diff do primeiro: o tal LLM as judge) são caros e meio imprevisíveis, então entram só onde o risco compensa.

Um harness típico tem dois modos:

Modo Hobby, para projetos pessoais, blog, experimentos: um arquivo de regras na raiz do projeto (tipo CLAUDE.md ou AGENTS.md) que descreve as convenções, mais um make check que precisa passar antes de qualquer commit. Só isso. Uso muito em testes em casa quando preciso fazer algo rápido e quero montar a estrutura de forma rápida e barata.

Modo Pro, para trabalho em equipe: plano formal escrito antes de tocar em código, execução com TDD, revisão em dois estágios (a spec foi cumprida? o código presta?), um verificador cético lendo o diff final e métricas registradas ao fim de cada sessão. Admito que estou testando já uma V3 deste modelo aqui, ir lapidando é a melhor forma de se chegar no estado da arte.

O sensor computacional mais básico é um Makefile sem glamour nenhum:

check: fmt lint test

check-strict: fmt lint
	go vet ./...
	# -race e -count=1 de propósito: race conditions e cache de teste
	# são exatamente os bugs que agente nenhum confessa ter criado
	go test -race -count=1 -coverprofile=coverage.out ./...

A regra de ouro: o agente nunca pode declarar "pronto" sem colar o output desse comando. Sem exceção, nem no modo Hobby.

O sensor inferencial entra quando o risco é alto. Pensa numa code review automatizada: um segundo agente recebe o diff, o plano original e o output dos testes, e responde uma pergunta só: "esse código faz exatamente o que foi pedido, ou tem algo estranho?" Não substitui o review humano, mas filtra os casos óbvios, e, mais importante, pega aqueles cases quase certos que passariam batido.

A parte que ninguém faz: medir de verdade

Dica rápida: antes de montar qualquer harness, passe uma semana anotando suas sessões com IA do jeito que está hoje. Tempo total, tempo revisando, quanto do diff você jogou fora. Esse é o seu baseline. Sem ele, daqui a um mês você vai estar igual aos devs do estudo da METR: convicto de um ganho que talvez não exista.

E cuidado com as métricas de vaidade: Quantidade de linhas geradas, PRs abertos, tokens consumidos: tudo isso mede volume, não valor. O que vale acompanhar é retrabalho (% do diff que foi reescrito), defeitos que escaparam pro pós-merge e tempo do primeiro prompt até o merge.

Quando dar um passo atrás

Nem todo código merece harness. Script descartável, protótipo de uma tarde, experimento que vai morrer amanhã: nesses casos, o chat pelado resolve e a cerimônia só atrapalha. O harness existe para código que vai viver. Não seja um purista de padrões com código que você vai deletar na sexta. Nem tudo precisa estar rigorosamente como foi escrito em um livro.

A diferença entre um fluxo produtivo com IA e uma confusão generalizada não está no modelo que você escolheu, está no que você colocou em volta dele. 22 mil desenvolvedores e 246 issues depois, os dados são claros: o gargalo não é gerar código, é garantir que ele presta. Um bom harness não te deixa mais lento. Ele te protege de você mesmo (e do seu agente bem intencionado).

E você? Já parou pra medir de verdade o quanto a IA te acelera, ou está confiando no feeling igual todo mundo? Conta aí como é seu fluxo hoje.