O que DHH afirmou e por que isso virou notícia

Em 16 de janeiro de 2026, , criador do e cofundador da , disse em um podcast que as ferramentas de IA para programação ainda não produzem código tão bem quanto “a maioria dos programadores juniores” com quem ele já trabalhou. Ele comparou a experiência de usar IA hoje a uma “lâmpada piscando”: momentos de clareza intercalados com apagões — o que torna difícil confiar no resultado sem revisão cuidadosa.

O ponto mais polêmico veio logo depois: Hansson também se mostrou cético com a tese de que empresas podem demitir parte do time de engenharia e, mesmo assim, ir mais rápido “substituindo” pessoas por IA. Para ele, isso ignora o trabalho real de software: decisões, manutenção, trade-offs e qualidade ao longo do tempo — não apenas “gerar linhas de código”.

O exemplo de Fizzy: “95% do código foi escrito por humanos”

Para sustentar o argumento, Hansson citou o desenvolvimento do , produto recente da 37signals: segundo ele, cerca de 95% do código foi escrito por pessoas. A equipe até experimentou recursos “AI-powered”, mas essas tentativas acabaram descartadas (ficaram “na sala de corte”) por não atingirem o padrão desejado.

O próprio contexto do produto ajuda a entender a postura: o Fizzy foi apresentado publicamente em 3 de dezembro de 2025 como uma alternativa mais simples e rápida para kanban e rastreamento de bugs/ideias — uma reação ao que a empresa descreve como “bloat” e complexidade excessiva em ferramentas populares do mercado.

Em outras palavras: não é que a 37signals seja “anti-IA” por ideologia. O recado é mais pragmático: se o objetivo é entregar software enxuto, com comportamento previsível e manutenção tranquila, a IA ainda não dá para ser colocada no volante sem alguém com carteira de motorista do lado.

O que isso muda para times e para quem está começando

Esse tipo de declaração incomoda porque vai contra duas narrativas populares: (1) “IA já escreve tudo sozinha” e (2) “júnior virou dispensável”. A visão de Hansson sugere um cenário mais realista para 2026: IA pode ajudar, mas a régua de qualidade e o custo de correção ainda exigem gente que entenda profundamente o produto — especialmente em software comercial, onde bugs custam reputação e suporte.

Na prática, para empresas e desenvolvedores, a leitura útil é:

• Use IA para acelerar rascunhos e exploração, não para terceirizar responsabilidade técnica.
• Meça produtividade por entrega estável (menos retrabalho, menos incidentes), não por volume de código.
• Invista em formação: se a IA fizer o “fácil”, a base (debug, testes, arquitetura, leitura de código) fica ainda mais valiosa.

Fechamento

A fala de Hansson, repercutida pelo , não é um “anti-hype” gratuito: é um lembrete de que software não é só digitar código — é sustentar decisões, qualidade e manutenção. Se a IA ainda oscila entre brilho e blackout, talvez a pergunta certa não seja “quantos devs posso demitir?”, e sim “onde a IA realmente aumenta a clareza — sem virar mais uma fonte de incerteza?”.