IA me deixou 5x mais rápido — e 5x pior no meu trabalho

O “quarto terminal” e o erro que define a era

Há um momento acontecendo em escritórios e quartos pelo mundo: três sessões de agentes de IA rodando ao mesmo tempo — um refatorando, outro escrevendo testes, outro migrando código. A pessoa à frente não digita. Ela observa, alternando o olhar entre painéis como quem apostou em três mesas e não sabe qual vigiar. Até que surge o pensamento: “posso abrir um quarto”.

O autor Gursimar Singh, em ensaio publicado no Towards Data Science, chama isso de “quarto terminal” — e o define como o erro definidor da era da programação com IA. Não porque rodar agentes em paralelo seja ruim, mas pelo que o reflexo revela: a IA nos entregou capacidade ociosa, e nosso primeiro instinto foi preenchê-la com mais IA, em vez de perguntar para que essa capacidade realmente serve.

A aceleração é real — mas a conta vem depois

É preciso ser justo com as ferramentas. Em um estudo controlado com desenvolvedores construindo um servidor HTTP simples, quem usou assistente de IA terminou visivelmente mais rápido. Em um experimento de campo com milhares de desenvolvedores, os pull requests mesclados cresceram cerca de 25%. Para código novo e boilerplate, a aceleração é real.

Mas ninguém avisa sobre o custo oculto. Singh relata o primeiro sinal: precisou ler a própria descrição de um PR — escrita por IA — para lembrar do que se tratava. Depois veio o quase-desastre: um agente adicionou um conjunto de permissões a um serviço, com um wildcard permissivo que só foi barrado porque um colega perguntou “essa permissão coringa é de propósito?”. Os testes passavam porque checavam que a permissão existia, não que era segura.

“Todos os testes passam” não é o mesmo que “isso faz o que eu queria”.

O gargalo mudou de lugar

A visão mais útil, segundo o autor: o gargalo não desapareceu — ele mudou de endereço. Antes, o custo estava em transformar ideia em sintaxe. Agora, com a geração de rascunho quase gratuita, o caro virou dizer com precisão o que você quer e provar que conseguiu. Em times com alta adoção de IA, o tempo de revisão de PRs cresceu cerca de 90% em dados de mais de dez mil desenvolvedores.

Há ainda um achado mais incômodo: um estudo com desenvolvedores open source experientes apontou que ficaram cerca de 19% mais lentos com IA, acreditando estar 20% mais rápidos — revisado depois por problema amostral, mas coerente com o relato de muitos engenheiros seniores. A IA é rápida no que é pequeno e novo; é não confiável no que é grande e antigo.

Surge daí o “paradoxo da confiança”: grande parte do código de produção já é coautorada por IA, enquanto cerca de três quartos dos desenvolvedores relatam alucinações frequentes e admitem não confiar totalmente na saída. Singh dá nome à lacuna: dívida de verificação — tempo economizado na escrita que volta depois como auditoria de código que ninguém entende, e que “aparece às 2 da manhã”.

O que fazer enquanto a IA escreve o código

O autor propõe substituir o quarto terminal por quatro práticas:

• Ler a documentação de verdade. Enquanto o agente rascunha, leia a referência completa — não o quickstart — incluindo os casos-limite. Isso muda o próximo prompt: você para de guiar a IA por “vibes” e passa a guiá-la com um mapa.
• Escrever a especificação antes do código. Não um ticket, uma página: o que deve fazer, o que não deve, o que significa “pronto” e o que exige revisão humana. No quase-desastre, uma linha — “sem permissões coringa, liste cada ação” — teria evitado tudo.
• Falar com um humano. O modo de falha do trabalho assistido por IA não é código ruim, é código não examinado — e uma segunda pessoa é o exame mais barato disponível.
• Registrar decisões em público. Notas de trabalho curtas, postadas onde colegas possam ler e discutir.

O princípio de fundo: sua capacidade ociosa gerada pela IA vale mais gasta no que a máquina não consegue fazer do que em rodar mais máquinas.

Sete regras práticas

Singh fecha com uma lista direta: especificação primeiro, sempre; nunca mesclar um diff que você não consiga explicar; segurança, permissões, dados e dinheiro passam por olhos humanos; lotes pequenos (um agente, uma tarefa, um PR); inclua tempo de verificação na estimativa; pergunte à IA o porquê, não só o quê; e reserve um dia por semana sem agentes — não como penitência, mas como manutenção do julgamento.

O alerta final é sobre os juniores: a IA produz no primeiro dia a versão “intermediária” do código, o que pode fazer alguém parecer produtivo muito além do que entende — e a lacuna não aparece no PR, mas em produção, meses depois. “Não é que a IA escreva código ruim. É que removemos silenciosamente o mecanismo pelo qual as pessoas aprendiam a distinguir o bom do ruim — e não colocamos nada no lugar.”