DHH e a execução sem fim: o que muda quando o agente escreve

David Heinemeier Hansson não é um entusiasta óbvio de IA. Criador do Ruby on Rails, cofundador da 37signals e conhecido por posições fortes contra modismos da indústria, ele passou anos torcendo o nariz para promessas exageradas de automação. Por isso a virada dele chama atenção: DHH conta que hoje quase não escreve código à mão e delega a construção a agentes de IA, mantendo o mesmo padrão de qualidade que sempre defendeu. Quando um cético desse porte muda de lado, vale entender o que ele viu, e o que isso significa para quem opera IA em produção.

O que ele disse

Nos textos que publicou no seu blog e numa conversa detalhada com Gergely Orosz, DHH descreve uma mudança de rotina, não só de ferramenta. O ponto que ele faz questão de marcar é que a virada não veio principalmente do modelo ficar mais inteligente. Veio das ferramentas ao redor do modelo. O agente hoje controla o terminal, roda os testes para validar o próprio trabalho, busca documentação na web e usa serviços externos com instruções dadas em inglês simples. Foi esse conjunto, e não um salto de raciocínio puro, que fez os agentes ganharem vida para ele.

O resultado ele batiza de execução sem fim. A ideia é que toda hipótese, todo palpite e todo experimento passam a ficar ao alcance imediato. Antes, a distância entre ter uma ideia e ver ela rodando era grande o suficiente para matar a maioria das ideias na fila. Com o agente executando, essa distância encolhe, e a economia de tentar coisas muda. Para alguém com ideias em excesso, ele diz, isso é uma espécie de nirvana.

DHH ainda leva o argumento para o terreno do open source. Ele defende que os agentes democratizam a contribuição, porque abaixam a barreira técnica para participar, e critica projetos que passaram a barrar contribuições feitas com ajuda de IA. Para ele, tratar contribuição assistida como algo a proibir é uma forma de reserva de mercado, um portão erguido justo quando a promessa histórica do software livre finalmente poderia se cumprir para mais gente.

Por que a voz dele importa

A tese de DHH interessa porque ele não está vendendo modelo nem ferramenta. Ele é operador: constrói e mantém produtos que rodam para clientes pagantes há mais de vinte anos. Quando ele diz que mudou o modo de trabalhar, é evidência de campo, não pitch. E a evidência bate com um consenso que vem se formando entre vozes técnicas sérias. É a mesma direção que Andrej Karpathy aponta ao falar de um software mais verificável, onde o humano especifica e checa em vez de digitar linha por linha.

Também é um contraponto interessante a leituras mais céticas. Kent Beck avisa que, no fundo, ninguém quer agentes pelo agente: as pessoas querem resultado, e o agente é meio, não fim. DHH não discorda disso, ele mostra o outro lado da moeda: quando as ferramentas ao redor do agente amadurecem a ponto de ele rodar testes e se autocorrigir, o meio fica bom o suficiente para virar rotina de trabalho de um veterano exigente. As duas visões convivem. O agente só vale quando entrega, e chegou num ponto em que, para certos trabalhos, entrega.

A leitura crítica para quem opera

O erro seria ler DHH como um convite a acelerar sem freio. A parte mais útil da tese dele é justamente onde ela expõe o novo gargalo. Se a execução vira barata e quase infinita, o que passa a ser escasso não é a capacidade de produzir código, é a capacidade de decidir o que merece ser construído e de julgar o que voltou. Digitar deixa de ser o limite. Gosto, revisão e verificação viram o limite.

Isso tem três consequências práticas para um time.

A primeira é que o julgamento técnico fica mais valioso, não menos. Para revisar bem o que o agente produziu, você precisa reconhecer código inchado, sentir quando uma escolha vai cobrar juros e saber o que é uma boa solução. Quem não tem esse repertório não vira sênior por ter um agente, vira alguém que aprova o que não entende. A mesma lição aparece quando Martin Fowler lembra que o valor imediato da IA é entender o código que já existe: o difícil nunca foi escrever, foi compreender e decidir.

A segunda é que a priorização vira o músculo central. Se você pode tentar tudo, tentar tudo é a pior estratégia possível. A execução sem fim só produz valor se estiver acoplada a um jeito disciplinado de escolher o que construir, o que nos leva para técnicas como o impact mapping, que liga o que você constrói ao resultado que você quer. Sem esse acoplamento, execução sem fim é só desperdício sem fim.

A terceira é que a verificação precisa acompanhar a velocidade. Produzir mais rápido também produz dívida e risco mais rápido. O contrapeso é operacional: teste que o próprio agente roda, revisão humana de verdade e um orçamento de erro que diz quando desacelerar. DHH mantém padrão alto porque tem essas redes. Copiar a velocidade dele sem copiar a disciplina é a receita para acelerar direto contra a parede.

O que fazer com isso na segunda de manhã

A tese da execução sem fim é uma boa notícia disfarçada de alerta. Boa porque o custo de experimentar caiu, e times que sabem escolher e verificar vão validar mais em menos tempo. Alerta porque o mesmo movimento premia quem tem julgamento e pune quem só tem pressa. O trabalho de quem lidera, agora, é menos sobre destravar a execução e mais sobre proteger as duas pontas que o agente não cobre: decidir bem o que entra na fila e julgar bem o que sai dela.

Se o seu time já sente a execução ficar barata mas está afogado na revisão e sem critério de priorização, chame a gente no WhatsApp para montar os freios certos sem perder a velocidade nova.