Vibe Coding: você sente +20%, mede -19%

Toda vez que fecho uma tarefa com Claude Code, meu cérebro já cospe: “foi bem mais rápido”. E é esse “bem mais rápido” que me pegou.

Em 2025 o METR soltou um RCT (randomized controlled trial) com 16 devs open source experientes passando por 246 tarefas nos próprios projetos deles (artigo PDF). O título é um sonífero. O resultado nem tanto: quando são obrigados a usar IA, os devs levam 19% a mais pra terminar. Antes de começar, chutavam que iam ser 24% mais rápidos. Já tendo terminado, ainda juravam ter sido 20% mais rápidos.

A sensação errou por 39 pontos num sentido só.

Reli o paper três vezes atrás de furo na metodologia. Não achei. A metodologia estava intacta — o furo era meu.

O que o cronômetro vê e o cérebro não

Esses 39 pontos entre “o que senti” e “o que o relógio marcou” não são barulho estatístico. São um viés cognitivo manjado, com nome e sobrenome: viés de automação.

Em uma linha: você confia demais no que a máquina cuspiu. O assunto é velho — aparece nos manuais de aviação desde os anos 80, quando a tripulação relaxa demais no piloto automático. E em 2024 o Georgetown CSET confirmou que o mesmo efeito reaparece intacto quando o “piloto” é um LLM gerando código.

A assinatura é sempre a mesma. Quando algo “funciona de primeira”, o cérebro credita a facilidade à sua própria competência. O que ele não credita é os 15 minutos que você gastou lendo a sugestão da IA, reescrevendo as beiradas erradas e desfazendo duas tentativas que não compilaram. Esse pedaço somem. Fica registrado só o “escrevi a função em 5 minutos”.

É esse padrão que o METR cronometrou. Os devs não mentiram. Esqueceram as frições que, num dia sem IA, teriam entrado na conta.

Três micro-vieses dentro do Vibe Coding

O livro Manual completo dos truques psicológicos para engenheiros desmonta o Vibe Coding em três camadas de viés que empilham uma em cima da outra. Vou passar correndo porque o ponto não é a taxonomia — é que nenhuma das três se resolve com “preste mais atenção”.

1. Viés de automação

Já falei disso logo acima. Você aceita a sugestão porque ela compila. Só que “compila” e “está correto” moram em bairros diferentes; o cérebro trata como se fossem o mesmo endereço porque o sinal verde chega antes do raciocínio.

2. Efeito de ancoragem

A primeira saída do Copilot ou do Claude vira a âncora. Toda correção que você faz depois sai dali, não de uma folha em branco. A literatura recente sobre vieses em desenvolvimento assistido por LLM descreve o mesmo padrão: depois de ver a primeira sugestão da IA, os devs quase nunca cogitam abordagens radicalmente diferentes. O leque mental fecha sem que ninguém note.

Peguei isso em mim mesmo semana passada. Estava escrevendo for loops em TypeScript do jeito que o Claude tinha escrito — mesmo quando map/filter eram claramente mais limpos. Não foi escolha. Foi âncora.

3. Viés de autoridade

Quando o LLM responde “esta é a melhor abordagem” com cara de verbete de enciclopédia, a sua barreira interna de verificação baixa a guarda. Um colega humano começando com “acho que…” faz você conferir. O OWASP Top 10 for LLM Applications lista “Overreliance” (dependência excessiva) como um dos riscos principais exatamente por essa dinâmica.

Por que “ser mais cuidadoso” não resolve

A primeira reação, depois de ler o paper do METR, costuma ser “ok, vou ficar mais atento”. Não resolve. O METR mediu devs experientes — 5 anos de média no projeto, sabendo que estavam sendo cronometrados — e mesmo esse grupo errou por 39 pontos.

O viés de automação não é falha de atenção. É economia cognitiva de fábrica. “Ser mais cauteloso” quer dizer gastar System 2 (lento e caro) num lugar onde o cérebro insiste em usar System 1 (rápido e barato). Você até consegue por meia hora. O dia inteiro, impossível.

O que me funcionou melhor, nessas últimas semanas rodando Claude Code aqui no meu setup, foram rituais que tiram a verificação de dentro do fluxo. Dois que vale a pena citar e um que eu detesto fazer:

• Antes de aceitar uma sugestão, parar meio minuto e escrever numa linha “como eu escreveria do zero?”. É uma maneira de forçar o System 2 pra fora da cabeça, para o papel
• Perguntar ao mesmo LLM “liste três fraquezas dessa resposta” — ativa verificação sem depender da minha disciplina
• Rodar o código em edge cases que o teste gerado pela IA não cobre. Esse é o chato. É também o que mais pega bug, porque teste gerado pela IA raramente acha bug em código gerado pela mesma IA

Chato é o ponto. Chato quer dizer fora do fluxo, e fora do fluxo quer dizer que não depende de eu estar com pique naquela hora.

O que isso significa pra quem lê daí do Brasil

Honesto: eu moro no Japão e meu dia de código é num ambiente japonês. Não vou fingir que medi nada em dev brasileiro nem que tenho dado agregado do mercado BR. O viés provavelmente aparece aí da mesma forma, mas quem vai cronometrar isso em devs brasileiros é alguém local — não eu.

O que dá pra oferecer é outra coisa: o paper do METR é reprodutível no seu próprio dia a dia. Duas semanas cronometrando as tarefas em dois baldes (com Claude Code vs sem), e você sai com um número pessoal. Esse número vai ser diferente do meu, provavelmente diferente do METR também, e é o único que importa pra sua decisão.

Métrica agregada tipo “produtividade com IA” não serve pra nada. “Minha produtividade com IA, no meu projeto, nas minhas tarefas” é a única que decide alguma coisa.

O risco maior está no “funcionou”

O pior do Vibe Coding não é a lentidão de 19%. É que “funcionou” começa a bastar como critério.

“Funcionou”, “está correto” e “é mantível” são três coisas diferentes. O loop curto do Vibe Coding — pergunta, resposta, roda, verde — libera dopamina em cima do primeiro. Os outros dois ficam pra depois. “Depois” quase sempre vira “pro colega que vai pegar esse código daqui a seis meses”.

Isso não é argumento contra IA. É argumento contra confundir “me sinto produtivo” com “estou produtivo”. O METR mostrou que o primeiro não é proxy do segundo — nem com 5 anos de projeto nas costas.

Fechamento

Se tivesse que levar uma coisa só deste post, levaria esta: na próxima vez que terminar uma tarefa com Claude Code e aquela voz interna disser “foi rapidíssimo”, marque o tempo real no cronômetro e compare com uma tarefa parecida que você fez sem IA. Faça isso dez vezes. Vai sair um número.

Pode dar positivo (parabéns, você quebrou o padrão METR), pode dar zero, pode dar negativo. Tanto faz — o que importa é que você saiu da sensação, e a sensação, como vimos, é o próprio viés em ação.

A IA não pede menos engenheiro. Pede engenheiro que meça a si mesmo. Essa é a mudança de ofício.

---

ken imoto · WebRTC & Voice AI engineer · kenimoto.dev · TabNews