DHH abriu o Rails World 2026, em Austin, dizendo que escrever código à mão deixou de ser uma habilidade economicamente viável pra maioria dos programadores na maioria das empresas. Na 37signals, o time dele já não coda rotina - dirige agente, avalia resultado, ponto final. Tio Bob, que programa desde o fim dos anos 60, anunciou em julho que parou de ler o código que os próprios agentes escrevem: a estratégia dele agora é cercar o agente de teste unitário, gherkin, mutation testing, e confiar no que sobrevive à bateria. Torvalds, no Open Source Summit India, foi na mesma linha - "eu mal leio código hoje. Não sou mais programador, sou tech lead" - ele lê descrição de PR, entende a intenção, segue em frente. E quando o Fabio Akita assistiu à keynote do DHH, a primeira pergunta dele foi se aquilo não invalidava o resto da programação técnica do evento - todas as palestras mostrando trecho de código.
Eu mesmo não abro o vim há um tempo. Então não vou fingir que acho isso um exagero ou bobagem de gente querendo hype.
Mas também escrevi, há um tempo, que você não usa IA, você delega raciocínio - e isso é o problema. E à primeira vista, os dois textos parecem se contradizer. Um diz "pare de aceitar output sem entender". O outro diz "essas quatro referências da área pararam de olhar output linha por linha e estão bem". Qual dos dois é verdade?
Os dois. Só que em camadas diferentes.
O erro que eu apontava naquele texto não era "usar IA pra escrever código". Era parar de pensar - aceitar o que sai do chat sem validar contra o problema real, sem saber o que acontece com input malicioso, sem conseguir debugar aquilo em produção. O filtro que eu propus era simples: você consegue explicar esse código pra um júnior sem abrir o chat de novo? Sabe o que quebra se o input vier errado? Funciona sem a IA no meio?
Agora repara no que DHH, Tio Bob e Torvalds estão realmente descrevendo. Nenhum deles disse "aceito o que a IA me dá e sigo em frente sem pensar". Tio Bob descreveu, com detalhe de quem passou 60 anos escrevendo código, uma bateria de constraint - teste unitário, gherkin, QA, mutation testing - que ele mesmo desenhou pra que o agente não consiga produzir nada ruim sem que algo quebre primeiro. Isso não é ausência de raciocínio. É o raciocínio dele codificado em outra camada: em vez de estar na linha 40 de um arquivo, está no desenho do gauntlet que aquela linha 40 precisa sobreviver. Torvalds troca "ler diff" por "entender intenção do PR" - mas continua sendo ele quem decide se aquela intenção faz sentido pro kernel. Nenhum dos três abdicou do julgamento. Eles mudaram o objeto sobre o qual exercem esse julgamento: de código pra contrato, de implementação pra critério de aceite.
É isso que "orquestrar" quer dizer de verdade - e é aqui que a maior parte do discurso sobre "vibe coding" e "agent-first" erra feio. Orquestrar bem exige exatamente a mesma coisa que escrever bom código sempre exigiu: entendimento de sistema, previsão de consequência, capacidade de desenhar um contrato de saída que não deixa passar lixo. A diferença é só o nível de abstração em que você aplica isso. Um dev júnior que troca "aceitar o que o chat responde" por "aceitar o que o agente entrega sem revisar o gauntlet" não evoluiu - só trocou de forma de delegar raciocínio. Continua sendo o mesmo problema, com um verniz de "orquestração" em cima.
Isso levanta a pergunta que a discussão de "vibe coding" evita: quem realmente entende o software que tá rodando em produção? Teste, agente, review automatizado e boa descrição de PR reduzem risco, mas nenhum deles sozinho responde isso.
Minha resposta é que, no fim das contas, isso não importa - pelo menos não do jeito que a pergunta sugere. O que importa é a biblioteca de contexto que você tem: gerada por ferramenta de IA ou não, UML, documentação de endpoint, e agora a ai-memory do Fabio Akita, guardando decisão atrás de decisão. Esse contexto não é pra você guardar de cabeça. É pra IA consultar. Se o contexto for suficiente, ela reconstrói em segundos o que um loop faz e por que faz - sem precisar que um humano tenha aquilo memorizado.
O teste que proponho aqui não é mais "você consegue explicar pra um júnior" - é "seu agente consegue reconstruir isso sozinho, consultando o que você deixou registrado?". Se a resposta for não, o problema não é ter parado de ler código. É não ter construído a biblioteca de contexto que substituiria essa leitura.
DHH, Tio Bob e Torvalds não pararam de ler código porque confiam cegamente no agente. Pararam porque, de um jeito ou de outro, construíram contexto suficiente ao redor do processo - teste, critério de aceite, descrição de PR - pra que a resposta certa apareça rápido, com ou sem eles lendo linha por linha. É essa biblioteca, não a experiência acumulada na cabeça de ninguém, que decide se orquestrar é orquestração de verdade ou só delegação de raciocínio com nome bonito.
