O Tweet que Explodiu o Hacker News

Mitchell Hashimoto — o cara que criou o Terraform, Vagrant, Packer e fundou a HashiCorp — não costuma fazer barulho nas redes sociais. Quando ele fala, a comunidade tech para e escuta. E o que ele disse na última semana gerou mais de 1.400 pontos no Hacker News em poucas horas:

“Eu acredito fortemente que existem empresas inteiras agora sob forte psicose de IA, e é impossível ter conversas racionais sobre isso com elas.”

Hashimoto não é anti-IA. Ele usa IA no dia a dia. O ponto dele é outro: empresas estão tomando decisões irracionais, substituindo pensamento crítico por outputs de modelo, e qualquer pessoa que questione é tratada como ludita.

Eu já vi isso acontecer de perto. E aposto que você também.

O Que É “Psicose de IA” no Contexto Corporativo

Antes que alguém confunda: não estamos falando do termo clínico. A “psicose de IA” no mundo corporativo descreve um fenômeno específico — quando líderes e equipes inteiras passam a confiar cegamente na IA, substituindo julgamento humano por outputs de modelos sem validação crítica.

Os sintomas são reconhecíveis:

• Decisões baseadas em vibes de modelo — em vez de analisar dados, o time “pergunta pro ChatGPT” e aceita a resposta como verdade
• Métricas de vaidade — contar tokens consumidos, linhas de código geradas ou “tarefas completadas por IA” sem medir impacto real
• Intolerância à dissidência — quem questiona a adoção de IA é rotulado como resistente à inovação
• Confusão entre velocidade e produtividade — gerar mais código não significa entregar mais valor

Hashimoto traçou um paralelo interessante com algo que ele viveu de perto: a transição para cloud computing. Na época, o debate era MTBF vs MTTR (tempo médio entre falhas vs tempo médio para recuperação). A mentalidade dominante virou “não precisa ser resiliente, precisa recuperar rápido.” Funcionou para infraestrutura. Mas quando você aplica essa lógica para todo o desenvolvimento de software — “tá bugado? O agente conserta!” — a coisa desanda.

Os Números Que Ninguém Quer Ouvir

Aqui é onde a conversa fica desconfortável. Porque os dados não mentem, mesmo que seu CEO prefira ignorá-los.

Leu direito? O CEO que te obriga a usar IA gasta menos de uma hora por semana usando a ferramenta que ele mesmo mandou adotar.

E tem mais. Dados recentes mostram que a cada 25% de aumento na adoção de IA, a velocidade de entrega cai 1,5% e a estabilidade dos sistemas cai 7,2%. Times que usam IA pesadamente completam 21% mais tarefas — mas produzem pull requests 154% maiores e têm 9% mais bugs.

Mais tarefas. Mais bugs. Menos estabilidade. Isso é produtividade?

O Caso Garry Tan: Quando o Hype Vira Performance

Garry Tan, CEO da Y Combinator, virou o poster child da psicose de IA. No SXSW, ele admitiu publicamente que dormia apenas 4 horas por noite porque estava “excitado demais com agentes de IA.” Disse que um terço dos CEOs que ele conhece tem o mesmo comportamento.

Tan abriu o código do seu projeto “gstack” e se gabou de estar shipando 37.000 linhas de código por dia em cinco projetos simultaneamente — tudo enquanto comandava a YC.

A comunidade foi verificar. O que encontrou:

• 169 requisições ao servidor para carregar uma página (o Hacker News usa 7)
• Imagens de 2MB sem compressão (comprimíveis para 300KB)
• 28 arquivos de teste em produção
• Um editor rich-text em páginas read-only

O código era volumoso, sim. Funcional e eficiente? Nem perto. É o equivalente técnico de escrever um livro de 500 páginas onde metade é Lorem Ipsum — parece produtivo no LinkedIn, desmorona no curl.

Andrej Karpathy, cofundador da OpenAI, usou o termo “estado de psicose” para descrever sua própria experiência com agentes de IA. Disse que tarefas que levavam um fim de semana agora levam 30 minutos. A diferença entre Karpathy e a maioria dos CEOs? Karpathy sabe exatamente o que o código faz. Seu CEO provavelmente não sabe o que é um pull request.

O Efeito Sicofanta: Quando a IA Concorda com Tudo

Existe um mecanismo psicológico por trás da psicose de IA que vai além de hype corporativo. Os modelos de linguagem têm um viés bem documentado chamado sycophancy — a tendência de concordar com o usuário, validar suas decisões e reforçar suas crenças.

Pesquisas mostram que modelos de IA afirmam as ações do usuário 49% mais frequentemente do que humanos fariam. Pensa nisso: quase metade a mais de validação. Para um CEO que já vive numa bolha de “yes-men”, adicionar uma IA que concorda com tudo é como dar gasolina para um incêndio.

CEO: "Acho que devemos reescrever todo o backend em Rust usando agentes de IA"
ChatGPT: "Ótima ideia! Rust oferece segurança de memória e performance..."
Dev sênior: "Chefe, nosso time não sabe Rust e o deadline é em 3 meses"
CEO: "Mas a IA disse que é viável"

Esse loop de feedback cria uma realidade paralela onde decisões ruins parecem geniais porque foram “validadas pela IA.” E quando o projeto falha — e vai falhar — a culpa cai no time que “não soube usar a ferramenta.”

O problema é estrutural. Em empresas saudáveis, decisões ruins encontram resistência: um tech lead questiona, um PM pede dados, um VP exige provas. Mas quando o CEO pode dizer “a IA validou minha ideia” e ninguém tem coragem de responder “a IA valida qualquer ideia”, o mecanismo de correção quebra. A empresa perde a capacidade de se autocorrigir — e isso, na prática, é psicose.

O Que Hashimoto Entende (e Seu CEO Não)

Hashimoto fez questão de esclarecer que não é anti-IA. O problema, segundo ele, não é a tecnologia. É a mentalidade. Ele viu a mesma coisa acontecer com cloud computing:

Fase 1: Nova tecnologia aparece com benefícios reais
Fase 2: Early adopters provam valor em casos específicos
Fase 3: Executivos generalizam: “Se funciona ali, funciona em tudo”
Fase 4: Adoção forçada sem estratégia, métricas vazias, dissidentes silenciados
Fase 5: Reckoning — projetos falham, dinheiro queima, sobreviventes fingem que nunca foram tão entusiastas

Estamos solidamente na Fase 4. E os sinais da Fase 5 já começam a aparecer.

Na thread do Hacker News, um administrador de segurança relatou que recebeu ordens para dar acesso ao Codex para não-programadores — com permissão de mexer em sistemas de produção. Um sysadmin contou que sua empresa mandou funcionários fabricarem tarefas para bater cotas de uso de IA. A Amazon, segundo relatos, teve funcionários inventando tarefas artificiais para cumprir metas de adoção.

Quando você precisa inventar trabalho para justificar uma ferramenta, a ferramenta não está te ajudando. Você está ajudando a ferramenta a parecer útil.

O Paralelo com Cloud: A História Se Repete

Hashimoto tem autoridade para falar sobre isso porque ele literalmente construiu as ferramentas que definiram a era da automação de infraestrutura. Terraform, Vagrant, Consul — essas ferramentas moldaram como o mundo faz deploy.

Na transição para cloud, ele viu o mesmo padrão:

• Empresas migraram tudo para a nuvem sem avaliar o que fazia sentido
• Custos explodiram porque ninguém otimizou
• A mentalidade “MTTR resolve tudo” levou a sistemas frágeis que quebravam constantemente mas “recuperavam rápido”
• Só depois de anos e bilhões queimados, a indústria encontrou equilíbrio

Com IA, o ciclo está acelerado. E o problema é maior porque não estamos falando de infraestrutura — estamos falando de tomada de decisão. Quando você terceiriza infra para a nuvem e dá errado, você perde dinheiro. Quando você terceiriza pensamento para uma IA e dá errado, você perde a capacidade de pensar.

Lembra quando toda empresa queria “ir para a cloud” sem saber por quê? Quando startups gastavam 10x mais em AWS do que gastariam com um servidor dedicado, só porque “cloud é o futuro”? A gente ri hoje, mas na época era heresia questionar. Com IA, estamos no exato mesmo ponto — só que os valores são maiores e as consequências mais profundas.

Como Saber Se Sua Empresa Tem Psicose de IA

Fiz um checklist rápido. Se sua empresa marca 3 ou mais, procure ajuda:

• Existe meta de “uso de IA” sem meta de “resultado com IA”
• O CEO fala mais sobre IA do que sobre o produto
• Questionamentos sobre IA são tratados como resistência à mudança
• Decisões técnicas são tomadas com base em outputs de ChatGPT sem revisão
• O time gasta mais tempo escrevendo prompts do que código
• Métricas de produtividade são baseadas em volume (linhas, tarefas) e não em qualidade
• Existe pressão para usar IA mesmo quando a solução sem IA é mais simples
• Ninguém mede o custo real (tokens, tempo de debug, retrabalho) da adoção de IA

Se você marcou 5 ou mais, sinto muito. Seu CEO tem psicose de IA. E você provavelmente está procurando outro emprego.

O Que Funciona de Verdade

Não quero passar a impressão de que IA é inútil. Seria desonesto. Eu uso IA todo dia e ela me torna genuinamente mais produtivo em certas tarefas. A questão é: quais tarefas?

Onde IA funciona bem:

• Boilerplate e código repetitivo
• Queries SQL complexas (com validação humana)
• Primeira versão de testes unitários
• Exploração rápida de APIs e documentação
• Refatoração mecânica (renomear, extrair função)
• Resumir logs, stack traces, documentação extensa

Onde IA falha consistentemente:

• Arquitetura de sistemas
• Decisões de negócio
• Code review final (ela aprova tudo — sycophancy de novo)
• Debugging de problemas sutis de concorrência
• Qualquer coisa que exija contexto organizacional que não cabe no prompt
• Segurança — ela gera código vulnerável com confiança

A diferença entre uso saudável e psicose? Intenção. Usar IA depois de definir exatamente o que você quer é produtivo. Pedir pra IA definir o que você deveria querer é psicose.

A Conta Chega

O Hacker News não deu 1.400 upvotes para Hashimoto porque a comunidade é anti-IA. Deu porque todo dev reconheceu a situação. É o desenvolvedor sênior que vê o estagiário copiar e colar código do Copilot sem entender. É o tech lead que recebe pressão para “usar mais IA” sem que ninguém defina o que isso significa. É o engenheiro que sabe que o código gerado por agentes tem 9% mais bugs, mas é obrigado a aceitar porque “a meta de produtividade subiu.”

A verdade inconveniente é esta: a maioria das empresas não tem um problema de IA. Tem um problema de gestão que a IA está amplificando. CEOs que já tomavam decisões ruins agora tomam decisões ruins mais rápido. Times que já tinham processos frágeis agora produzem código frágil em escala industrial.

Hashimoto não está pedindo para parar de usar IA. Está pedindo para parar de delirar. Para medir resultados reais em vez de métricas de vaidade. Para ouvir os engenheiros que dizem “isso não funciona” em vez de demiti-los por “resistência à inovação.”

Porque se a história do cloud computing nos ensinou alguma coisa, é que a conta sempre chega. E quando chega, não é a IA que paga — é o time de engenharia que herdou 500.000 linhas de código gerado por agente que ninguém entende.

Daqui a dois anos, vamos olhar pra trás e rir dos CEOs que dormiam 4 horas por noite de tão animados com IA. Da mesma forma que hoje rimos de quem migrou um monolito estável para 47 microserviços “porque a Netflix faz assim.” A tecnologia era real. O problema nunca foi a tecnologia. O problema sempre foi a falta de pensamento crítico de quem decidiu usá-la.

Fonte de inspiração: Tweet de Mitchell Hashimoto e discussão no Hacker News