É claro que o DHH deixa a IA escrever o código dele

A polêmica

Na semana passada, o DHH, criador do Ruby on Rails, disse que não está mais escrevendo código na mão. Agora ele deixa a IA escrever.

A reação foi barulhenta, e dá para entender. Há cerca de um ano, ele era um dos céticos mais declarados da nossa indústria. Disse que nunca deixaria uma IA escrever o código dele e que, se um dia chegasse a esse ponto, preferia se aposentar.

Boa parte da comunidade leu a notícia como uma virada surpreendente. Para mim, fez todo o sentido. Aliás, olhando para o que o Rails sempre foi, era quase inevitável.

O Rails era um agente de código antes dos agentes de código

O Rails nasceu com uma obsessão: velocidade de desenvolvimento. E chegou lá por meio de Convention over Configuration. Siga as convenções, e o framework toma centenas de decisões por você.

Ele empilhou abstração sobre abstração:

• O próprio Ruby é uma linguagem de alto nível, e uma das que mais se aproximam da linguagem natural. 3.days.ago e user.posts.where(published: true) se leem quase como inglês.
• O Rails implementou uma quantidade enorme de lógica para nós. MVC e rotas RESTful vinham por padrão. O Active Record transformava tabelas em objetos. Migrations, validações, mailers, jobs em background: tudo convencional, tudo pronto.
• Os geradores vieram desde as primeiras versões. rails generate scaffold Post title:string body:text entregava model, migration, controller, views, rotas e testes em segundos.

Pense no que esse último item realmente é. Você descreve o que quer em algo próximo da linguagem natural, e código funcionando sai do outro lado. É exatamente o que os agentes de código fazem hoje. O Rails fazia isso, num escopo estreito mas muito útil, duas décadas atrás.

A famosa demo de "crie um blog em 15 minutos" não era sobre digitar rápido. Era sobre não precisar digitar a maior parte do código.

Por que a mudança aconteceu agora

É exatamente por isso que o ceticismo do DHH há um ano fazia sentido.

Se você já trabalha com uma das stacks mais produtivas já criadas, a régua para uma ferramenta nova é muito alta. Pouco mais de um ano atrás, os agentes de código não passavam dessa régua. Exigiam muito esforço para conduzir e muitas vezes produziam código verboso, inconsistente ou simplesmente errado. Para quem trabalhava com Rails, a troca era ruim: mais tempo revisando e corrigindo do que se levaria escrevendo Rails idiomático na mão.

Isso mudou. Os modelos e os harnesses de agentes mais recentes estão muito melhores em seguir convenções, ler uma base de código existente, rodar testes e iterar sobre o próprio resultado. A experiência de desenvolvimento agora é genuinamente diferente, e genuinamente mais rápida.

Quando uma ferramenta fica boa o bastante para superar um framework que já era altamente produtivo, migrar para ela não é trair os valores desse framework. É o mesmo valor, velocidade de desenvolvimento, levado um passo adiante.

Só mais uma camada de abstração

A história do software é uma história de subir camadas de abstração:

1. Do binário e do código de máquina para o assembly.
2. Do assembly para linguagens de baixo nível como C.
3. De linguagens de baixo nível para as de alto nível, como Ruby, Python e JavaScript.
4. De SQL escrito na mão e encanamento complexo de banco de dados para frameworks convencionais e ORMs.
5. E agora, de escrever código para descrever a intenção para LLMs e agentes de código.

Cada passo veio acompanhado das mesmas preocupações. "Programador de verdade escreve assembly." "Frameworks escondem coisa demais." "Você não vai entender o que está acontecendo por baixo." E toda vez a indústria subiu mesmo assim, porque o ganho de produtividade era grande demais para ignorar.

A IA é o próximo degrau dessa escada. Não é mágica, nem o fim da programação. É um novo nível de abstração.

As habilidades não desaparecem. Elas se empilham.

Esta é a parte que costuma se perder no hype. O Rails nunca tornou desenvolvedores desnecessários. Um scaffold te dava um CRUD funcionando em segundos, mas saber o que construir, como modelar o domínio e quando quebrar as convenções continuava sendo com você. Quem já herdou uma aplicação Rails feita inteira de scaffolds, por alguém que nunca aprendeu de verdade o framework, sabe como essa história termina. Com a IA é igual, só que numa escala muito maior.

Acho útil pensar nisso como uma stack. Estamos acostumados a falar de stack tecnológica: banco de dados, backend, frontend, infraestrutura. Cada camada depende da que está embaixo. Engenheiros de software que trabalham com IA agora precisam de uma stack de habilidades que funciona do mesmo jeito. Há uma fundação de habilidades tradicionais de engenharia, e uma nova camada de habilidades específicas de IA construída em cima dela. Tire a fundação, e a camada de cima não tem onde se apoiar.

A fundação importa mais, não menos

A fundação é tudo aquilo de que sempre precisamos. Nada disso perdeu importância quando os agentes começaram a escrever código. A maior parte ganhou importância, porque um agente amplifica o julgamento de quem o conduz, seja ele bom ou ruim.

Comece pela modelagem de domínio. Um agente sabe muito sobre código em geral e nada sobre o seu negócio. Ele não sabe que um "pedido" na sua empresa pode ser dividido entre três centros de distribuição, ou que "membro" e "usuário" não são a mesma coisa. Se você não entende o problema bem o suficiente para dar os nomes certos, o agente vai dar os nomes errados com toda a tranquilidade, e cada arquivo que ele gerar depois vai carregar esse erro adiante.

Depois, arquitetura de software. Quando escrever código era caro, uma má decisão de arquitetura se espalhava devagar, um pull request por vez. Hoje um agente gera o equivalente a uma semana de código numa tarde, e uma má decisão se espalha na mesma velocidade. Fronteiras, dependências, fluxo de dados, onde o estado mora: eram coisas que dava para ajustar pelo caminho. Agora elas decidem se o que o agente produz vai se acumular em um produto ou em uma bagunça. E o agente não vai pesar esses trade-offs por você. Ele vai escolher algo que funciona hoje.

Ler código talvez seja a habilidade que mais cresceu. A maioria de nós agora revisa muito mais código do que escreve, e esse código é escrito com confiança, mesmo quando está errado. Um agente nunca diz "não tenho certeza sobre essa parte". Perceber o bug sutil, a checagem de autorização que faltou ou a query N+1 escondida dentro de um método com cara de limpo é responsabilidade sua. Essa capacidade não vem de escrever prompts. Vem de anos escrevendo, quebrando e consertando código você mesmo.

Testes também mudaram de papel. Não são mais só uma rede de segurança. São como você diz ao agente o que significa "pronto", e como você descobre, rápido, que não está. Um engenheiro que sabe o que testar, e em qual nível, tira muito mais de um agente do que alguém que deixa o agente testar as próprias suposições.

Debugging também não foi a lugar nenhum. Quando algo quebra em produção às 2 da manhã, um agente pode ajudar a vasculhar logs e sugerir correções, mas alguém ainda precisa entender como o sistema realmente se comporta sob carga, com dados reais, entre serviços. Agentes são bons em corrigir o sintoma que está na frente deles. Encontrar a causa exige um modelo mental do sistema inteiro, e construir esse modelo mental é trabalho seu.

Por fim, segurança, performance e manutenibilidade: o que separa uma demo de um produto. Agentes otimizam para "funciona agora". Eles não perdem o sono com ataques de injeção, com uma query que vai bem com mil linhas e cai com dez milhões, ou com o engenheiro que vai precisar mexer nesse código daqui a dois anos. Se preocupar com isso continua sendo trabalho humano.

Por baixo de tudo isso há um ponto mais silencioso. Saber como é um código bom, o que engenheiros experientes chamam de bom gosto, é o que permite conduzir um agente. Você não reconhece uma solução ruim se nunca aprendeu como é uma boa. Por isso a experiência não está perdendo valor na era da IA. Ela está virando alavanca.

A nova camada por cima

Em cima dessa fundação vem um novo conjunto de habilidades. Engenharia de prompt é a mais visível, mas é a parte mais fina. Comunicar a intenção com clareza importa, mas é só o começo.

Engenharia de contexto é onde a coisa fica séria. Um agente só é tão bom quanto aquilo que ele consegue ver: as partes relevantes da base de código, as convenções, a documentação, os exemplos de "é assim que fazemos aqui". Decidir o que entra nesse contexto, e o que fica de fora, é na prática um exercício de entender o seu próprio sistema. Não dá para curar o contexto de uma base de código que você não entende.

Engenharia de harness é o ambiente em que o agente trabalha: as ferramentas que ele pode chamar, os comandos que pode rodar, as permissões que tem, os testes e linters que dão feedback. É a velha mentalidade de DevOps e ferramental aplicada a um novo tipo de colaborador.

Desenvolvimento orientado a especificação (spec-driven development) resgata algo que muitos times abandonaram em silêncio: escrever o que você quer antes de construir. Uma boa especificação, com requisitos claros e critérios de aceite, é a diferença entre um agente que entrega e um agente que se perde. Escrever uma boa spec exige o mesmo entendimento de domínio e senso de produto de sempre.

Depois vêm decomposição e verificação: quebrar o trabalho em tarefas pequenas o bastante para o agente terminar e para você conferir, e construir os testes, evals e hábitos de revisão que dizem se o resultado está realmente certo. Conforme o trabalho cresce, entra também a orquestração. Rodar vários agentes ou sessões na mesma base de código sem que um atropele o outro é, na prática, coordenação, a mesma coisa que um tech lead faz com um time.

Repare no padrão: cada uma dessas novas habilidades é uma habilidade antiga com roupa nova. Engenharia de contexto é conhecer o seu sistema. Spec-driven development é levantamento de requisitos e modelagem de domínio. Engenharia de harness é ferramental e DevOps. Verificação é teste. Orquestração é liderança técnica. A nova camada só funciona por causa da fundação que está embaixo dela.

Engenheiros vs. vibe coders

É aqui que a linha entre engenheiros de software e vibe coders fica clara.

Um vibe coder trabalha só na camada de cima. Escreve o prompt, aceita o que sai e julga o resultado pelo fato de parecer funcionar. Para ser justo, é um jeito perfeitamente válido de construir um protótipo, um projeto de fim de semana ou uma ferramenta interna da qual ninguém depende. Não sou contra. Os problemas começam quando esse código encontra usuários reais, dados reais e escala real. Sem um modelo mental do sistema, não há como depurar, proteger ou alterar sem quebrar outra coisa. Cada novo prompt vira um lance de dados.

Um engenheiro de software usa exatamente as mesmas ferramentas, mas é dono do resultado. Ele sabe por que o código tem essa forma, quanto vai custar mudá-lo e onde ele vai falhar. A diferença não está na ferramenta. Está no julgamento e na responsabilidade.

Quando o custo de escrever código cai para perto de zero, o valor se desloca para outro lugar: decidir qual código deve existir e saber se ele está correto. Essa é a habilidade escassa agora, e ela é construída exatamente sobre os fundamentos que algumas pessoas estão correndo para declarar obsoletos.

Não, não estamos ficando obsoletos

Tem gente que usou a declaração do DHH como prova de algo mais sombrio. Se nem o criador do Rails escreve mais código, dizem, os programadores estão acabados.

Eu leio exatamente ao contrário. O DHH não se aposentou. Ele continua construindo software, continua tomando as decisões de arquitetura, continua definindo o que é código bom. O que mudou foi como o código é digitado, não quem é responsável por ele. A pessoa com as opiniões mais fortes sobre como software deve ser escrito acabou de mostrar que essas opiniões continuam necessárias. São elas que conduzem a IA.

A história aponta na mesma direção. Compiladores não acabaram com a programação; permitiram que muito mais gente programasse. Linguagens de alto nível e frameworks como o Rails não encolheram a indústria; tornaram o software barato o bastante para que todo mundo quisesse mais dele. Cada vez que o custo de construir software caiu, a demanda por software cresceu.

Isso não quer dizer que nada muda. A parte do trabalho que era basicamente digitar boilerplate está indo embora, mas os geradores do Rails já estavam comendo essa parte vinte anos atrás. Papéis vão mudar, algumas tarefas vão desaparecer, e engenheiros que se recusarem a aprender a nova camada vão ter mais dificuldade. Isso foi verdade em toda mudança da nossa indústria. O que não fica obsoleto é a capacidade de entender um problema, projetar um sistema e assumir a responsabilidade por ele funcionar.

Mesma filosofia, nova ferramenta

O DHH não abandonou a filosofia do Rails. Ele a seguiu.

O Rails sempre perguntou: qual é o caminho mais rápido entre uma ideia e um software funcionando, sem abrir mão da qualidade? Por vinte anos, a resposta foi convenções, geradores e uma linguagem bonita. Hoje, a resposta inclui a IA.

Os desenvolvedores que vão se dar bem não serão os que recusam a nova camada, nem os que confiam nela cegamente. Serão os que trazem fundamentos sólidos de engenharia para ela, e aprendem as novas habilidades que ela exige.

E você: a IA mudou a forma como você escreve código neste último ano, ou você ainda está onde o DHH estava doze meses atrás?