Voltar ao blog
Inteligência Artificial

O criador do Rails não lê mais o código que a IA escreve. E você, deveria?

No Rails World, o DHH anunciou que a 37signals parou de escrever código à mão e que ele nem olha o Rust que os agentes geram. Funciona pra ele. Antes de copiar, vale entender o que segura isso em pé.

Guilherme Chaves6 min de leitura
O criador do Rails não lê mais o código que a IA escreve. E você, deveria?

No dia 23 de setembro, em Austin, o David Heinemeier Hansson abriu o Rails World com uma hora de palestra em que falou de quase tudo, menos de Ruby. E o DHH é o criador do Rails, o framework por trás do Shopify, do GitHub e do primeiro Twitter. Quem contou na transcrição achou a palavra onze vezes. Um dos blogs que cobriram o evento chamou aquilo de "o funeral mais confuso que eu já fui".

A frase que ele usou foi "pencils down", lápis na mesa. Na 37signals, a empresa dele, escrever código à mão deixou de ser o trabalho normal. Virou exceção, coisa que acontece quando o agente erra e alguém precisa consertar a máquina. Ele perguntou pra plateia quantos ainda escreviam código à mão toda semana. Levantaram umas cinco mãos.

O HEY, o serviço de e-mail deles, está sendo reescrito com o backend em Rust, uma linguagem que o DHH sempre disse detestar. "Rust pra mim é como jogar ácido nos olhos", nas palavras dele, "a linguagem mais feia inventada nos últimos 40 anos". Agora ele acha o Rust ótimo, com uma condição: "desde que você nunca, nunca, nunca precise olhar pra ele". Quem escreve são os agentes. Ele não lê, e chamou isso de privilégio: o privilégio de não ter a menor ideia do que está saindo.

Eu assisti ao vídeo concordando com a cabeça e desconfiando com o resto. Ele tem razão em boa parte. Só que a parte em que ele tem razão ainda não vale pra sua empresa, e o motivo ficou de fora da palestra.

Os números que ele mostrou

Em 21 anos, o DHH escrevia por volta de 30 mil linhas de Ruby por ano. Só em agosto deste ano ele produziu 150 mil linhas, com a ressalva dele mesmo de que Rust é mais verboso e infla a conta. Nos últimos 20 meses saiu metade de todo o código que ele tinha escrito na vida.

O HEY novo, segundo ele, usa 99% menos CPU e 95% menos memória que a versão em Rails. A conta de guardanapo diz que o pico de tráfego caberia num Raspberry Pi. Um dos engenheiros que comentaram a palestra avisou: são números dele, de uma reescrita ainda em andamento, sem benchmark publicado, e comparar um sistema maduro em Rails com um serviço novo e mais enxuto em Rust nunca é uma comparação justa. Mesmo descontando isso, a direção é clara. Ficou barato demais produzir código pra continuar produzindo na mão.

O HEY também vai deixar de ser um site pra virar seis aplicativos nativos, iOS, Android, Windows, Mac, Linux e web, feitos ao mesmo tempo por um time pequeno. Dois anos atrás isso era orçamento de empresa grande. Ele disse que os primeiros resultados apareceram em dias.

O que segura isso em pé

O DHH não lê o código, mas ele avalia o resultado. Ele mesmo descreveu o fluxo: o engenheiro descreve o que quer, o agente implementa, o engenheiro volta e julga o que saiu pelo comportamento. Isso só funciona porque atrás tem um time que conhece o produto há 20 anos, uma suíte de testes que diz na hora quando algo quebrou e uma operação que mede CPU, memória e erro em produção o dia inteiro. Quando o agente erra, a 37signals percebe em minutos. Não olhar o código é o que sobra depois que todo o resto está no lugar.

Tira isso e o mesmo fluxo vira o cenário do post sobre o agente que fugiu do teste: um sistema que ninguém entende, com acesso a coisa de verdade, e que vai avisar que deu errado quando o cliente ligar. Um dos comentários mais lúcidos que eu li sobre a palestra resume bem: o código continua tendo dono, e os agentes passam essa posse pra quem aprova e opera. Se ninguém no seu fornecedor consegue diagnosticar o que o agente escreveu, o Rust não tem culpa. Só não sobrou ninguém que responda por ele.

Quem não lê o código precisa de alguém que leia o resultado. Se ninguém faz nenhum dos dois, não é automação, é abandono.

O que muda pra quem contrata

Pra você, que contrata software em vez de escrever, três coisas ficaram diferentes depois desse setembro.

  • O preço de construir caiu de verdade, e vai cair mais. Se o seu fornecedor ainda cobra tela por tela como em 2023, pergunte por quê. Os 80% visíveis de qualquer sistema saem numa fração do tempo, e essa economia tem que aparecer no seu orçamento.
  • "Quem escreveu" deixou de ser a pergunta. Daqui a pouco a resposta vai ser sempre "um agente", e isso não diz nada sobre a qualidade. A pergunta que diz alguma coisa é "quem leu, quem testou e quem responde quando quebrar". Se a resposta for "ninguém olhou, mas funciona", você está contratando o privilégio do DHH sem a estrutura do DHH.
  • Aplicativo nativo voltou a caber no orçamento. Se a sua ideia morreu há dois anos porque "app pra iPhone e Android custa demais", vale reabrir a conversa. O custo de fazer os dois mudou de patamar.

E uma coisa que não mudou: saber o que construir. O DHH gastou boa parte da palestra dizendo que inglês virou a melhor linguagem de programação. Concordo, e é por isso mesmo que descrever bem o que você quer virou a parte mais cara do projeto. Um agente faz em sete minutos a coisa errada com a mesma confiança com que faz a certa.

Como eu trabalho hoje

Eu também não escrevo mais a maior parte do código na mão. O agente escreve, eu leio o que importa, testo com dado de verdade e decido. Em código que vai lidar com dinheiro, dado de cliente ou integração com terceiro, eu leio linha por linha, porque é ali que o erro custa caro. Numa tela de cadastro, confio no teste e no comportamento e sigo em frente.

O método é parecido com o do DHH. O que muda é o tamanho da cerca. Ele pode não olhar porque tem 20 anos de produto, testes e monitoramento segurando. Um projeto novo, de uma empresa que está contratando o primeiro sistema dela, ainda não tem nada disso. Alguém precisa construir essa cerca antes de ganhar o direito de parar de olhar, e nos projetos daqui esse alguém sou eu.

Então, quando você perguntar "isso aqui foi a IA que fez?", a resposta vai ser sim, em grande parte. A pergunta seguinte, "e quem leu?", vem com nome e sobrenome, porque você fala direto com quem desenvolve, e quem desenvolve é quem leu.

Fontes

Tem um projeto em mente?

Fale direto com quem desenvolve. Sem intermediários, sem surpresas.

Iniciar Projeto