Matz, DHH e Jeremy Daer: o que significa ser rubista quando os agentes escrevem o código

Bem, sejam todos bem-vindos. Sinto que estamos todos participando de uma grande conversa. Esta tem sido uma conferência diferente de todas as outras em que já participei. E sinto que dá para tirar o R, o L e o S daquela palavra inicial ali. Porque tudo gira em torno da IA.

Agora, estamos aqui para falar sobre como moldar o futuro do Ruby on Rails. E a palestra do David ontem deixou muitas questões em aberto. Como estamos moldando o Ruby? Como estamos moldando o Rails? Foi uma visão mais ampla do que o mundo da programação como um todo está enfrentando.

E, nestes momentos, fico ouvindo as pessoas perguntarem sobre o futuro e pedirem previsões. E parece que, justamente quando o futuro está mais incerto, é quando as pessoas mais querem previsões, segurança e uma noção do que está por vir. Então, acho que podemos partir daí. Considerando que ainda não sabemos, o que podemos dizer? O que vocês preveem para o final deste ano, para o final do ano que vem? Começa com você, Matz.

Tudo muda tão rápido nos últimos anos que não dá para saber para onde as coisas estão indo. Por isso, há dois anos, eu não conseguia imaginar que deixaria de usar o Emacs como editor de código. Mas ainda uso o Emacs, aliás.

Todo o meu código está escrito no meu ambiente de código na nuvem desde novembro passado, mais ou menos. E as coisas eram totalmente diferentes de… isso é bem desafiador para mim.

David?

Acho que você está absolutamente certo. O que estamos lidando agora não é com certezas, mas com probabilidades. E a probabilidade que vejo é que, até o final do ano, como disse ontem, não será a maioria das pessoas, mas praticamente todas as pessoas que estarão programando como o Matz por meio de seus agentes.

Agora também entendo por que isso parece tão incerto. Mudar as coisas e misturar tudo dessa forma é como uma grande onda, e a gente não sabe como se equilibrar nem onde se posicionar para superar isso. Mas acho que é por isso que temos a responsabilidade coletiva de nos unirmos e nos ajudarmos mutuamente.

Primeiro, é preciso aceitar. Isso está acontecendo. Nenhum de nós tem o poder, mesmo que quiséssemos, de impedir isso. É como se estivéssemos passando rapidamente pelas fases do luto aqui. É isso que está acontecendo. E sei que muitas pessoas já superaram a raiva e estão em algum estágio de negociação com o futuro. Isso não funciona. A IA vai te ouvir e te dar atenção, mas não vai mudar sua trajetória.

Portanto, quanto mais rápido você passar pelo estágio de negociação — e, com sorte, dar uma passada rápida pela depressão — para então chegar à aceitação, esse é, na minha opinião, o único caminho a seguir. E então, quando você chegar à aceitação, espero que experimente o que eu experimentei, o que tantas pessoas já experimentaram: que o outro lado é incrível. É maravilhoso e divertido de todas as maneiras que a programação é maravilhosa e divertida, pois fazemos as máquinas realizarem coisas novas. Temos ideias e as vemos ganharem vida, e com a IA isso simplesmente acontece muito, muito, muito mais rápido.

Acho que algo particularmente intrigante nessa época é que as pessoas estão tendo essa experiência, mas também estão tendo a outra simultaneamente. Você consegue usar um agente e ver as coisas ganharem vida, mas também há… Quer dizer, eu me sinto um programador Ruby, me sinto um programador Rails, e, no entanto, faz meses que não uso o Vim para escrever código Ruby. Então, onde está minha identidade?

E ontem o David pediu que levantassem a mão quem está escrevendo código Ruby, mas vou pedir que levantem a mão de novo. Quem se sente um programador Ruby? É isso aí, pessoal.

Então, estamos em uma situação diferente — onde nos situamos nesse caminho quando a identidade, de certa forma, pode sobreviver à nossa prática? Quando nos chamamos de “Rubyistas”, mas não estamos escrevendo em Ruby, qual é o resquício que fica para trás?

Embora a tecnologia tenha mudado a nossa vida, acho que agora podemos escolher como nos sentimos nas nossas atividades e no nosso dia a dia. Por exemplo, quando a tecnologia surgiu, digamos, há 80 anos, as pessoas se preocupavam com o fato de que os empregos seriam tirados dos seres humanos e que toda a produção industrial ou algo do tipo seria feita por máquinas. Criaram filmes como “Tempos Modernos”, de Chaplin, mas as coisas aconteceram de maneira diferente, de modo que reduzimos a carga de trabalho na produção industrial ou podemos trabalhar de maneira diferente do que há 100 anos.

Esse tipo de coisa pode acontecer na próxima década, mais ou menos. E provavelmente nossas vidas como desenvolvedores de software seriam diferentes do que são hoje. Mas, mesmo assim, podemos escolher a criação tranquila, a atividade criativa de desenvolvimento de software, em vez de sermos expulsos do setor, de um emprego bem remunerado ou algo do tipo. Acho que agora é a hora de escolher o rumo, o nosso rumo, como me sinto e como nos comportamos em relação à IA.

Acho que isso realmente resume a diferença. Fiz uma palestra há alguns anos em que falei sobre o fato de não me ver como um engenheiro de software. Essa nunca foi uma identidade com a qual me identifiquei. Soava sério demais, rigoroso demais. Eu me via como um redator de software e me vejo assim há muitos anos.

Portanto, para quem já fazia parte desse grupo em que o rótulo de “engenheiro de software” já não se encaixava, acho que vocês estão em uma posição muito melhor para adotar o novo papel de criador de software. Essa é uma perspectiva mais ampla. Na verdade, há mais coisas a se considerar, mais coisas a se aprender do que apenas aperfeiçoar a arte de escrever código à mão. E minha grande descoberta é que é mais gratificante ser um criador de software do que meramente um programador. E eu adorava ser programador, mas a parte da criação, o pacote completo, é simplesmente mais gratificante.

E acho que nossa sensibilidade como programadores Ruby está excepcionalmente bem sintonizada para esta época. Qual é o valor humano que agregamos quando trabalhamos com agentes? É o bom gosto. É o senso de proporção. É o senso de beleza. Tudo o que sempre nos importou ao escrever código Ruby — a abstração disso é o que vai formar um bom criador de software, vai formar um bom desenvolvedor de agentes.

Então, vejo isso como um motivo de comemoração: o fato de a turma do Top Gun aqui estar tão bem posicionada, porque isso não tem nada a ver com o Rails. Nem mesmo tem a ver com Ruby. Essa é a parte do discurso online que acho tão intrigante, como se o que está acontecendo fosse, de alguma forma, exclusivo da nossa pequena comunidade. Vocês estão cegos? Isso vai atingir todo mundo. Para todos os domínios, para todas as bibliotecas, para todas as estruturas de trabalho, para todas as linguagens.

E há um foco estranhamente míope em: “ah, então o Rust é a próxima grande novidade”. Não dou a mínima para o Rust. Tipo, não vou me tornar um programador de Rust porque esse papel já foi abstraído de mim. O Rust é simplesmente a ferramenta mais eficiente no momento, e se amanhã alguém lançar um Rust melhor, eu mudarei sem nenhum do sofrimento que está sendo vivenciado agora nesta sala em relação às coisas do Ruby, porque não terei nenhum ego investido no Rust.

E acho que é perfeitamente possível que, em breve, o Rust nem seja mais o que estivermos usando. Iremos direto para o assembler, e o fato de ele não ser portátil não importará, porque simplesmente escreveremos o código de máquina necessário para cada plataforma em que quisermos estar, e adeus, Rust. Então, não se apegue a essa ideia de que, ah, eu tenho que mudar de lado. Os lados já não existem mais. Não estamos criando novos.

Vou abordar o que pode ser ideal para os agentes um pouco mais adiante. Acho que você tocou em uma ansiedade fundamental quando surge aquela ideia de que, se você sente a energia — ela está lá fora e está disponível —, mas se você não a sente por dentro, então há um abismo entre o que poderia ser — é quase como o que se espera de você — e, bem, não sei, a ansiedade e o receio diante das forças da natureza: como eu posso enfrentar isso?

Cada indivíduo precisa passar por essa experiência por conta própria. É como ouvir que vai haver uma demissão em massa e, bem, que basta se requalificar, fazer qualquer curso, aprender a programar. E agora, o que fazer? Então, quando falamos em “criador profissional cheio de energia”, as pessoas estão sentindo isso? E as pessoas que sempre sentiram isso já têm essa sensibilidade, então não é nada de novo. Mas, para quem está sendo convidado a adotar isso, é uma disciplina totalmente nova.

Sim. E, em parte, isso simplesmente requer que o tempo faça seu trabalho no ego. É por isso que temos os cinco estágios do luto: para explicar às pessoas que não é algo instantâneo. Para mim, não foi instantâneo. Talvez eu tenha passado por isso um pouco mais rápido do que a maioria, mas ainda assim tive que passar por esses estágios, e acho que isso é perfeitamente normal. Deve haver espaço para sentir um pouco de nostalgia por algo de que você realmente gostava antes de conseguir fazer a transição para algo que talvez você goste mais — ou não.

Cada mudança de paradigma que tivemos na área de informática deixou algumas pessoas desejando que isso não tivesse acontecido. A internet foi exatamente assim. A era dos celulares foi exatamente assim. Havia pessoas que simplesmente não queriam embarcar nesse trem e ficaram na estação. Haverá espaço para isso também.

O que me chama a atenção aqui é que comecei a usar Ruby sem nenhum interesse no valor econômico da linguagem. Gostava de Ruby porque era Ruby e era divertido de usar. E era mesmo, no sentido de que, quando as pessoas — como no seu exemplo com os retratos — não conseguem mais obter reconhecimento econômico por esse talento e conhecimento, para onde elas são redirecionadas? Bem, e se você nunca tivesse precisado disso, para começar? Talvez o Ruby esteja voltando à sua forma natural.

Ao contrário do DHH, tenho um enorme orgulho em relação ao Ruby. E toda a minha vida depende disso. Mas acho que sou parcialmente responsável, digamos, pelo aquecimento global.

É uma afirmação ousada.

Consome muita, muita energia. E, na era da IA, do ponto de vista puramente econômico, financeiro, o Ruby não é a melhor opção. Mas temos um enorme impulso e inércia em relação à gigantesca base de código do Rails — ou do Ruby.

Então, este ano, comecei a trabalhar em um compilador alternativo para Ruby chamado Spinel, que compila programas em Ruby em binários nativos. E ele roda com uma rapidez impressionante e consome muito menos memória.

Quanto?

Conforme testamos, o programa realista, em condições reais, roda com 1/20 da memória. Então, digamos que sua aplicação Rails consuma 100 megabytes de memória. O binário nativo da aplicação compilada pelo Spinel consome 20 megabytes. Portanto, isso significa que…

O quê? São 5,5 megabytes, quer dizer.

Eu só comecei o Spinel em março, então ele ainda é um bebê. Mas tem um potencial e tanto. E talvez da próxima vez ele escolha Ruby de novo. E compile para o binário nativo pra criar o backend.

Matz, gostaria de saber mais sobre isso. Afinal, você já tem a ideia do Spinel há muitos anos. E você trabalha com o mruby há muitos anos. E cada um deles ocupa um lugar diferente no mundo da engenharia e do desenvolvimento de software. Então, você sempre refletiu sobre o que o Ruby tem a oferecer — no caso do mruby, a um ambiente embarcado — ou o que o Ruby tem a oferecer aos seres humanos? E agora o Spinel parece responder à pergunta: o que o Ruby tem a oferecer aos agentes? O que faz do Ruby o Ruby? Se você retirar certos elementos, ele ainda será o Ruby?

Isso não é exatamente muito claro. Mas eu fui por tentativa e erro para definir o que é Ruby e o que não é Ruby. E o resultado é o CRuby que temos e que quase todo mundo usa. Mas não existe uma solução única para todos. Então, algumas pessoas preferem o JRuby para aplicações corporativas. O CRuby é grande demais para microdispositivos embarcados.

E então — ou talvez o próprio Ruby seja lento demais — mesmo com o compilador JIT que disponibilizamos recentemente. Então, esse subconjunto de desempenho da linguagem Ruby pode ser compilado em binário nativo e rodar com uma rapidez impressionante. E isso significa que, pelo menos por enquanto, só eu posso traçar a linha entre o que é Ruby e o que não é.

Pensando no papel do Ruby em coisas como o Roundhouse — caso nem todos conheçam o Roundhouse, trata-se de uma forma de tratar o Ruby como uma espécie de… ou uma aplicação Ruby on Rails como uma espécie de oráculo de conformidade que um agente pode consultar como uma especificação, e então ele gera Ruby puro sem o Rails ou outras linguagens. O scaffolding do Ruby está presente nisso, ou é um meio de preservar o Ruby, ou é algo que seria um único passo e, depois disso, você deixaria a aplicação em Ruby de lado?

As pessoas são diferentes. A criação de software envolve diversos aspectos. E, muito provavelmente, prevejo que a maioria das pessoas se concentre na direção do produto e na gestão do mercado do produto. Mas algumas pessoas se sentem muito motivadas pela parte da programação em si. Então, isso seria, pelo menos como carreira, algo que nos seria tirado em um futuro bem próximo.

Mas, ao mesmo tempo, isso nos faz aprender a nos concentrar em resolver nossos problemas. E se, no passado, nos faltava, digamos, capacidade, habilidade ou experiência para oferecer ou criar uma solução, agora os agentes podem nos ajudar de forma que, mesmo sem conhecimento suficiente, possamos criar uma solução de qualquer maneira. Essa é a situação.

Mas, ainda assim, pelo que vejo, nem todo mundo vai criar uma solução. A maioria de nós, a maioria dos seres humanos, está apenas esperando por soluções. Então, nesse caso, os provedores de soluções são uma espécie de “escolhidos”, como nós aqui. Portanto, a única coisa que podemos fazer é aprimorar nossa capacidade e oferecer uma solução para a humanidade como um todo. Isso é mais importante do que fornecer tecnologia específica e focar em tecnologia específica, como diz o DHH.

Mas, mesmo assim, Ruby é uma linguagem legal. E é a linguagem preferida de muita gente. E o próprio Ruby motiva as pessoas. Mesmo na era da IA, a motivação é o recurso mais importante que os seres humanos podem oferecer — algo que só os seres humanos podem oferecer, e não a IA.

Acho que o Ruby tem um papel maravilhoso a desempenhar nesse seu retorno à forma. Lembro-me de quando aprendi Ruby pela primeira vez: foi por meio de artigos na revista IEEE Magazine, escritos por Dave Thomas e outros autores, que descreviam conceitos de código usando Ruby, e eu achava que eles estavam escrevendo pseudocódigo. Achava que não era executável, mas era.

E acho que, à medida que avançamos para esse cenário em que não seremos nós mesmos a escrever a maioria das linhas de código, ocasionalmente vamos querer entender o algoritmo e saber como ele funciona — e o Ruby é a melhor linguagem de programação para explicar conceitos. Portanto, se, em vez de Dave Thomas me explicar conceitos na revista IEEE Magazine, eu agora tiver um agente que me explique meu código em Rust usando Ruby, isso parece um retorno incrível à forma.

Outra coisa que eu diria é que acho que a maioria das pessoas tem dificuldade em pensar além do “bolo fixo”. E acho que é daí que vem parte da ansiedade. Elas imaginam que o mundo do futuro terá o mesmo número de aplicativos que temos hoje e, então, imaginam que precisaremos de muito menos programadores para criar esses aplicativos. E isso vai ser verdade. O número de aplicativos que temos no mundo hoje vai exigir muito, muito menos programadores para mantê-los e desenvolvê-los.

Mas podemos criar mais. Vamos criar mais. Essa é toda a exuberância do momento: estamos criando muito mais software. Cada estatística que você vê no GitHub — e o motivo de o site ficar fora do ar a cada 5 minutos — se deve à explosão na criação de software. Esse é o florescimento. Esse é o florescimento. Teremos muito mais aplicativos para cuidar, e vamos precisar

de pessoas para fazer isso. É por isso que tenho esse enorme otimismo em relação aos programadores que aceitam o futuro e se dedicam ao seu novo papel como criadores de software. Vamos trabalhar em muito mais coisas, e isso é empolgante. É bom. É estabilidade no emprego. Mas isso não vai acontecer se você se agarrar tanto ao lápis a ponto de não conseguir imaginar que a calculadora possa te ajudar.

É interessante relembrar o início dos anos 2000 e a ascensão da Programação Extrema, quando ter uma linguagem muito fluente valia muito a pena. O custo de execução da linguagem era insignificante em comparação com os custos de desenvolvimento. E o — é claro — preço de alterar uma especificação, ter um ciclo de desenvolvimento ágil e introduzir práticas como o desenvolvimento orientado a testes. E vejo uma ironia nada pequena na situação em que nos encontramos agora. E quais são os artefatos do nosso trabalho? É o Markdown? São as especificações? É tudo o que existia antes da Programação Extrema e do qual nos livramos por causa das características negativas do longo tempo de ciclo e do alto custo — que agora são custo zero? Então, voltamos ao “grande projeto inicial” e às metodologias em cascata?

Não sei. Mas a metodologia específica e concreta é menos importante hoje em dia porque, sabe, a estrutura do código tem menos importância, já que não mexemos mais no código. Mas, então, agora precisamos, sabe, formalizar e aprender. Temos algo para formalizar e aprender nos próximos anos. É como criar uma visão do software, qual deve ser a solução, e determinar qual deve ser a solução, e qual é o problema? E, sabe, eles gerenciam a IA para construir isso… construir a solução.

Vocês conhecem o “vibe coding” e também já ouviram falar das histórias de fracasso do “vibe coding”, tipo, tudo bem criar jogos como o Tetris, mas, quando se tenta criar um aplicativo realista, muitas das tentativas fracassaram miseravelmente. Mas, em contraste, as pessoas ao nosso redor, ao meu redor, como os colaboradores do Ruby, tentam programar ao vivo nas ferramentas, como parte da filosofia do Ruby no estilo “live coding”. E, surpreendentemente, elas têm uma taxa de sucesso surpreendentemente alta. E isso significa que, sabe, nós, programadores com alguma experiência, sabemos como conduzir a criação de software. Ou sabemos como definir a meta para os agentes. Esse tipo de coisa pode ser— É. Sabe, precisamos formalizá-las e ensiná-las às próximas gerações de desenvolvedores de software.

E então, por exemplo, sou o líder do “vibe coding” porque, nos últimos 15 anos, venho praticando o “vibe coding”. Tenho praticado o “vibe coding” porque, sabe, sou o líder da comunidade do núcleo do Ruby, e pergunto aos committers: “Ok, que tal implementarmos esse recurso?” E então a inteligência orgânica… a inteligência criou o software. E eu testei, analisei e, tudo bem, vamos integrá-lo. E que tal melhorar o coletor de lixo assim? E os colaboradores apresentam o código: melhoramos tanto assim. Ótimo. É assim que trabalhamos atualmente. Todo mundo tem colaboradores principais ao seu redor. É assim que trabalhamos. É assim que vamos trabalhar daqui em diante.

Não se engane. É uma promoção. Ora, às vezes você é promovido para um cargo que não quer, mas acho que essa promoção, se você der cinco minutos a ela, vai ser imensamente gratificante, porque tive exatamente a mesma experiência que o Matz teve com o Rails por muitos anos, talvez décadas. Na primeira versão do Rails, escrevi tudo sozinho. Na segunda versão, talvez metade. E quando chegamos à 6ª e à 7ª, quase nada. Apenas orientação. Para onde queremos ir? O que é bom? O que está na moda, o que está fora de moda. É a isso que agora todos temos acesso.

O que também é verdade é que o dilema do inovador geralmente descreve o que acontece com as empresas estabelecidas quando surge uma nova tecnologia. Primeiro, a nova tecnologia parece um brinquedo. Não é uma ameaça. Ela só dá conta das coisas mais simples. Por que nos importaríamos? Temos a maior fatia do mercado e os grandes clientes, e eles não se importam com brinquedos. Qualquer um que estivesse por perto quando o Ruby ganhou destaque pela primeira vez vai se lembrar dessa história. “Não é escalável.” Lembra disso? É o que as pessoas estão dizendo agora sobre a IA. E estão erradas exatamente da mesma forma que estavam erradas sobre o Ruby e o Rails lá no começo.

Porque o vibe coding não só funciona e produz ótimos resultados, como também está evoluindo a um ritmo absolutamente astronômico. Portanto, tudo o que hoje ainda não é escalável vai se tornar escalável daqui a 5 minutos. Isso está claro. Por isso, precisamos tomar cuidado para não ficarmos estagnados como os gigantes do setor. Para não menosprezarmos essas novidades porque, por um breve momento, elas não fazem o que a gente quer. Mas vão fazer.

Por falar em zombar. Percebo ecos disso no desprezo pela IA, no fato de chamarem as coisas de “slop” e se referirem a elas como “meat proxies”. E até que ponto essas expressões — que são sugestivas e, em certo sentido, muitas vezes verdadeiras — são, na sua opinião, diagnósticos reais, e até que ponto são apenas uma forma de lidar com a situação?

90% é uma forma de lidar com a situação.

Uau.

Não sei. Simplesmente não sei. Detesto fazer previsões. Não sou bom em prever o futuro.

É por isso que temos que lidar com probabilidades. Não com previsões, nem com certezas, mas com probabilidades. Probabilidade. E é provável que isso seja apenas uma forma de lidar com a situação. E quanto mais cedo você se livrar dessas muletas, mais cedo poderá correr. E é verdade que, à medida que descobrimos como usar esses sistemas da melhor maneira possível, tanto para nós quanto para eles, vamos acabar adotando algumas formas subótimas de fazê-lo. E o “meat proxy” é uma delas. Se você está gastando tempo copiando e colando entre agentes e mensagens de erro, deveria considerar simplesmente deixar o agente ler as mensagens de erro diretamente. Por que você está nesse ciclo? Por que está aí atuando como um “proxy humano”? Saia desse papel. É insatisfatório e ineficaz.

Muitas coisas são assim quando você começa a colocá-las em prática. Elas são um pouco precárias. Ainda não estão totalmente aperfeiçoadas. Não temos um processo perfeito. Não temos ferramentas perfeitas. E nos viramos por um tempo, mas devemos ter a ambição de almejar algo mais elevado. Portanto, o rótulo de “meat proxy” é apenas uma tábua temporária para ir de A a B.

A questão do “slop”, porém, é uma desculpa da pior espécie. A ideia de que os agentes não conseguem escrever código original, de alta qualidade e livre de bugs é, neste momento, simplesmente ilusória. É muito mais delirante, muito mais uma psicose em torno da IA do que o otimismo sobre o que ela pode fazer, porque é como enfiar a cabeça na areia. Então, essa história do “slop”, acho que está na hora de aposentar. Até mesmo a “granada de slop” não vai durar muito mais por aí.

Acho que “granada de slop” capta algo que “slop” não consegue, porque é o slop mais a forma como é apresentado. E é aí que as pessoas sentem que é slop, quando isso é jogado na cara delas. E é como se não fosse levado até o fim. Se você tem uma ideia, bem, quer dizer, é como receber um comunicado de imprensa que não foi bem pensado, e agora cabe a você dedicar sua atenção para analisá-lo e entendê-lo. E a “granada de slop” é que você precisa descobrir se vale a pena lançar isso. Então há… o que está faltando aí? Há mais do que apenas escrever o código.

Não me importo nem um pouco com “granadas de slop”. Eu simplesmente as vejo como sugestões e não preciso me preocupar em aceitá-las. E se eu gostar da sugestão, meu agente vai analisar o código e voltar com uma implementação impecável. Prefiro, de longe, pull requests e issues abertos pelos agentes. Eles são de qualidade superior à de qualquer pull request ou issue produzido por um ser humano comum em qualquer repositório que já tive o privilégio de gerenciar. Isso não significa que eu tenha que aceitar a implementação. Na verdade, é ainda melhor, porque, se você não escreveu o código, não sentirá nenhum sentimento de perda quando eu descartar tudo e reescrever. Bem, não serei eu quem reescreverá, e sim meu agente, mas você não estará mais apegado às linhas de código. Isso é uma bênção.

Grande parte do atrito nas comunidades de código aberto do passado vinha do fato de as pessoas se apegarem às linhas de código porque, por acaso, haviam dedicado muita energia a escrevê-las, e era difícil abrir mão delas quando surgiam linhas de código melhores. Nunca tive esse problema. Acho que não restam muitas linhas de código na base de código do Rails que eu tenha escrito pessoalmente. Maravilhoso! Melhoria, progresso, algo melhor. Acho que essa ideia de que não estamos mais escrevendo o código manualmente permite que mais pessoas vivenciem isso: uma produção de linhas de código sem ego e, portanto, um apego apenas às ideias, às ideias melhores e à melhoria.

É. Acho que conseguimos lidar com a enorme quantidade de, você sabe, PRs e issues com a ajuda da IA. Por exemplo, ontem, acordei, tomei banho e verifiquei meu GitHub, e não tínhamos nenhum issue nem pull request para o Spinel. Isso é ótimo. E eu… então acordei, vim a pé até aqui no local do evento e participei de uma discussão. E, logo antes da palestra dele, recebi 20 issues e 1 pull request em apenas 1 hora.

E então peguei meu celular e abri o aplicativo do Claude. Pedi ao Claude para, bom, resolver esses problemas no pull request. E, no final da palestra, quando terminei, o Claude já tinha resolvido automaticamente aqueles 12 problemas. É assim que fazemos — é assim que criamos o software. Tudo mudou. E podemos aproveitar o valor da IA usando a própria IA.

Isso me leva a outra coisa que eu ia perguntar. Ao longo desses últimos nove meses, na verdade, à medida que as pessoas foram aceitando, de modo geral, que, bem, esses modelos podem produzir um código excelente, elas continuam procurando aquilo que eles não conseguem fazer. E qual é essa pequena lacuna que não para de diminuir, representando o domínio humano, onde sempre teremos algum tipo de superioridade? E por que, afinal, insistir nisso? Mas um deles é a sensação de ter bom senso. Agora, quando vejo o Claude lidar com todas essas questões, analisar cada uma delas e tomar as decisões certas, será que isso ainda é um fator limitante? São os humanos que estão exercendo seu bom senso, ou até que ponto cedemos a decisão aos agentes?

Na medida em que sua competência o justifique. E a competência deles é medida pela sua confiança de que o último pull request foi tratado corretamente, exatamente como você faria com qualquer pessoa. Eu observo os agentes e procuro os mesmos sinais que procuraria se fosse um programador trabalhando na 37signals. Essa pessoa está pronta para assumir mais responsabilidades? Com que frequência preciso verificar o trabalho? E quanto mais sênior o agente ou o funcionário se torna, menos eu verifico, mais confio, mais presumo que ele tenha feito tudo certo e mais também aceito que há o risco de que ele não tenha feito.

Se eu ler cada linha de código, saberei o que cada uma delas faz. Se eu parar de ler as linhas de código, terei que confiar nos resultados e na confiança. E, ocasionalmente, o agente cometerá um erro. Quem entre nós nunca cometeu um? Quem entre nós nunca escreveu um código ruim, com bugs, que poderia ser mais rápido? Todos nós, o tempo todo. Por que vocês têm essa exigência de que a nova inteligência deve ser perfeita e isenta de falhas desde o primeiro dia? Isso é a psicose da IA. Isso é a ilusão da IA. Essa inteligência está melhorando rapidamente, mas ainda não é perfeita — e nós também não somos. Então, qual é o problema?

Existe uma assimetria na norma. Quero dizer, é semelhante ao que ocorre com os veículos autônomos, em que qualquer colisão já é demais, e, no entanto, ocorrem dezenas de milhares de colisões por ano, mas o ser humano está no controle. Então, será que o fato de o ser humano estar no controle, ao volante, torna isso mais justificável? O fato de gerar falhas, erros e bugs e representar um risco?

Em uma sociedade dominada por processos judiciais, sim. Em uma sociedade sensata, orientada por resultados, não. Existem diferentes sociedades ao redor do mundo que lidam com esse problema de maneiras muito distintas. Na Dinamarca, não há processos por danos pessoais. Simplesmente não existe essa categoria de ação. Não é uma área do direito que tenha qualquer impacto sobre a forma como as decisões são tomadas. Essas sociedades se sairão melhor. Porque, neste momento, infelizmente nos deparamos com o problema de ter uma tecnologia de direção superior que, segundo os indicadores que vi, tem cerca de 8 vezes menos probabilidade de se envolver em uma colisão do que o ser humano médio; e, ainda assim, dizemos: ah, não sei, uma colisão já é demais. Entre 40.000 e 45.000 pessoas morrem todos os anos nos Estados Unidos em acidentes de trânsito. Se pudéssemos melhorar isso agora mesmo e reduzir esse número para um oitavo, 30 mil pessoas estariam vivas no final do ano que, de outra forma, não estariam. Não é uma sociedade sensata aquela que opta por ignorar isso.

Então, sim, isso me faz pensar em outras aplicações dessas mesmas tecnologias, porque não se trata de um fenômeno exclusivamente da programação. As pessoas estão buscando aplicar essas mesmas tecnologias na área da saúde e na engenharia como um todo. Você gostaria que uma equipe de IA projetasse uma nova ponte? Quero dizer, engenharia de verdade.

É. Mas tenho uma preocupação. Mesmo que criemos o software usando agentes sem conhecer os detalhes, a solução ainda depende de componentes de software existentes, como o compilador Rust, o Ruby on Rails ou o interpretador de Ruby, seja lá o que for, o Linux ou o PostgreSQL. E então, como dependemos cada vez mais dos agentes, os outros componentes se tornariam cada vez mais transparentes. E, embora esses componentes — em sua maioria, software de código aberto — sejam muito importantes e viáveis para a sociedade, as pessoas não os veriam e não se importariam com eles. Essa é a minha maior preocupação. Quanto mais os componentes se tornam transparentes, menos a sociedade se importa com eles, com a manutenção e com a sustentabilidade. Essa é a minha preocupação, e eu acho que nós temos que trabalhar para manter esses componentes, incluindo o Ruby on Rails, o Linux e os bancos de dados.

Isso me faz pensar, David, no que você disse sobre as desvantagens da abstração. Em que momento a gente acaba ignorando esses componentes e cada um acaba inventando o seu próprio? E penso em coisas como, por exemplo, quando falamos de bibliotecas específicas: por que não, sei lá, ignorar uma biblioteca de WebSockets e simplesmente implementar o protocolo WebSockets diretamente? E todo mundo, quer dizer, é um ecossistema amplo com várias implementações diferentes evoluindo de forma independente e com suas próprias funções de aptidão, que precisam ser capazes de interoperar. E minha mente de engenheiro imediatamente pensa: bem, existem essas desvantagens claras, como ineficiências de escala; se houver um bug, você precisa corrigi-lo em um único lugar, em vez de em 100 mil lugares. Mas o que você acha?

Essa é a próxima fronteira. Perceber que as abstrações em nossas próprias bases de código são obstáculos à concorrência e ao paralelismo. E o mesmo vale, até certo ponto, para nossos frameworks e nossas linguagens de programação. E, eventualmente, chegaremos ao nível do fóton, diretamente à física. E que todos os nossos esforços nos últimos 60 anos de desenvolvimento de software tiveram como objetivo lidar com os limites da cognição humana. E se esses limites não se aplicam mais, as soluções também não.

Portanto, consigo imaginar perfeitamente que o futuro do software se pareça mais com a vanguarda da jogabilidade generativa que temos hoje. Já existem modelos capazes de gerar mundos de jogo em tempo real. A ideia de que poderíamos acabar em um mundo onde sistemas operacionais, drivers de dispositivos, frameworks e linguagens sejam gerados em

tempo real parece ficção científica neste momento, mas o mesmo acontecia com a ideia de que esses agentes poderiam escrever todos os nossos aplicativos web para nós e nos livrar do lápis há muito pouco tempo.

Então, acho que, na verdade, precisamos de mais ficção científica, de brincadeiras mais criativas, porque é isso que vai guiar nossa imaginação daqui para frente.

Grande parte da nossa imaginação hoje está ancorada em obras como “2001: Uma Odisseia no Espaço”. Grande parte da nossa percepção sobre os perigos da IA vem do HAL 9000, do Exterminador do Futuro e de obras de ficção científica escritas há 40 a 100 anos. Precisamos de uma ficção científica melhor neste momento, porque todas essas histórias já se tornaram realidade, em certa medida; e, portanto, precisamos de novos horizontes que nos tragam nova inspiração sobre como pode ser uma nova era da computação.

Você acha que existem limites de velocidade que estamos enfrentando imediatamente aqui quando se fala, quer dizer, digamos que eu queira contornar a libc e simplesmente me comunicar, sabe, por meio de microcódigo com uma CPU? É como se isso fosse exigir muito mais tokens. Tipo, o que isso aciona dentro de um modelo? Existem outros tipos de barreiras à eficiência além da eficiência em tempo de execução e da eficiência no tempo de desenvolvimento. Já reduzimos bastante o tempo de desenvolvimento. Ou, no ciclo de retroalimentação, o custo é quase zero. Então dizemos: “Bem, não preciso arcar com o custo de nenhuma outra linguagem — qualquer que seja a que me ofereça alta expressividade. Portanto, vamos escolher o Rust, pois ele vai reduzir drasticamente o custo de execução”. Mas e quanto ao custo do ciclo, os tokens que são gastos para representar a realidade e operar dentro dela?

Acho que estamos lidando com o Commodore 64 neste momento. Temos um agente de 1 MHz. E no ano que vem teremos um que rodará 10 vezes mais rápido, e no ano seguinte, 100 vezes mais rápido, e os seres humanos são simplesmente incapazes de compreender coletivamente o crescimento exponencial. Portanto, todas as nossas preocupações atuais sobre a eficiência e o custo dos tokens são relevantes neste momento, e você deve prestar atenção ou sua conta de tokens vai explodir. Mas essa atenção é uma consideração de curto prazo. É claro que isso vai ficar mais barato.

Mais uma vez, esse absurdo apocalíptico do “decrescimento” — de que estamos prestes a ser enganados pela Anthropic e pela OpenAI — é simplesmente ignorância econômica. Os modelos de peso aberto já são fenomenalmente bons. Existe concorrência. Nunca houve tanta concorrência em um novo campo da computação quanto temos agora com a IA. Nenhuma das mudanças de paradigma anteriores teve algo parecido com isso em termos de concorrência. Quando os dispositivos móveis surgiram, tínhamos dois players: o Google e a Apple. Quando o mercado de computadores de mesa se dividiu, tínhamos o Windows e a Apple. Agora, temos um milhão de provedores de tokens. Talvez a Anthropic e a OpenAI estejam na liderança, mas essa vantagem é medida em meses, se não em semanas. Não há nada com que se preocupar, pessoal. As coisas vão melhorar. Vão ficar mais baratas. Vão ficar ainda melhores.

Há alguns meses, Matz Endo-san fez essa observação de que Ruby é a linguagem mais eficiente em termos de tokens.

Sim. Há alguns meses, nós — a equipe da Kaleido — analisamos várias linguagens, incluindo Ruby, Python, JavaScript e TypeScript, além de Rust, Kotlin, Go e Haskell. E, curiosamente, há três linguagens entre — não me lembro bem, provavelmente 13 linguagens — que apresentam bastante eficiência em termos de tokens e de tempo. E essas linguagens são Ruby, Python e JavaScript — JavaScript puro. E, curiosamente, a tipagem estática não contribui nem para a eficiência de tokenização nem para a eficiência de tempo.

Eu te disse!

Para complementar isso, considerando que os agentes têm o mais próximo que consigo dizer é que eles se divertem com essas linguagens eficientes em termos de tokens. Eles conseguem chegar rapidamente ao resultado que buscam. E se eu tivesse alguma medida mais precisa da satisfação dos agentes, seria o fato de eles terem seguido o método de escalada de montanha.

É uma suposição um pouco ousada, mas acredito que, sabe, uma linguagem de programação que seja agradável para os humanos, projetada para proporcionar o prazer de programar, provavelmente essa linguagem também seja agradável para as IAs.

Stream do Android em Ruby.

Então, o interessante aqui foi que Chad Fowler fez um teste de desempenho com várias tarefas representativas, e o Ruby não foi escolhido em nenhuma delas. E as linguagens mais comumente utilizadas foram Python, JavaScript etc., dependendo do tipo de problema. E isso talvez reflita o pré-treinamento com base no que eles viram. Portanto, o que eles conhecem é o que eles usam. Como você orienta um modelo? Bem, no sentido de que estamos meio que nos desviando do assunto aqui. Estamos dizendo que vamos permitir que os modelos façam tudo, mas os modelos já têm seu próprio senso de “Rails” interno. É nisso que eles foram treinados. Então, como fazemos para que os modelos façam o que queremos? E, quer dizer, talvez isso esteja distorcendo um pouco o contexto, porque não é necessariamente fazer o que queremos, mas recebemos o resultado daquilo em que eles foram treinados. Será que é isso que queremos?

Não acho que os agentes se importem. Se você quiser que eles se comuniquem com você em Ruby, eles falarão em Ruby, e são muito bons nisso. As avaliações dos agentes que temos realizado mostram exatamente isso. Eles são eficientes em termos de tokens. Ficam perfeitamente à vontade para se comunicar com você em Ruby. Eles falam Python por padrão porque foi com essa linguagem que os pesquisadores de aprendizado de máquina que vêm trabalhando nesses sistemas foram treinados. Mas isso não tem influência sobre qual linguagem eles dominam melhor. Eles poderiam muito bem falar Ruby com você. Eles não se importam. Eles falam todas as linguagens fluentemente.

Além disso, o foco no pré-treinamento se torna muito míope muito rapidamente, e acho que ficamos presos nessa visão logo no início, quando estávamos pensando em como poderíamos ajudar os laboratórios a ensinar melhor Ruby aos modelos, porque tínhamos essa ideia de que eles precisavam ver muito Ruby para escrever bem em Ruby. Não, eles não precisam. Os princípios do excelente desenvolvimento de software são universais, e não importa se eles aprendem essas regras em JavaScript, Python ou Smalltalk. Eles vão traduzir para a forma final com a mesma eficiência. Esse é o segundo equívoco da era passada: achar que eles são papagaios. Eles estão apenas repetindo o que lhes dissemos. Não, não estão. São pensadores incrivelmente criativos.

Na verdade, é por isso que representam um desafio tão grande. Na área de segurança, eles são incrivelmente criativos ao encadear vários ataques combinados. E é por isso que estamos tendo dificuldade em lidar com isso e precisamos de nossos próprios agentes para nos defendermos contra eles. A criatividade existe. Na verdade, se há alguma diferença, eles são mais criativos do que os humanos que os comandam.

Então, aproveite isso. Peça que eles falem Ruby com você quando for isso que você preferir. Quando você quiser examinar o código, é claro que eles devem falar Ruby, porque Ruby é a melhor linguagem de programação para humanos. Portanto, peça que eles traduzam para você, e depois eles podem voltar a falar código de máquina em assembly diretamente com a CPU.

É isso que o Spinel faz.

Então, eu gostaria de falar um pouco sobre o que vem depois do Rails. Temos o Rails para desenvolvimento web. É uma espécie de concretização específica do que nós, como programadores, trazemos para o mundo da tecnologia. Quero dizer, nos últimos 20 anos. E isso está mudando. Nosso domínio está mais sólido, mais abrangente. Podemos fazer mais. E, ainda assim, há uma sensação de: “Quero manter o Rails”. E não precisa necessariamente ser a estrutura, mas e os valores do Rails?

E você, David, com o Omarchy, está começando algo novo. E os valores dele são atraentes. E o Matz, com o MINASWAN: o Matz é legal, então a gente também é legal. Isso nunca me pareceu muito certo, porque é como se a gente não fizesse algo só porque outra pessoa é de um jeito determinado. Mas é quase como dar permissão para uma forma de interagir com uma linguagem. Que é normal valorizar as coisas que o Ruby valoriza. E, com essa permissão, há um ótimo filtro para identificar quem se sente atraído por essa linguagem. Então, vocês dois, como fundadores, o que vem por aí para vocês?

Não sei, mas respeito muito o Linus Torvalds porque ele criou o Linux. Essa é uma grande conquista. Mas, além disso, ele criou o Git. Uma coisa já é uma história, mas criar duas grandes obras é uma espécie de lenda. E é por isso que respeito muito o DHH. Porque, sabe, ele criou o Ruby on Rails e o Omarchy, certo? Ele está escrevendo uma lenda. Estou criando o Ruby. E quanto a outra coisa? Deixa eu pensar nisso.

Bem, acho que é muito importante que as pessoas encontrem seu grupo, encontrem outras pessoas que gostem das mesmas coisas que elas, que tenham a mesma visão de mundo — não exatamente igual, mas compartilhada —, porque precisamos de um pouco de atrito. Precisamos de um pouco de discordância para podermos aprender uns com os outros. E eu realmente acho que a razão pela qual todos levantaram a mão quando perguntaram “você se considera um Rubyista?” é que temos uma visão comum sobre a importância do Ruby como forma de expressão ao programar máquinas. Isso é realmente importante.

Nem todo mundo compartilha dessa visão. Há muitas pessoas que detestam profundamente o Ruby. Há muitas pessoas que não gostam do Omarchy, do Rails ou de qualquer outra coisa com a qual eu tenha me envolvido. Isso é bom. Seria tão chato se todos nós gostássemos das mesmas coisas exatamente da mesma maneira e houvesse apenas uma linguagem de programação, um framework, um sistema operacional neste mundo. Talvez fosse eficiente, mas com certeza não seria divertido.

Porque os seres humanos são tremendamente diversos em suas formas de pensar. E respondem de maneira diferente a diferentes tecnologias, a diferentes paradigmas, a diferentes metodologias. O debate de longa data na comunidade de programação sobre tipagem estática versus tipagem dinâmica é uma ilustração perfeita disso. Você pode apresentar quantos argumentos quiser às pessoas de um lado ou de outro, elas não mudarão de ideia porque não chegaram a essas posições por meio do raciocínio; portanto, não é possível convencê-las a abandoná-las com argumentos. Algumas dessas posições são simplesmente fundamentais, quase que predefinições em seus cérebros.

Emacs.

Exatamente! Tabulações x espaços, Emacs x Vim. Essas são exatamente essas linhas divisórias, e devemos mantê-las, e devemos celebrá-las. Precisamos celebrá-las e precisamos encontrar novas. Então, quando avançarmos para o futuro e os agentes estiverem escrevendo cada vez mais do nosso código, precisaremos de novas maneiras de nos conectar com os outros, criar camaradagem e encontrar um grupo. Acho que essa comunidade aqui tem uma oportunidade única de fazer isso juntos. Vocês já sabem que enxergam grande parte do mundo da mesma maneira. Então, à medida que avançarmos para o que vier a seguir, fiquem por aqui. Vai ser muito legal.

Então, se não podemos prever o futuro, quer dizer, talvez possamos nos preparar para ele e celebrar o presente. Na sua opinião, o que o Ruby on Rails realmente acertou nessas últimas décadas?

Para mim, o foco está na autonomia. Programadores individuais capazes de ir muito mais longe do que iriam com ferramentas menos eficientes, menos prazerosas e menos bonitas. O Ruby, para mim, foi essa chave mágica, pois não só me proporcionou uma ferramenta prática para criar aplicativos web, mas também foi uma fonte inesgotável de alegria e motivação para me dedicar a esse trabalho. Acho que nós, nas comunidades do Ruby on Rails, compreendemos isso melhor do que qualquer outra pessoa. Uma compreensão da psicologia humana, do que impulsiona a produtividade. Um componente enorme disso é exatamente o que você disse. É a motivação. É trabalhar com ferramentas belas e ergonômicas que criam algo que, à primeira vista, pode parecer frívolo. Código que parece poesia. Além da questão de ele rodar rápido.

Agora, essa é a outra questão sobre o momento atual. Acho importante entender que existem aplicativos em que o desempenho é fundamental e que podem ser aprimorados reescrevendo-os em algo como Rust. E, por outro lado, há muitos, muitos, muitos, muitos outros em que essa eficiência não importa. A grande maioria dos aplicativos Rails já roda em um único Raspberry Pi. Não precisa de mais velocidade do que isso. E, quando for necessário mais hardware, você pode trocá-lo.

Então, vou continuar a iniciar todas as novas aplicações web que escrever em Ruby on Rails. É uma maneira maravilhosa de começar. E terei grande satisfação em dar uma espiada nos bastidores e ver esse belo código sendo gerado pelos agentes. E então, se chegar o momento em que algo se torne tão popular que seja economicamente vantajoso reescrevê-lo em Rust ou em código de máquina, simplesmente faremos isso. E então poderemos transformá-lo de volta em Ruby, se assim quisermos, por um momento de pura alegria e apreciação da bela poesia do código. Tudo isso é flexível. Podemos seguir em uma direção ou na outra. Você não precisa se prender a nada e pensar: “Meu Deus, agora tenho que ser um programador de Rust”. Eu não te condenaria a esse destino. Confie em mim.

Graças a Deus.

Pelo que acredito, a maior contribuição da comunidade Ruby para o mundo é mostrar a importância da alegria e da motivação em uma comunidade — no cenário da programação. Nós, seres humanos, precisamos de motivação para fazer qualquer coisa. Portanto, precisamos estar motivados para criar software ou, sabe, para criar qualquer coisa — e também para melhorar a sociedade. E, quando sentimos alegria, podemos ser muito mais produtivos no produto — em desenvolvimento. Esse tipo de coisa não fazia parte do senso comum há 30 anos. Portanto, essa é a maior contribuição da linguagem Ruby.

E o princípio básico, acredito, é que, enquanto as preocupações humanas continuarem as mesmas no futuro, isso permanecerá. Portanto, a motivação é importante. A alegria importa e a liberdade importa. Esse tipo de coisa vai permanecer igual. Mas, sabe, a tecnologia vem e vai, e talvez no futuro o Ruby seja menos importante, venha a se tornar menos importante, mas, de qualquer forma, a alegria, a motivação e a liberdade ainda serão muito importantes. Obrigado. Continuará sendo importante para todos nós, desenvolvedores ou criadores.

Claro que sim. Sim, quando penso na felicidade do programador, é uma combinação de autonomia e alegria. E há algo sobre a felicidade do programador profissional, talvez: também é receber pelo trabalho. É o reconhecimento do que você está criando e da relevância dentro do âmbito profissional — saber que você tem um futuro fazendo esse tipo de trabalho. Então, para finalizar, olhando para trás — e isso é realmente como uma parceria de 20 anos entre o Ruby on Rails, a autonomia e a alegria —, pelo que você é mais grato?

Tenho muita gratidão ao Matz por ter permitido que eu e outros membros da comunidade Rails concluíssemos o livro que ele começou. Colocar o programador de aplicativos no mesmo nível que o criador da linguagem e fazer com que não fosse possível distinguir a diferença entre os dois.

Agradeço ao DHH e à comunidade do Rails por terem divulgado o Ruby para o mundo. Antes do Rails, o Ruby já existia, mas praticamente ninguém o conhecia. E então, graças ao Rails, todo mundo começou a usá-lo, e muitos aplicativos — incluindo o Shopify, o GitHub e as primeiras versões do Twitter — foram desenvolvidos com Ruby on Rails, e todo mundo passou a usá-lo. E, no passado, muitas, muitas, muitas startups usavam o Ruby on Rails, e elas tiveram, você sabe, lucros e mudaram o mundo. Isso é uma grande alegria para mim. E me deu uma espécie de autoestima. E, depois do Rails, pude trabalhar com Ruby em tempo integral.

Então, sim, eu estou mais do que, você sabe, eu agradeço muito, muito, muito mesmo pela existência do DHH e do Rails.

Bem, Matz, David, obrigado a vocês dois por tudo. Obrigado.