Ruby, Rails, and the future of programming - Matz, DHH & Jeremy Daer

Ruby on Rails

AI-assisted summary of Ruby, Rails, and the future of programming - Matz, DHH & Jeremy Daer — original source. Check the original for full context.

Source published: 2026-09-27

Key ideas

Yukihiro Matsumoto (Matz) anunciou o Spinel, um novo compilador alternativo que gera binários nativos de Ruby de alta performance, reduzindo a pegada de memória de aplicações Rails típicas de 100 MB para cerca de 5,5 MB. (13:01)
Pesquisas comparativas com 13 linguagens conduzidas por Yusuke Endoh revelaram que Ruby, Python e JavaScript vanilla são as mais eficientes em termos de tokens e tempo de inferência para agentes de IA, refutando a ideia de que tipagem estática traria vantagens. (46:59)
DHH e Matz defendem a transição da identidade do programador de redator de código para criador de software (software maker), argumentando que o valor profissional migra da digitação manual para o bom gosto estético, direção de produto e visão arquitetural. (6:51)
Matz alertou para o perigo da invisibilidade da infraestrutura de código aberto: à medida que agentes assumem o desenvolvimento de alto nível, fundações vitais como Linux, PostgreSQL e compiladores correm o risco de perder financiamento e governança. (39:48)

Detailed notes

## Background Publicado pelo canal oficial do Ruby on Rails no YouTube em 27 de setembro de 2026, o vídeo registra uma conversa informal no Rails World 2026 entre Yukihiro "Matz" Matsumoto, David Heinemeier Hansson (DHH) e o mediador Jeremy Daer (37signals). Segundo a descrição oficial, o painel aborda o impacto do desenvolvimento guiado por agentes autônomos na identidade dos programadores, apresenta o novo compilador Spinel criado por Matz e discute a relevância duradoura do bom gosto, da eficiência de tokens do Ruby e das lições acumuladas em mais de duas décadas de ecossistema.

## TL;DR Jeremy Daer, DHH e Matz debatem a transformação do programador tradicional de mero digitador de código em um diretor de sistemas ou criador de software, incentivando a superação rápida do luto tecnológico diante do avanço da inteligência artificial. Matz revela seu projeto Spinel, um compilador para binários nativos que reduz o consumo de memória do Ruby para cerca de um vigésimo do padrão habitual, enquanto DHH desconstrói o pânico em torno de códigos gerados por IA e defende a eliminação do ego no desenvolvimento de software. A conversa também analisa estudos sobre a alta eficiência de tokens de linguagens expressivas como o Ruby e conclui reafirmando que o verdadeiro diferencial competitivo e humano reside no bom gosto, na motivação criativa e na autonomia do desenvolvedor.

## Atmosphere & style A conversa transcorre em um clima de camaradagem calorosa e reflexão filosófica entre pioneiros da tecnologia que acompanham as transformações do setor há décadas. Enquanto Jeremy Daer conduz o diálogo com empatia e indagações existenciais francas sobre o ofício da programação, DHH injeta sua conhecida energia confiante e provocadora contra o ceticismo do mercado, e Matz equilibra a dinâmica com modéstia zen, sabedoria prática e tiradas bem-humoradas autodepreciativas. O arco emocional transita do desabafo sincero sobre as incertezas e a perda de hábitos históricos de desenvolvimento para uma empolgação contagiante com novas ferramentas, culminando em uma comovente celebração de gratidão mútua pela parceria histórica entre Ruby e Rails.

## Bulletin - [13:01](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=781s) Yukihiro Matsumoto (Matz) anunciou o Spinel, um novo compilador alternativo que gera binários nativos de Ruby de alta performance, reduzindo a pegada de memória de aplicações Rails típicas de 100 MB para cerca de 5,5 MB. - [46:59](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=2819s) Pesquisas comparativas com 13 linguagens conduzidas por Yusuke Endoh revelaram que Ruby, Python e JavaScript vanilla são as mais eficientes em termos de tokens e tempo de inferência para agentes de IA, refutando a ideia de que tipagem estática traria vantagens. - [06:51](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=411s) DHH e Matz defendem a transição da identidade do programador de redator de código para criador de software (software maker), argumentando que o valor profissional migra da digitação manual para o bom gosto estético, direção de produto e visão arquitetural. - [39:48](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=2388s) Matz alertou para o perigo da invisibilidade da infraestrutura de código aberto: à medida que agentes assumem o desenvolvimento de alto nível, fundações vitais como Linux, PostgreSQL e compiladores correm o risco de perder financiamento e governança.

## Key takeaways - [02:11](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=131s) A revolução da inteligência artificial exige acelerar os estágios do luto rumo à aceitação prática, permitindo aos desenvolvedores redescobrir a criatividade e a diversão na concepção de software. - [06:51](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=411s) A identidade do desenvolvedor ganha novo significado no papel de criador de software, onde a comoditização da escrita mecânica valoriza a sensibilidade estética, proporção e elegância conceitual. - [13:01](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=781s) O compilador Spinel surge como uma resposta de alta eficiência do Ruby para o ecossistema moderno, compilando binários nativos ultrarrápidos com uma fração do consumo tradicional de memória. - [19:57](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=1197s) A ansiedade quanto ao fim dos empregos fundamenta-se na falácia do bolo fixo: embora sistemas individuais exijam menos esforço de manutenção, o volume global de novas aplicações criadas se expandirá exponencialmente. - [22:34](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=1354s) O fenômeno do vibe coding democratiza a postura executiva de arquitetura que Matz já exercia há mais de uma década ao direcionar committers para implementar visões de alto nível. - [27:09](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=1629s) O ceticismo corporativo que rotula a programação assistida por IA como brinquedo ou slop repete os mesmos erros históricos do Dilema do Inovador enfrentados pelo Rails no início dos anos 2000. - [31:45](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=1905s) Pull requests e sugestões gerados por agentes eliminam o apego emocional ao código, retirando o atrito do ego nas revisões e permitindo foco exclusivo na relevância das ideias. - [36:25](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=2185s) A exigência de perfeição absoluta para agentes revela uma assimetria moral irracional similar ao debate sobre carros autônomos, que tolera amplas falhas humanas mas hipervigila o erro da máquina. - [39:48](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=2388s) A sustentabilidade a longo prazo do open source exige atenção ativa para evitar que componentes estruturais vitais deixem de ser mantidos quando a camada de agentes torná-los invisíveis. - [44:27](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=2667s) O estágio atual da IA corresponde à era Commodore 64, sugerindo que restrições imediatas de latência e custo de tokens serão rapidamente superadas pela evolução exponencial do hardware e dos modelos. - [46:59](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=2819s) Linguagens concebidas historicamente para maximizar o prazer cognitivo humano, como Ruby, mostram-se organicamente as mais compactas e eficientes para o raciocínio de grandes modelos de linguagem. - [56:57](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=3417s) A filosofia central do ecossistema Ruby on Rails consolidou-se ao provar que empoderar a autonomia do desenvolvedor e priorizar a ergonomia estética são os motores definitivos de produtividade e motivação. - [01:01:45](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=3705s) A simbiose de mais de duas décadas entre a linguagem expressiva criada por Matz e o framework de aplicação moldado por DHH viabilizou empresas globais sem abrir mão do humanismo na tecnologia.

## Detailed walkthrough ### [00:10](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=10s) Bem-vindos ao "AI World" e as previsões incertas

Jeremy Daer abre a conversa destacando a atmosfera singular do Rails World daquele ano. Ele brinca que, se alguém removesse as letras R, L e S da palavra "Rails" no letreiro do evento, restaria apenas "AI", refletindo como a inteligência artificial tomou conta de todas as discussões. A palestra de abertura feita por David Heinemeier Hansson (DHH) no dia anterior havia lançado questionamentos profundos sobre o rumo do desenvolvimento: como estamos moldando o Ruby, como estamos moldando o Rails e o que toda a comunidade de programação está enfrentando diante dessa revolução. Jeremy observa um paradoxo clássico: justamente quando o futuro se torna mais nebuloso e imprevisível, é quando as pessoas mais anseiam por certezas, previsões sólidas e respostas claras sobre o que acontecerá até o final do ano vigente ou no ano seguinte.

Ao passar a palavra para Yukihiro "Matz" Matsumoto, o criador do Ruby reflete sobre a velocidade estonteante das transformações recentes, confessando a dificuldade de prever qualquer rumo a médio prazo. Para ilustrar o choque cultural, Matz relata sua própria rotina de trabalho: há apenas dois anos, ele jamais imaginaria a possibilidade de abandonar o Emacs como seu editor de cabeceira. Embora ainda mantenha o Emacs aberto por hábito e apego, ele admite que, desde novembro do ano anterior, praticamente todo o código que desenvolve é escrito diretamente em ambientes de desenvolvimento na nuvem por meio de ferramentas modernas, o que representa um desafio mental e uma ruptura dramática com décadas de prática diária.

```mermaid flowchart LR accTitle: Ciclo de Incerteza e Busca por Previsões accDescr: Diagrama ilustrando como a incerteza tecnológica impulsiona o anseio por previsões. subgraph Contexto["Cenário Tecnológico"] A["Mudança Acelerada por IA"] --> B["Futuro Imprevisível"] end subgraph Reacao["Comportamento da Comunidade"] B --> C["Ansiedade por Previsões"] C --> D["Busca de Certeza e Estabilidade"] end ```

[02:11](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=131s) Acelerando os estágios do luto rumo à aceitação

David Heinemeier Hansson entra no debate concordando com a premissa de Jeremy e Matz, mas pontuando que o momento atual não deve ser encarado sob a ótica de certezas absolutas, e sim de probabilidades estatísticas. Para David, a probabilidade esmagadora é de que, até o encerramento daquele ano, a quase totalidade dos desenvolvedores estará programando exatamente como Matz: guiando e interagindo diretamente por meio de agentes inteligentes. Ele compara o impacto dessa mudança a uma onda gigantesca, na qual é natural perder o equilíbrio e ficar desorientado sobre onde se posicionar na prancha para conseguir surfar sem ser engolido pela força da maré.

DHH argumenta que a comunidade tem o dever moral e coletivo de apoiar uns aos outros nessa travessia, cujo primeiro passo incontornável é a aceitação fática da realidade: "Isso está acontecendo. Nenhum de nós tem o poder, mesmo que quiséssemos, de impedir isso". Ele traça um paralelo bem-humorado, porém firme, com os estágios clássicos do luto (negação, raiva, barganha, depressão e aceitação). Segundo David, muitas pessoas superaram a raiva inicial e estão presas na fase de barganha — tentando negociar mentalmente concessões com a tecnologia —, o que considera um esforço inútil: "A IA vai te ouvir e te dar atenção, mas não vai mudar sua trajetória". A recomendação é acelerar ao máximo a passagem pela barganha e pela depressão para atingir a aceitação plena. Uma vez superado o choque, David garante que o "outro lado é incrível": programar volta a ser mágico, libertador e divertido, permitindo conceber ideias de software e vê-las concretizadas em instantes diante dos próprios olhos.

[04:24](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=264s) Quem ainda se sente um programador Ruby?

Jeremy Daer aprofunda o dilema psicológico da categoria: é perfeitamente possível desfrutar da velocidade produtiva dos agentes e, ao mesmo tempo, sentir um vazio ou uma crise existencial profunda. Jeremy confessa sua própria angústia: ele ainda se define internamente como um programador Ruby e um desenvolvedor Rails experiente, mas percebe que já faz meses que não abre o terminal no Vim para digitar uma linha sequer de código à mão. Diante disso, ele pergunta à plateia onde fica a identidade do profissional quando a prática manual deixa de existir. Ele convida o auditório a levantar a mão para ver quem ainda se sente essencialmente um "Rubyista", provocando uma manifestação calorosa do público presente. A questão central paira no ar: quando a identidade sobrevive à própria prática técnica, qual é o resíduo que realmente fica para trás?

Matz responde trazendo uma perspectiva histórica de longo alcance, comparando o momento à consolidação da era industrial no século XX. Ele lembra que, há cerca de 80 ou 100 anos, havia um pânico generalizado de que as máquinas roubariam todos os postos de trabalho dos operários humanos, imaginário retratado com maestria no clássico cinematográfico *Tempos Modernos*, de Charlie Chaplin. No entanto, o desenrolar real dos fatos mostrou que a tecnologia serviu para reduzir a sobrecarga braçal extenuante e remodelar as dinâmicas de trabalho, permitindo que as pessoas atuassem de maneira diferente e menos massacrante. Matz acredita que o mesmo ocorrerá com os desenvolvedores na próxima década: a rotina prática mudará de forma irreconhecível, mas os profissionais ainda poderão preservar a essência criativa e pacífica do desenvolvimento em si, recusando-se a encarar a IA como um algoz que os expulsará do ofício.

[06:51](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=411s) De redator de código a criador de software e a ilusão do Rust

David Heinemeier Hansson retoma a palavra para traçar uma distinção conceitual crucial sobre rótulos profissionais. Ele relembra uma palestra antiga na qual declarou categoricamente nunca ter se enxergado como um "engenheiro de software" — título que sempre considerou excessivamente austero, mecânico e rigoroso. David sempre preferiu se definir como um "redator de software" (um *software writer*), tratando o ato de programar como uma forma de escrita e expressão criativa. Para quem já encarava a programação com essa sensibilidade artística, David avalia que o salto em direção ao papel de "criador de software" (*software maker*) é natural e infinitamente mais gratificante:

> "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."

Na visão de DHH, a comunidade Ruby possui uma vantagem competitiva única para a era dos agentes autônomos. Quando a digitação manual de código se torna comoditizada, os verdadeiros diferenciais humanos passam a ser o bom gosto estético, a sensibilidade de design, a noção de proporção e a elegância conceitual — virtudes que a cultura do Ruby sempre cultivou desde a sua origem. Por isso, ele critica duramente a fixação de parte do setor com migrações de linguagens, rotulando a ansiedade em torno de tecnologias como Rust como uma miopia tática:

- **Universalidade do impacto**: A transformação causada pela IA não é restrita ao ecossistema Ruby ou Rails; ela atingirá todas as linguagens, frameworks e bibliotecas sem distinção. - **Desapego ao Rust**: DHH afirma categoricamente: "Não dou a mínima para o Rust". O Rust é apenas uma ferramenta circunstancial e temporária de alta eficiência, sem qualquer investimento emocional ou apego de ego por parte dele. - **Salto direto para o Assembly**: David especula que logo os agentes poderão ignorar linguagens intermediárias como Rust e gerar diretamente código de máquina ou assembly hiperotimizado para cada arquitetura e plataforma específica, tornando irrelevante qualquer discussão sobre portabilidade tradicional.

[09:50](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=590s) A dor da transição, o ego e o retorno à essência do Ruby

Jeremy Daer pontua a disparidade emocional sentida por quem está na linha de frente: há uma energia palpável de inovação no ar, mas quando um indivíduo não consegue senti-la internamente, abre-se um abismo repleto de ansiedade e receio perante o futuro. Não se trata simplesmente de uma requalificação corporativa trivial, como ouvir de uma empresa após uma demissão em massa que basta fazer um curso rápido de "aprenda a programar". Para quem sempre se dedicou exclusivamente à minúcia do código artesanal, ser empurrado da noite para o dia para a posição de criador ou diretor de sistemas representa uma disciplina inédita e desconfortável.

DHH concorda e enfatiza que domar o ego diante dessas mudanças requer tempo. É indispensável respeitar o luto e permitir-se sentir nostalgia por ferramentas e práticas antigas antes de abraçar o novo paradigma. Ele traça paralelos diretos com a chegada da web comercial nos anos 1990 e a revolução dos smartphones: em todas essas transições históricas, houve desenvolvedores que se recusaram a embarcar no trem e optaram por ficar esperando na estação, o que também é uma escolha legítima.

Jeremy então destaca uma ironia histórica: a maioria dos pioneiros começou a escrever Ruby puramente por diversão, deleite estético e amor à linguagem, sem visar ganhos econômicos imediatos. Com a desvalorização puramente mercantil da codificação manual, Ruby poderia, paradoxalmente, estar retornando ao seu estado original e mais puro de expressão lúdica. Matz reage com humor autodepreciativo, contrapondo-se ao pragmatismo desapegado de DHH:

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

A piada arranca risos da plateia, mas Matz reconhece a dura realidade prática: sob uma perspectiva financeira e de eficiência estrita de máquina na era dos grandes modelos de IA, o Ruby tradicional nem sempre é a opção mais econômica, embora conte com uma base instalada colossal, uma inércia madura e um momento histórico vigoroso sustentando seu ecossistema.

[13:01](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=781s) Spinel: Compilando Ruby para binários nativos

Yukihiro Matsumoto (Matz) revela um novo projeto que iniciou em março do mesmo ano: o **Spinel**, um compilador alternativo para a linguagem Ruby focado em gerar binários nativos de alta performance. Matz explica que o Spinel faz os programas rodarem com extrema rapidez e com uma pegada de memória dramaticamente reduzida. Ele compartilha métricas práticas de testes em condições reais: o compilador foi capaz de rodar aplicações utilizando apenas um vigésimo da memória habitual. Em uma aplicação típica de Ruby on Rails que normalmente consome 100 megabytes, a versão compilada nativamente pelo Spinel ocupa cerca de 5 a 5,5 megabytes (embora Matz inicialmente mencione 20 MB, ele logo se corrige para ressaltar a marca de 5,5 MB). Ele admite com bom humor que, por ter começado o projeto recentemente, a tecnologia ainda é apenas "um bebê", mas possui um potencial imenso para redefinir a criação de backends em binário nativo.

```mermaid flowchart LR accTitle: Fluxo de compilação do Spinel accDescr: Diagrama ilustrando a compilação de código Ruby para binário nativo via Spinel, destacando a redução de memória. subgraph Entrada["Código-Fonte"] A["Aplicação Ruby / Rails"] end subgraph Compilador["Spinel (Matz)"] B["Compilador Nativo Ruby"] end subgraph Saida["Executável Final"] C["Binário Nativo<"] D["Consumo: ~1/20 da memória<br/>(Ex: 100 MB -> ~5,5 MB)"] end A --> B B --> C C --> D ```

Jeremy Daer aprofunda o assunto, lembrando que Matz passou décadas refletindo sobre o ecossistema do Ruby e suas variantes especializadas. Ele cita o **mruby**, concebido para hardware embarcado com recursos limitados, e questiona qual fronteira o Spinel vem traçar: se o CRuby atende à maioria dos humanos e o JRuby atende ambientes corporativos, seria o Spinel a resposta do Ruby para o mundo dominado por agentes autônomos de IA? Jeremy indaga o que fundamentalmente define a essência da linguagem ("o que faz do Ruby o Ruby?") caso certas funcionalidades dinâmicas sejam removidas para viabilizar a compilação nativa.

Matz reflete que a linha demarcatória nunca foi perfeitamente nítida, tendo sido construída ao longo dos anos por tentativa e erro até formar o CRuby que conhecemos. No entanto, uma única solução não atende a todos os cenários: o CRuby é pesado demais para dispositivos de Internet das Coisas (IoT), e o Ruby tradicional pode se mostrar lento em certas tarefas computacionais extremas, mesmo com a recente introdução de compiladores JIT (Just-In-Time). Para Matz, compilar um subconjunto de alto desempenho do Ruby em binários ultrarrápidos é o caminho pragmático, e ele brinca que, "pelo menos por enquanto, só eu posso traçar a linha entre o que é Ruby e o que não é".

---

[16:28](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=988s) Scaffolding de agentes, o projeto Roundhouse e a motivação humana

A conversa aborda experimentos recentes de arquitetura como o **Roundhouse**, uma abordagem conceitual em que aplicações Ruby on Rails operam como um "oráculo de conformidade" ou especificação executável: agentes de IA consultam as regras de negócio modeladas em Rails e então geram código-fonte em outras linguagens de baixo nível ou Ruby puro sem frameworks. Jeremy pergunta a Matz se o scaffolding em Ruby é apenas um passo temporário a ser descartado ou uma forma duradoura de preservação do ecossistema.

Matz pondera que a relação com a criação de software está mudando rapidamente. Grande parte dos profissionais precisará migrar seu foco para gestão e direção de produto. Embora muitos desenvolvedores encontrem grande prazer e motivação no ato mecânico de programar linhas de código, Matz alerta com sinceridade que a codificação enquanto ofício de carreira tradicional provavelmente nos será tirada em um futuro muito próximo. No entanto, o contraponto positivo é que os agentes agora democratizam a resolução de problemas: engenheiros sem amplo conhecimento ou bagagem técnica profunda conseguem entregar soluções completas com o auxílio das ferramentas de IA.

Ainda assim, Matz salienta que a maioria da humanidade apenas consome soluções passivamente; os criadores e provedores de soluções continuam sendo uma minoria, "uma espécie de 'escolhidos'". O foco não deve se prender cegamente a ferramentas específicas — ecoando argumentos de David Heinemeier Hansson (DHH) —, mas sim no ato de gerar soluções para as pessoas. Acima de tudo, Matz defende o Ruby como um motor de satisfação: - "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." - Ruby permanece como uma das ferramentas mais prazerosas do planeta para despertar essa centelha inventiva no desenvolvedor.

---

[19:57](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=1197s) Ruby como pseudocódigo executável e a falácia do "bolo fixo"

Jeremy Daer relembra sua própria trajetória de descoberta da linguagem através dos célebres artigos de Dave Thomas publicados na *IEEE Software*: ao ler os códigos de exemplo na revista, Jeremy pensava tratar-se de puro pseudocódigo conceitual, até perceber pasmo que aquele código expressivo e conciso rodava de verdade. Jeremy argumenta que, em um mundo onde agentes escreverão imensas bases de código em linguagens como Rust, o Ruby pode viver um "retorno à sua melhor forma" como uma linguagem de explicação algorítmica: uma forma lúcida de um agente traduzir e demonstrar conceitos complexos para nós com extrema clareza.

DHH intervém enfaticamente para desconstruir o pessimismo do mercado, diagnosticando a ansiedade dos desenvolvedores como uma incapacidade de enxergar além do dogma econômico do "bolo fixo" (*fixed pie*):

- **A ilusão do bolo fixo:** Profissionais temem o desemprego porque assumem erroneamente que o número de softwares no mundo permanecerá estático, deduzindo que precisaremos de uma fração mínima de programadores para manter esse volume fixo de sistemas. - **A explosão na demanda:** Embora sistemas existentes exijam menos mãos para manutenção, o volume total de aplicações criadas vai explodir exponencialmente. - DHH aponta o cenário diário do GitHub — brincando que "é o motivo de o site ficar fora do ar a cada 5 minutos" — como reflexo da enxurrada de novos projetos sendo concebidos graças à facilidade de geração de software. - Para DHH, agarrar-se obsessivamente à digitação de código é o equivalente a "se agarrar tanto ao lápis a ponto de não conseguir imaginar que a calculadora possa te ajudar". Quem abraçar o papel de criador (*maker*) desfrutará de imensa estabilidade e volume de trabalho.

---

[22:34](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=1354s) Metodologias do passado e Matz como o "vibe coder" original

Jeremy reflete sobre a ironia histórica do momento atual: no início dos anos 2000, o movimento da Programação Extrema (XP), a agilidade e o TDD (Test-Driven Development) nasceram para combater o peso e os ciclos lentos de documentação formal, compensando ciclos rápidos com o custo de execução da linguagem. Agora que o custo de gerar e alterar código caiu para zero, Jeremy pergunta em tom de debate se a indústria estaria voltando involuntariamente ao modelo em cascata (*Waterfall*) e ao "Big Design Up Front" com especificações e Markdown.

Matz responde que o formato específico da metodologia importa cada vez menos, pois a estrutura microscópica do código perde relevância à medida que humanos deixam de manipular sintaxe linha por linha. A habilidade fundamental a ser ensinada para as próximas gerações é a capacidade de vislumbrar a essência do problema e formular uma visão clara de solução para os agentes guiarem a execução.

Abordando o fenômeno contemporâneo do *vibe coding* — frequentemente criticado por conseguir gerar apenas jogos simples como Tetris e fracassar feio em aplicações reais de negócios —, Matz salienta que colaboradores sêniores do Ruby vêm obtendo taxas impressionantes de sucesso em sessões de codificação orientada a IA. A razão é simples: veteranos sabem exatamente como direcionar a máquina e estabelecer objetivos realizáveis. Matz brinca com a plateia ao se autoproclamar pioneiro do movimento: - "Nos últimos 15 anos, venho praticando o *vibe coding*." - Como líder do núcleo da linguagem, sua rotina há mais de uma década tem sido propor visões de arquitetura aos committers ("E se implementássemos esse recurso?"), ao que a inteligência orgânica dos programadores desenvolve o código, e Matz apenas analisa, aprova ou pede refinamentos. - Ele pontua que, na era da IA, essa dinâmica executiva se democratizou: agora, qualquer programador comum tem à sua disposição uma equipe de colaboradores principais dedicados.

---

[27:09](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=1629s) A promoção do programador e o dilema do inovador

DHH encerra o bloco reforçando a visão de Matz sobre a nova postura do desenvolvedor frente à inteligência artificial: trabalhar com agentes não é uma ameaça, mas sim "uma promoção". Ele traça um paralelo direto com sua própria evolução liderando o desenvolvimento do Rails:

DHH destaca que qualquer transição de cargo pode assustar de início, mas que atuar como diretor e curador do produto é infinitamente mais gratificante. Ele recorre ao clássico conceito do **Dilema do Inovador** para alertar sobre o ceticismo míope das empresas estabelecidas. Quando uma disrupção surge, os incumbentes costumam descartá-la como um mero "brinquedo" que só resolve problemas bobos e não ameaça as grandes corporações.

DHH recorda que os detratores usavam exatamente o mesmo argumento arrogante contra o ecossistema de Ruby e Rails nos anos 2000 — bradando insistentemente que o framework "não era escalável" —, e que essas pessoas quebraram a cara. Ele conclui que os críticos atuais que descartam o *vibe coding* estão cometendo o exato mesmo erro histórico, ignorando que as ferramentas generativas não apenas funcionam para o mundo real, mas evoluem a um ritmo exponencial e sem precedentes.

[28:55](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=1735s) "Meat proxy", "slop" e a negação diante da evolução da IA

A conversa parte da premissa de que qualquer limitação técnica atual de escalabilidade deixará de existir "daqui a 5 minutos". Para David Heinemeier Hansson (DHH), os desenvolvedores precisam tomar cuidado para não repetirem a arrogância e a estagnação dos antigos gigantes da tecnologia, que costumavam zombar das inovações emergentes só porque, por um breve instante, elas ainda não atendiam perfeitamente às expectativas. Quando questionado sobre rótulos pejorativos como *"slop"* (código desleixado ou "porcaria") e *"meat proxy"* (o humano atuando como mero intermediário biológico entre ferramentas), DHH é categórico: cerca de 90% dessa reação não passa de puro mecanismo de enfrentamento (*cope*) e negação da realidade.

Ele argumenta que quem ainda atua como um *meat proxy* — copiando manualmente mensagens de erro do terminal e colando nos agentes — está apenas utilizando muletas temporárias e ineficientes. A solução óbvia é dar acesso direto aos agentes para que eles leiam os erros e executem os comandos sozinhos. Quanto ao rótulo de *slop*, DHH considera que insistir na ideia de que modelos de linguagem não conseguem gerar código original, sofisticado e livre de bugs tornou-se uma ilusão muito mais psicótica do que qualquer otimismo exagerado sobre a IA. Trata-se de "enfiar a cabeça na areia" para evitar aceitar o ritmo do progresso.

- O termo *meat proxy* representa apenas uma ponte precária e temporária entre ferramentas imperfeitas e a automação completa do ciclo de desenvolvimento. - Desqualificar o código gerado por IA como necessariamente descartável ou defeituoso é, na visão de DHH, uma desculpa ultrapassada que os desenvolvedores precisam abandonar imediatamente.

---

[31:45](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=1905s) "Granadas de slop", PRs de agentes e o código sem ego

O debate se aprofunda no conceito de "granada de slop" (*slop grenade*): a prática de despejar sobre os mantenedores de projetos uma ideia ou pull request cru, gerado por IA sem acabamento, transferindo a terceiros o fardo de analisar se aquilo tem valor. Enquanto muitos encaram isso com revolta, DHH afirma não se incomodar nem um pouco. Ele encara essas contribuições apenas como sugestões que não tem obrigação nenhuma de aceitar. Caso a proposta seja boa, ele simplesmente aciona seu próprio agente para reescrever e implementar a solução de forma impecável. DHH chega a afirmar que prefere pull requests e *issues* gerados por agentes, pois a qualidade média deles já supera a das contribuições humanas típicas que recebeu ao longo da carreira gerenciando repositórios.

Essa dinâmica traz uma consequência transformadora para o código aberto: a eliminação do ego. Historicamente, grande parte do atrito e da toxicidade nas comunidades vinha do apego emocional às linhas de código que os desenvolvedores haviam sofrido para redigir manualmente, gerando resistência quando alguém propunha uma refatoração superior. Quando o código é escrito por um modelo, esse sentimento de posse desaparece. DHH exemplifica com o próprio Rails, observando com orgulho que quase não restam linhas da base de código original escritas por ele mesmo — um sinal de evolução contínua guiada apenas pelas melhores ideias, e não pela vaidade pessoal.

```mermaid flowchart TD accTitle: Fluxo de Contribuição com Agentes sem Ego accDescr: Diagrama comparando o atrito do código tradicional com o ciclo ágil e desapegado de PRs intermediados por agentes.

subgraph Legado["Modelo Tradicional (Humano)"] A["Esforço manual intenso"] --> B["Apego emocional às linhas"] B --> C["Atrito na revisão e resistência a refatorações"] end

subgraph Agentes["Modelo com Agentes (Sem Ego)"] D["Sugestão externa / Granada de slop"] --> E["Filtragem da ideia pelo mantenedor"] E --> F["Agente local reescreve com excelência"] F --> G["Código descartável focado apenas no resultado"] end ```

---

[34:06](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=2046s) O caso Spinel: Claude resolvendo issues no celular de Matz

Yukihiro Matsumoto (Matz) ilustra esse novo paradigma compartilhando uma experiência que viveu na manhã daquele mesmo evento. Ao acordar e conferir o GitHub, o repositório do seu novo compilador Spinel não tinha nenhuma pendência aberta. Matz caminhou até o local do evento e participou de discussões, mas, logo antes da palestra de DHH, viu chegarem 20 *issues* e 1 pull request em um intervalo de apenas uma hora.

Em vez de se desesperar com a sobrecarga ou abrir o computador para programar manualmente, Matz simplesmente pegou o smartphone, abriu o aplicativo do Claude e instruiu o agente a resolver os problemas reportados na solicitação de pull. Ao término da apresentação, o Claude já havia resolvido automaticamente 12 daqueles problemas. Para Matz, essa cena sintetiza uma quebra definitiva: "É assim que criamos o software. Tudo mudou." Ele destaca que a melhor forma de absorver o impacto da avalanche de demandas geradas por IA é usando a própria IA como escudo e ferramenta de execução.

- O fluxo de trabalho de Matz com o Spinel exemplifica a transição de programador de terminal para gestor de modelos operando diretamente do celular. - A velocidade com que 12 problemas foram solucionados demonstra que os gargalos de triagem e manutenção de projetos foram drasticamente reduzidos.

---

[36:25](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=2185s) Delegação de julgamento, tolerância ao erro e a analogia dos carros autônomos

Jeremy Daer questiona se o julgamento crítico e o bom senso (*judgment*) ainda representam o último reduto inabalável da exclusividade humana. DHH responde que a decisão deve ser cedida aos agentes na exata medida em que a competência demonstrada justifique essa transferência de poder. Ele traça um paralelo direto com a avaliação de programadores na 37signals: com profissionais juniores ou agentes recém-adotados, cada linha é inspecionada; conforme a confiança cresce, as verificações diminuem e assume-se o risco inerente de erros ocasionais. DHH rebate os críticos lembrando que seres humanos cometem gafes, escrevem código lento e introduzem falhas o tempo todo, sendo incoerente exigir perfeição absoluta de uma tecnologia em rápida evolução.

Para expor essa hipocrisia, DHH compara as críticas à IA ao debate sobre veículos autônomos. Nos Estados Unidos, morrem entre 40.000 e 45.000 pessoas por ano em acidentes de trânsito, e a sociedade tolera essas perdas simplesmente porque humanos estão no controle do volante. Mesmo com dados indicando que a direção autônoma é cerca de oito vezes menos propensa a acidentes — o que salvaria mais de 30 mil vidas por ano —, qualquer incidente pontual de um carro autônomo vira manchete e motivo de pânico regulatório. Ele contrapõe essa cultura hiperlitigiosa à realidade da Dinamarca, onde a inexistência de processos por danos pessoais permite tomadas de decisão pragmáticas e focadas em métricas reais de bem-estar social.

- O nível de supervisão dispensado a um agente deve ser idêntico ao de um funcionário: quanto maior a senioridade demonstrada nos resultados anteriores, menor a necessidade de inspecionar linha por linha. - A aversão ao erro da máquina reflete uma assimetria moral irracional, que prefere desastres causados por incompetência humana a melhorias estatísticas trazidas pela tecnologia.

---

[39:48](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=2388s) A invisibilidade da infraestrutura: o alerta de Matz sobre o open source

Apesar do entusiasmo com a produtividade dos agentes, Matz traz uma preocupação profunda quanto à sustentabilidade do ecossistema de software a longo prazo. Ele adverte que toda a mágica dos agentes depende de uma pilha gigantesca de ferramentas fundamentais construídas ao longo de décadas: linguagens, o compilador Rust, interpretadores Ruby, frameworks como Ruby on Rails, bancos de dados como PostgreSQL e sistemas operacionais como o Linux.

Na medida em que os desenvolvedores passam a interagir apenas com camadas de alto nível geradas por agentes, toda essa infraestrutura essencial se torna "transparente" e invisível. O grande perigo, segundo Matz, é que a sociedade e a comunidade técnica deixem de se importar com a manutenção, a governança e o financiamento dessas fundações de código aberto. Jeremy complementa levantando o dilema sobre os limites da abstração: até que ponto a facilidade de gerar soluções ad-hoc não levará as pessoas a abandonarem bibliotecas consolidadas para, por exemplo, mandar a IA reimplementar protocolos inteiros do zero, como o protocolo de WebSockets.

- Componentes estruturais vitais correm o risco de sucateamento financeiro e comunitário caso o uso de agentes oculte sua existência da nova geração de programadores. - Matz reforça que a sustentabilidade de ferramentas como Linux, PostgreSQL e Ruby on Rails exige esforço consciente contínuo, impedindo que sejam tratadas como recursos naturais infinitos e gratuitos.

[41:49](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=2509s) Abstrações, física e a ficção científica da computação

A conversa avança para a arquitetura de sistemas quando Jeremy Daer levanta uma dúvida prática de engenharia: em um ecossistema amplo, repleto de implementações autônomas com suas próprias funções de aptidão (*fitness functions*) precisando interoperar, surgem ineficiências de escala evidentes. Se um bug aparece, a lógica convencional dita que é muito melhor consertá-lo em um único lugar centralizado do que em cem mil instâncias distribuídas. David Heinemeier Hansson (DHH) rebate apontando que essa mentalidade reflete a barreira anterior: as abstrações nas bases de código, frameworks e linguagens foram inventadas unicamente para contornar os limites finitos da cognição humana, mas frequentemente se tornam gargalos para paralelismo e concorrência. Se agentes eliminam essa restrição cognitiva, a necessidade dessas camadas intermediárias também desaparece, abrindo caminho para que a computação desça diretamente ao nível do fóton e da física fundamental.

DHH traça um paralelo com a vanguarda dos jogos generativos, que já conseguem renderizar e construir mundos inteiros em tempo real. Da mesma forma, sistemas operacionais, drivers de hardware, bibliotecas e linguagens inteiras poderão ser sintetizados em tempo real conforme a demanda. Embora isso soe como delírio futurista, ele lembra que a própria ideia de agentes construindo aplicações web completas parecia impossível há pouco tempo. Para expandir esse horizonte, a indústria precisa de uma ficção científica renovada:

> "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."

[44:27](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=2667s) A era Commodore 64 da IA e o mito dos custos de tokens

Jeremy indaga se contornar bibliotecas padrão como a `libc` para falar direto com o microcódigo da CPU não esbarraria em uma barreira severa de consumo de tokens dentro dos modelos. DHH descarta a preocupação de longo prazo, afirmando categoricamente que a tecnologia atual está no estágio equivalente ao "Commodore 64", operando com agentes de 1 MHz. A velocidade crescerá dez vezes no próximo ano e cem vezes no seguinte, uma escala exponencial que a mente humana tem enorme dificuldade de assimilar. Os custos astronômicos de tokens atuais são apenas um problema transitório de curto prazo que se dissipará com o barateamento e a proliferação da infraestrutura.

Para DHH, o discurso pessimista de "decrescimento" (*degrowth*) ou a crença de que desenvolvedores ficarão permanentemente reféns de monopólios da OpenAI ou Anthropic representa pura ignorância econômica. Pela primeira vez na história da tecnologia, uma grande virada de paradigma não está restrita a um duopólio fechado — ao contrário da computação pessoal (Windows vs. Apple) ou dos smartphones (iOS vs. Android), o ecossistema de inteligência artificial conta com modelos abertos fenomenais e uma miríade de provedores competindo ferozmente por frações de centavos, onde a liderança dos pioneiros é medida em questão de semanas ou meses.

```mermaid flowchart TD accTitle: Transição de paradigmas de computação e abstração accDescr: Gráfico mostrando como a evolução da computação reduz camadas intermediárias para chegar direto ao hardware sob demanda.

subgraph ParadigmaHumano["Era Cognitiva Humana (Últimos 60 Anos)"] A["Linguagens e Frameworks de Alto Nível"] --> B["Bibliotecas de Sistema (libc, Drivers)"] B --> C["Sistema Operacional e Kernel"] C --> D["Hardware / CPU"] end

subgraph ParadigmaAgente["Era dos Agentes Generativos"] E["Intenção do Desenvolvedor / Prompt"] --> F["Agente Generativo em Tempo Real"] F --> G["Microcódigo / Assembly Otimizado"] G --> D end ```

[46:59](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=2819s) A eficiência de tokens do Ruby e a pesquisa de Yusuke Endoh

Matz retoma a discussão trazendo à tona uma descoberta recente feita por Yusuke Endoh (Endo-san) e sua equipe: Ruby despontou como uma das linguagens mais eficientes em termos de tokens. Ao analisarem cerca de treze linguagens distintas — incluindo pesos-pesados como Python, JavaScript, TypeScript, Rust, Kotlin, Go e Haskell —, os pesquisadores notaram um padrão claro. Apenas três linguagens se destacaram em termos de economia de tokens e eficiência temporal: Ruby, Python e JavaScript puro. Crucialmente, o estudo revelou que a tipagem estática não acrescenta nenhuma vantagem à eficiência de tokenização nem economiza tempo de processamento dos modelos, arrancando um satisfeito "Eu te disse!" de DHH.

Matz reflete que os agentes parecem quase "se divertir" operando nessas linguagens enxutas, alcançando seus objetivos rapidamente por um caminho similar a uma otimização por escalada (*hill climbing*). Ele formula a hipótese de que linguagens projetadas para maximizar a felicidade e a ergonomia do programador humano acabam sendo, naturalmente, as mais palatáveis e eficazes também para as inteligências artificiais.

- **Linguagens mais eficientes em tokens e tempo:** Ruby, Python e JavaScript (Vanilla). - **Linguagens analisadas no benchmark comparativo:** Ruby, Python, JavaScript, TypeScript, Rust, Kotlin, Go, Haskell, entre outras (totalizando cerca de 13 linguagens). - **Impacto da tipagem estática:** Nenhum ganho observado em tempo de inferência ou compactação de tokens.

[48:47](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=2927s) Universalidade do código: por que os agentes não são papagaios

Jeremy cita testes conduzidos por Chad Fowler nos quais agentes raramente escolhiam Ruby por padrão ao resolver problemas autônomos, preferindo Python ou JavaScript. Ele questiona se os modelos estariam apenas refletindo o viés de seu pré-treinamento e como desenvolvedores deveriam guiá-los para manter os padrões do ecossistema Rails. DHH responde que a preferência padrão por Python se deve meramente ao ecossistema dos próprios pesquisadores de aprendizado de máquina, e não a qualquer deficiência inerente dos agentes. Os modelos compreendem Ruby perfeitamente quando solicitados e operam com extrema fluência.

DHH insiste que a ideia de que modelos precisam de um volume colossal de código Ruby no treinamento para escrevê-lo bem é um engano superado. Os princípios de um bom design de software são universais: regras aprendidas em Smalltalk, JavaScript ou Python se traduzem perfeitamente para qualquer outra sintaxe. A crença de que IAs são apenas "papagaios estocásticos" que repetem padrões de forma burra ignora a criatividade analítica que já demonstram na prática — algo evidente na área de segurança ofensiva, onde agentes encadeiam vulnerabilidades complexas de formas surpreendentes. DHH argumenta que o humano deve usar o Ruby como interface de leitura e comunicação primária, deixando a IA livre para traduzir isso para assembly ou código de máquina direto na CPU via Spinel.

[52:03](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=3123s) Valores duradouros, MINASWAN e o status de lenda

Ao refletirem sobre o futuro além das fronteiras estritas do Rails, Jeremy ressalta que, embora as ferramentas mudem, a comunidade busca preservar a filosofia do ecossistema. Ele cita o lema MINASWAN (*"Matz is nice and so we are nice"*), notando que o valor da comunidade não está em idolatrar uma figura de forma cega, mas em conceder a si mesmos permissão cultural para priorizar o prazer, a clareza e a humanidade no código — servindo como um poderoso filtro para atrair desenvolvedores com os mesmos valores.

Jeremy pergunta aos dois criadores o que vem a seguir em suas trajetórias. Com humildade e bom humor característicos, Matz compartilha sua admiração por Linus Torvalds, destacando que criar o Linux já era um marco histórico, mas inventar o Git transformou Linus em uma lenda viva da computação por emplacar duas obras-primas seminais. Matz então elogia a trajetória de David:

> "Uma coisa já é uma história, mas criar duas grandes obras é uma espécie de lenda. E é por isso que respeito muito o David. Sabe, ele criou o Ruby on Rails e novos projetos... ele está escrevendo uma lenda. Eu criei o Ruby. E quanto a uma segunda coisa? É, deixa eu pensar nisso."

[54:12](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=3252s) Encontrando a sua tribo e a beleza das divergências fundamentais

David Heinemeier Hansson reflete sobre a necessidade humana de encontrar seu próprio grupo — pessoas que compartilham gostos parecidos e uma visão de mundo em comum, ainda que haja espaço para divergências saudáveis. Na visão de David, um pouco de atrito é indispensável para que possamos aprender uns com os outros. Ele observa que o motivo pelo qual quase todos na plateia levantaram a mão ao serem perguntados se ainda se consideram "Rubyistas" reside nessa sensibilidade compartilhada sobre o papel do Ruby como instrumento primordial de expressão ao programar máquinas. Essa perspectiva está longe de ser universal: há muitas pessoas no ecossistema de tecnologia que detestam profundamente o Ruby, o Rails ou as opiniões de David, e ele encara isso com total naturalidade e entusiasmo.

Para David, um mundo onde todos pensassem de forma idêntica, utilizando a mesma linguagem de programação, o mesmo framework e o mesmo sistema operacional, "talvez fosse eficiente, mas com certeza não seria divertido". Os seres humanos possuem formas de pensar radicalmente diversas e respondem a paradigmas e metodologias distintas. Como exemplo clássico, ele cita o eterno debate entre tipagem estática e dinâmica: tentar convencer alguém com argumentos lógicos raramente funciona, porque as pessoas não chegam a essas convicções por pura dedução racional — trata-se de preferências quase fundamentais, "predefinições em seus cérebros", no mesmo patamar de disputas históricas como Emacs versus Vim ou tabulações versus espaços. David defende que essas linhas divisórias devem ser celebradas e que, à medida que agentes de inteligência artificial passarem a escrever fatias cada vez maiores do código, as comunidades precisarão encontrar novas formas de forjar camaradagem, pertencimento e conexão mútua.

- **Expressão sobre conformidade:** O Ruby une desenvolvedores não por imposição técnica, mas por uma sensibilidade comum em torno da expressividade do código. - **Diversidade contra monotonia:** A fragmentação de ferramentas e crenças não é uma falha de engenharia, mas um reflexo da rica variedade cognitiva humana. - **Trincheiras ideológicas clássicas:** Posições sobre tipagem dinâmica versus estática, Emacs contra Vim e tabs contra spaces funcionam quase como identidades culturais intrínsecas e irredutíveis a simples debates lógicos.

---

[56:57](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=3417s) Autonomia, poesia no código e a flexibilidade entre Rails e Rust

Ao ser questionado por Jeremy Daer sobre o que o Ruby on Rails realmente acertou ao longo das últimas décadas, David aponta diretamente para o conceito de autonomia. A grande conquista do ecossistema foi permitir que desenvolvedores individuais conseguissem ir muito mais longe do que seria viável com ferramentas menos ergonômicas, menos bonitas e menos prazerosas. Para ele, o Ruby funcionou como uma "chave mágica", oferecendo uma fonte inesgotável de motivação ao compreender a psicologia humana por trás da produtividade: trabalhar com ferramentas elegantes que produzem "código que parece poesia", desmistificando a ideia de que o prazer estético seria uma frivolidade secundária à velocidade bruta de execução.

No que tange ao momento atual e à obsessão por desempenho, David pondera que existem nichos de mercado onde a performance máxima é estritamente necessária — cenários em que reescrever partes do sistema em linguagens de baixo nível como Rust faz todo o sentido econômico. No entanto, para a esmagadora maioria dos produtos de software, essa eficiência em nanossegundos é irrelevante, já que boa parte dos aplicativos Rails comuns roda com tranquilidade até mesmo em um único Raspberry Pi. Por isso, David afirma categoricamente que continuará iniciando qualquer nova aplicação web em Ruby on Rails, deliciando-se ao ver agentes gerando código Ruby elegante nos bastidores. Caso um projeto cresça a ponto de justificar financeiramente uma reescrita em Rust ou em código de máquina, isso pode ser feito de forma pragmática — e até revertido para Ruby depois, por pura fruição estética: "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."

```mermaid flowchart TD accTitle: Fluxo de decisão entre produtividade em Rails e reescrita em Rust accDescr: O diagrama ilustra como o Rails serve como ponto de partida focado em autonomia e prazer, com Rust reservado apenas para gargalos econômicos comprovados.

subgraph Inicio["Fase de Criação & Validação"] A["Nova Aplicação Web"] --> B["Desenvolvimento em Ruby on Rails"] B --> C{"Hardware suficiente?<br>(Ex.: Raspberry Pi)"} end

- **A primazia da autonomia:** O foco em empoderar programadores individuais com ferramentas altamente expressivas supera a obsessão abstrata por métricas de máquina. - **Dimensionamento realista:** A maioria esmagadora dos aplicativos web modernos consome recursos modestos e não necessita de otimizações extremas prematuras. - **Flexibilidade pragmática:** Não há obrigação dogmática de migrar permanentemente para linguagens como Rust; partes críticas podem ser otimizadas pontualmente quando os custos de infraestrutura justificarem.

---

[59:28](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=3568s) Alegria, motivação e liberdade: o legado perene do Ruby

Matz intervém para sintetizar o que considera a maior contribuição de sua criação para o mundo: provar que a alegria e a motivação humana devem ocupar o centro da engenharia de software e da formação de comunidades. Ele pontua que nós, como seres humanos, dependemos intrinsecamente de motivação para realizar qualquer empreendimento — seja para construir software, seja para transformar a sociedade. Quando os programadores sentem prazer no ato de criar, a produtividade no desenvolvimento do produto surge como uma consequência natural, uma constatação que estava longe de ser óbvia ou aceita pelo senso comum trinta anos atrás.

Segundo Matz, linguagens e tecnologias inevitavelmente vêm e vão, e é perfeitamente plausível que no futuro a presença do Ruby diminua diante de novos paradigmas técnicos. No entanto, as necessidades e preocupações humanas essenciais permanecerão inalteradas. Princípios como motivação, alegria e liberdade criativa continuarão vitais para quem constrói e desenvolve soluções, independentemente do ferramental adotado. Jeremy Daer complementa a reflexão pontuando que a felicidade do programador profissional nasce da junção entre autonomia e alegria, somadas ao reconhecimento econômico e à segurança de saber que existe uma carreira sólida e com futuro construindo software dessa maneira.

- **O fator motivacional na produtividade:** Sentir prazer durante o processo de escrita do código é o maior catalisador de entrega de software de qualidade. - **Valores humanos imutáveis versus ferramentas temporárias:** Plataformas e linguagens são passageiras, mas a busca humana por alegria, autonomia e liberdade criativa permanece constante. - **O tripé da felicidade profissional:** A plenitude no desenvolvimento de software apoia-se em autonomia criativa, alegria intrínseca na execução e remuneração justa pelo impacto gerado.

---

[01:01:45](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=3705s) Vinte anos de parceria: pelo que Matz e DHH são mais gratos

Encerrando a conversa após mais de duas décadas de história conjunta entre Ruby e Rails, Jeremy pergunta aos dois convidados pelo que eles se sentem mais gratos nessa trajetória. David responde expressando uma profunda gratidão a Matz por ter permitido que ele e a comunidade do Rails "concluíssem o livro que ele começou". David enfatiza a postura generosa de Matz em colocar o programador de aplicações no mesmo patamar de relevância do criador da linguagem, apagando a barreira de prestígio que tradicionalmente separa quem constrói ferramentas de sistema de quem cria aplicativos do dia a dia.

Matz, por sua vez, devolve o agradecimento a David e a toda a comunidade Rails por terem levado o Ruby aos quatro cantos do planeta. Ele recorda que, antes do surgimento do Rails, o Ruby era uma linguagem quase restrita e amplamente desconhecida fora de pequenos círculos no Japão. Foi através do Rails que gigantes como Shopify, GitHub e as fases iniciais do Twitter foram concebidos, abrindo caminho para que incontáveis startups gerassem lucro, inovassem e transformassem o mercado global. Para Matz, essa trajetória não apenas elevou sua autoestima, mas transformou sua própria vida ao permitir que ele trabalhasse com o desenvolvimento do Ruby em tempo integral: "Eu estou mais do que... agradeço muito, muito, muito mesmo pela existência do DHH e do Rails". A sessão é encerrada em clima caloroso com aplausos e agradecimentos mútuos de ambos os pioneiros.

- **Simbiose criativa:** Matz criou a fundação linguística e filosófica, enquanto David e a comunidade Rails estenderam seus conceitos para aplicações práticas de escala global. - **Impacto de mercado real:** O ecossistema impulsionou o nascimento e a infraestrutura de empresas fundamentais da internet, provando a viabilidade econômica do foco na produtividade do desenvolvedor. - **Transformação pessoal:** O sucesso estrondoso do Rails converteu o projeto autoral de Matz em uma carreira profissional de dedicação integral à evolução do Ruby.

## Notable quotes > [06:51](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=411s) 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. — David Heinemeier Hansson

> [06:51](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=411s) Não dou a mínima para o Rust — David Heinemeier Hansson

> [09:50](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=590s) Ao contrário do DHH, tenho um enorme orgulho em relação ao Ruby. E, sabe, toda a minha vida depende disso. E então... mas acho que sou parcialmente responsável, digamos, pelo aquecimento global. Consome muita, muita energia. — Yukihiro Matsumoto

> [13:01](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=781s) pelo menos por enquanto, só eu posso traçar a linha entre o que é Ruby e o que não é — Yukihiro Matsumoto

> [16:28](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=988s) 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. — Yukihiro Matsumoto

> [19:57](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=1197s) se agarrar tanto ao lápis a ponto de não conseguir imaginar que a calculadora possa te ajudar — David Heinemeier Hansson

> [22:34](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=1354s) Nos últimos 15 anos, venho praticando o vibe coding. — Yukihiro Matsumoto

> [34:06](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=2046s) É assim que criamos o software. Tudo mudou. — Yukihiro Matsumoto

> [41:49](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=2509s) 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. — David Heinemeier Hansson

> [52:03](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=3123s) Uma coisa já é uma história, mas criar duas grandes obras é uma espécie de lenda. E é por isso que respeito muito o David. Sabe, ele criou o Ruby on Rails e novos projetos... ele está escrevendo uma lenda. Eu criei o Ruby. E quanto a uma segunda coisa? É, deixa eu pensar nisso. — Yukihiro Matsumoto

> [56:57](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=3417s) 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. — David Heinemeier Hansson

> [01:01:45](https://www.youtube.com/watch?v=IEOqgPfGLQ8&t=3705s) Eu estou mais do que... agradeço muito, muito, muito mesmo pela existência do DHH e do Rails — Yukihiro Matsumoto

## Mentioned 37signals, Anthropic, Apple, Chad Fowler, Charlie Chaplin, Claude, Commodore 64, CRuby, Dave Thomas, David Heinemeier Hansson, Emacs, Exterminador do Futuro, Git, GitHub, Go, HAL 9000, Haskell, IEEE Software, JavaScript, Jeremy Daer, JRuby, Kotlin, Linux, Linus Torvalds, mruby, OpenAI, PostgreSQL, Python, Rails World, Raspberry Pi, Roundhouse, Ruby, Ruby on Rails, Rust, Shopify, Smalltalk, Spinel, Tempos Modernos, Twitter, TypeScript, Vim, Windows, Yukihiro Matsumoto, Yusuke Endoh

## Video description What does it mean to be a Rubyist when agents write the code? In this Rails World 2026 fireside chat, Yukihiro "Matz" Matsumoto and David Heinemeier Hansson sit down with Jeremy Daer (37signals) to talk about shaping the future of Ruby and Rails as AI-assisted development becomes the norm.

They cover the identity shift from software writer to software maker, why taste and joy still matter, and Matz's new Spinel compiler, which turns Ruby into native binaries using a fraction of the memory. They also get into slop, trust, and handing judgment to agents, why Ruby turns out to be one of the most token-efficient languages, and what two decades of Ruby and Rails have gotten right.

CHAPTERS 00:00 Welcome to "AI World" 02:55 Speedrunning the stages of grief 04:24 Who still feels like a Rubyist? 06:51 From software writer to software maker 13:13 Spinel: compiling Ruby to native binaries 21:05 Beyond the fixed pie 25:57 Matz, the original vibe coder 29:46 Slop, slop grenades, and cope 36:02 How much judgment do we cede to agents? 40:30 Keeping open source sustainable 42:36 When abstractions stop being necessary 45:17 The Commodore 64 era of AI 47:56 Ruby's token efficiency 52:41 The values of Rails, and finding your tribe 56:59 What Ruby and Rails got right 1:01:45 What they're most thankful for

#RailsWorld #RubyOnRails #Ruby #Matz #dhh

Thank you @shopify for sponsoring the editing and post-production of these videos. Check out insights from the Engineering team at: https://shopify.engineering/

[Source](https://www.youtube.com/watch?v=IEOqgPfGLQ8)

中文简报

Ruby、Rails与编程的未来：Matz、DHH与Jeremy Daer对谈 Jeremy Daer、DHH和Matz探讨了传统程序员从单纯的代码敲击者向系统架构导演或软件创造者的转变，鼓励大家在人工智能快速发展面前尽快摆脱技术悲观情绪。Matz透露了他的Spinel项目，这是一款能生成原生二进制文件的编译器，可将Ruby的内存消耗缩减至通常标准的约二十分之一；同时DHH驳斥了围绕AI生成代码的恐慌情绪，主张在软件开发中摒弃自我偏见。对话还分析了关于Ruby等富有表达力的语言在Token利用率上极具优势的研究，并总结指出，真正的竞争优势与人类价值在于开发者的良好品味、创作动力与自主性。 Yukihiro Matsumoto（Matz）公布了Spinel，这是一款全新的替代编译器，能够生成高性能的Ruby原生二进制文件，将典型Rails应用的内存占用从100 MB降至约5.5 MB。 (13:01) Yusuke Endoh开展的涉及13种语言的对比研究表明，在面向AI智能体时，Ruby、Python和原生JavaScript在Token消耗和推理时间方面效率最高，反驳了静态类型会带来优势的观点。 (46:59) DHH和Matz主张程序员的身份应从单纯的代码编写者转变为软件创造者（software maker），并认为专业价值正在从人工打字转向审美素养、产品方向把控与架构视野。 (6:51) Matz对开源基础设施被隐形化的风险提出警示：随着AI智能体接管上层开发，Linux、PostgreSQL以及编译器等至关重要的底层基石可能面临失去资金支持和有效治理的风险。 (39:48)

Reading summary

Yukihiro Matsumoto (Matz) e David Heinemeier Hansson (DHH) sustentam que a ascensão dos agentes de inteligência artificial transforma os programadores de redatores manuais de código em diretores de produto, reafirmando que a motivação e a ergonomia humana continuam sendo o verdadeiro diferencial do Ruby. Transição da codificação manual para direção criativa (6:51) Matz e DHH argumentam que a automação da digitação de código exige que a comunidade técnica supere a fase de negação e aceite a nova realidade operacional. DHH descreve esse processo como uma promoção de 'redator de software' para 'criador de software' (software maker), estágio no qual atributos humanos como gosto estético, design e visão de proporção se tornam os principais critérios de valor, superando a mera manipulação sintática. Matz traça um paralelo com a Revolução Industrial retratada em 'Tempos Modernos', prevendo que as tarefas braçais de programação serão eliminadas sem extinguir a essência criativa do desenvolvimento. O próprio criador do Ruby relata gerenciar o desenvolvimento de aplicações diretamente em ambientes na nuvem e via celular por meio de ferramentas como o Claude, caracterizando essa interação como uma extensão democratizada do que ele denominou como seu próprio 'vibe coding' de longo prazo à frente do núcleo da linguagem. Expansão de software e código sem ego (19:57) Ao analisar o receio de retração de postos de trabalho, DHH contesta o dogma econômico do 'bolo fixo' (fixed pie). Para ele, embora sistemas legados precisem de menos intervenção manual, a redução radical nos custos de geração de código causará uma explosão na quantidade de novos sistemas desenvolvidos, sustentando a demanda por profissionais focados em concepção e direcionamento. Essa mudança altera profundamente a convivência no código aberto. DHH aponta que o encaminhamento de códigos crus e pull requests gerados por IA reduz o apego emocional dos desenvolvedores às linhas escritas. Sem a vaidade autoral, mantenedores podem avaliar ou reescrever contribuições de forma pragmática, mitigando históricos atritos de comunidade decorrentes do ego. Compilação nativa, consumo de tokens e Rust (13:01) Para responder a demandas de eficiência de recursos computacionais, Matz detalhou o Spinel, um compilador alternativo para Ruby que gera binários nativos. Em testes práticos preliminares, a tecnologia permitiu que uma aplicação típica em Rails que demandava 100 megabytes de memória rodasse consumindo apenas entre 5 e 5,5 megabytes. No quesito consumo dos modelos de linguagem, Matz citou testes conduzidos por Yusuke Endoh envolvendo treze linguagens: Ruby, Python e JavaScript puro apresentaram a maior economia de tempo e tokens, sem que sistemas de tipagem estática tenham demonstrado ganhos nessa métrica. Diante desses resultados, DHH descarta a urgência de reescrever aplicações Rails em linguagens de baixo nível como Rust, defendendo que o ganho estético e de produtividade no Rails prevalece na maioria dos casos em que gargalos extremos de infraestrutura não existem. Sustentabilidade do código aberto e centralidade humana (39:48) Apesar do otimismo com os agentes, Matz manifestou preocupação com a sobrevivência da infraestrutura fundamental de software. Na avaliação do criador do Ruby, conforme as camadas de desenvolvimento passam a ser geridas automaticamente por agentes, alicerces históricos como Linux, compiladores, interpretadores e bancos de dados tornam-se invisíveis aos olhos dos novos usuários, arriscando perder investimento financeiro, governança e voluntários para manutenção. Ambos concordam que a identidade da comunidade Ruby transcende a linguagem sintática ou ferramentas passageiras. Para Matz e Jeremy Daer, o foco primordial sempre foi o bem-estar psicológico e a autonomia do desenvolvedor, preceito que se mantém relevante mesmo que a rotina prática de programar no terminal continue se transformando. Embora Matz e DHH vislumbrem um ciclo de democratização do software e descarte do trabalho mecânico de código, permanece como questão aberta a forma como o ecossistema manterá o financiamento e a governança da infraestrutura básica de código aberto quando as camadas fundamentais de computação forem completamente ocultadas pela automação dos agentes.

Source quotes

[6:51] David Heinemeier Hansson: 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. [6:51] David Heinemeier Hansson: Não dou a mínima para o Rust [9:50] Yukihiro Matsumoto: Ao contrário do DHH, tenho um enorme orgulho em relação ao Ruby. E, sabe, toda a minha vida depende disso. E então... mas acho que sou parcialmente responsável, digamos, pelo aquecimento global. Consome muita, muita energia. [13:01] Yukihiro Matsumoto: pelo menos por enquanto, só eu posso traçar a linha entre o que é Ruby e o que não é [16:28] Yukihiro Matsumoto: 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. [19:57] David Heinemeier Hansson: se agarrar tanto ao lápis a ponto de não conseguir imaginar que a calculadora possa te ajudar [22:34] Yukihiro Matsumoto: Nos últimos 15 anos, venho praticando o vibe coding. [34:06] Yukihiro Matsumoto: É assim que criamos o software. Tudo mudou. [41:49] David Heinemeier Hansson: 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. [52:03] Yukihiro Matsumoto: Uma coisa já é uma história, mas criar duas grandes obras é uma espécie de lenda. E é por isso que respeito muito o David. Sabe, ele criou o Ruby on Rails e novos projetos... ele está escrevendo uma lenda. Eu criei o Ruby. E quanto a uma segunda coisa? É, deixa eu pensar nisso. [56:57] David Heinemeier Hansson: 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. [61:45] Yukihiro Matsumoto: Eu estou mais do que... agradeço muito, muito, muito mesmo pela existência do DHH e do Rails

Original transcript

[0:10] Bem, sejam todos bem-vindos. [0:12] Sinto que estamos todos participando de uma grande conversa. [0:17] Esta tem sido uma conferência diferente de todas as outras em que já participei. [0:22] E sinto que dá para tirar o R, o L e o S daquela palavra inicial ali. [0:27] Porque tudo gira em torno da IA. [0:30] Agora, estamos aqui para falar sobre como moldar o futuro do Ruby on Rails. [0:35] E a palestra do David ontem deixou muitas questões em aberto. [0:39] Como estamos moldando o Ruby? [0:41] Como estamos moldando o Rails? [0:43] Foi uma visão mais ampla do que o mundo da programação como um todo está enfrentando. [0:49] E, nestes momentos, fico ouvindo as pessoas perguntarem [0:53] sobre o futuro e pedirem previsões. [0:56] E parece que, justamente quando o futuro está mais incerto, [1:00] é quando as pessoas mais querem previsões, segurança e uma noção do que está por vir. [1:06] Então, acho que podemos partir daí. [1:09] Considerando que ainda não sabemos, o que podemos dizer? [1:13] O que vocês prevêem para o final deste ano, para o final do ano que vem? [1:18] Começa com você, Matz. [1:21] Sabe, tudo muda tão rápido nos últimos anos que não dá para saber [1:27] para onde as coisas estão indo. [1:30] Por isso, sabe, há dois anos, eu não conseguia imaginar que deixaria [1:37] de usar o Emacs como editor de código. [1:41] Mas ainda uso o Emacs, aliás. [1:45] É. [1:48] Eu uso todo o meu código está escrito no meu ambiente de código na nuvem desde [1:55] novembro passado, mais ou menos. [1:58] E as coisas eram totalmente diferentes de… [2:03] isso é bem, sabe, desafiador para mim. [2:10] David? [2:11] Acho que você está absolutamente certo. [2:14] O que estamos lidando agora não é com certezas, mas com probabilidades. [2:17] E a probabilidade que vejo é que, até o final do ano, como disse ontem, [2:21] não será a maioria das pessoas, mas praticamente todas as pessoas que [2:25] estarão programando como o Mats por meio de seus agentes. [2:28] Hum-hum. [2:30] Agora também entendo por que isso parece tão incerto. [2:33] Mudar as coisas e misturar tudo dessa forma é como uma grande onda, [2:37] e a gente não sabe como se equilibrar nem onde se posicionar para superar isso. [2:42] Mas acho que é por isso que temos a responsabilidade coletiva de nos [2:46] unirmos e nos ajudarmos mutuamente. [2:48] Primeiro, é preciso aceitar. [2:50] Isso está acontecendo. [2:51] Nenhum de nós tem o poder, mesmo que quiséssemos, de impedir isso. [2:55] É como se estivéssemos passando rapidamente pelas fases do luto aqui. [2:58] É isso que está acontecendo. [3:00] E sei que muitas pessoas já superaram a raiva e estão em algum estágio [3:05] de negociação com o futuro. [3:06] Isso não funciona. [3:08] A IA vai te ouvir e te dar atenção, mas não vai mudar sua trajetória. [3:12] Portanto, quanto mais rápido você passar pelo estágio de negociação — e, com sorte, [3:17] dar uma passada rápida pela depressão — para então chegar à aceitação, esse é, na [3:23] minha opinião, o único caminho a seguir. [3:25] E então, quando você chegar à aceitação, espero que experimente o que eu [3:30] experimentei, o que tantas pessoas já experimentaram: que o [3:34] outro lado é incrível. [3:35] É maravilhoso e divertido de todas as maneiras que a programação é maravilhosa e [3:41] divertida, pois fazemos as máquinas realizarem coisas novas. [3:44] Temos ideias e as vemos ganharem vida, e com a IA isso simplesmente acontece [3:49] muito, muito, muito mais rápido. [3:52] É, acho que algo particularmente intrigante nessa época é que as pessoas [3:56] estão tendo essa experiência, mas também estão tendo a outra simultaneamente. [4:01] Você consegue usar um agente e ver as coisas ganharem vida, [4:04] mas também há Quer dizer, eu me sinto um programador Ruby, [4:08] me sinto um programador Rails, e, no entanto, faz meses que não uso [4:12] o Vim para escrever código Ruby. [4:14] Então, onde, onde está minha identidade? [4:16] E ontem o David pediu que levantassem a mão quem está escrevendo código Ruby, [4:21] mas vou pedir que levantem a mão de novo. [4:23] Quem se sente um programador Ruby? [4:30] É isso aí, pessoal. [4:34] Então, estamos em uma situação diferente — onde nos situamos nesse caminho quando a [4:39] identidade, de certa forma, pode sobreviver à nossa prática? [4:42] Quando nos chamamos de “Rubyistas”, mas não estamos escrevendo em Ruby, [4:46] qual é o resquício que fica para trás? [4:49] Sabe, embora a tecnologia tenha mudado a nossa vida, acho que agora podemos [4:56] escolher como nos sentimos nas nossas atividades e no nosso dia a dia. [5:03] Por exemplo, quando a tecnologia surgiu, digamos, há 80 anos, [5:09] as pessoas se preocupavam com o fato de que os empregos seriam tirados dos seres [5:17] humanos e que toda a produção industrial ou algo do tipo seria feita por máquinas. [5:25] Criaram filmes como “Tempos Modernos”, de Chaplin, e então mas as coisas [5:31] aconteceram de maneira diferente, de modo que reduzimos a carga de trabalho [5:39] na produção industrial ou podemos trabalhar de maneira [5:44] diferente do que há 100 anos. [5:47] Esse tipo de coisa pode acontecer na próxima década, mais ou menos. [5:53] É. [5:54] E provavelmente nossas vidas como desenvolvedores de software [6:00] seriam diferentes do que são hoje. [6:04] Mas, mesmo assim, podemos escolher, sabe, a criação tranquila, [6:10] a atividade criativa de desenvolvimento de software, em vez de, [6:17] sabe, sermos expulsos do—O setor. [6:20] Sabe, um emprego bem remunerado ou algo do tipo. [6:24] Acho que agora é a hora de escolher o rumo, o nosso rumo, como me sinto e [6:31] como nos comportamos em relação à IA. [6:35] Acho que isso realmente resume a diferença. [6:38] Fiz uma palestra há alguns anos em que falei sobre o fato de não me ver [6:43] como um engenheiro de software. [6:45] Essa nunca foi uma identidade com a qual me identifiquei. [6:50] Soava sério demais, rigoroso demais. [6:52] Eu me via como um redator de software e me vejo assim há muitos anos. [6:57] Portanto, para quem já fazia parte desse grupo em que o rótulo de “engenheiro de [7:03] software” já não se encaixava, acho que vocês estão em uma posição muito [7:08] melhor para adotar o novo papel de criador de software. [7:12] Essa é uma perspectiva mais ampla. [7:15] Na verdade, há mais coisas a se considerar, [7:18] mais coisas a se aprender do que apenas aperfeiçoar a arte de [7:22] escrever código à mão. [7:24] E minha grande descoberta é que é mais gratificante ser um criador de software [7:29] do que meramente um programador. [7:32] E eu adorava ser programador, mas a parte da criação, o pacote completo, [7:37] é simplesmente mais gratificante. [7:39] E acho que nossa sensibilidade como programadores Ruby está excepcionalmente [7:45] bem sintonizada para esta época. [7:47] Qual é o valor humano que agregamos quando trabalhamos com agentes? [7:52] É o bom gosto. [7:53] É o senso de proporção. [7:55] É o senso de beleza. [7:56] Tudo o que sempre nos importou ao escrever código Ruby — a abstração disso é o que [8:02] vai formar um bom criador de software, vai formar um bom desenvolvedor de agentes. [8:08] Então, vejo isso como um motivo de comemoração: o fato de a turma do Top Gun [8:14] aqui estar tão bem posicionada, porque isso não tem nada a ver com o Rails. [8:19] Nem mesmo tem a ver com Ruby. [8:21] Essa é a parte do discurso online que acho tão intrigante, [8:25] como se o que está acontecendo fosse, de alguma forma, exclusivo [8:29] da nossa pequena comunidade. [8:31] Vocês estão cegos? [8:32] Isso vai atingir todo mundo. [8:34] Para todos os domínios, para todas as bibliotecas, [8:38] para todas as estruturas de trabalho, para todas as linguagens. [8:42] E há um foco estranhamente míope em: “ah, então o Rust é a próxima grande novidade”. [8:47] Não dou a mínima para o Rust. [8:50] Tipo, não vou me tornar um programador de Rust porque esse papel [8:54] já foi abstraído de mim. [8:56] O Rust é simplesmente a ferramenta mais eficiente no momento, [9:00] e se amanhã alguém lançar um Rust melhor, eu mudarei sem nenhum do sofrimento que [9:05] está sendo vivenciado agora nesta sala em relação às coisas do Ruby, porque não [9:11] terei nenhum ego investido no Rust. [9:13] E acho que é perfeitamente possível que, em breve, o Rust nem seja [9:17] mais o que estivermos usando. [9:19] Iremos direto para o assembler, e o fato de ele não ser portátil não [9:24] importará, porque simplesmente escreveremos o código de máquina [9:28] necessário para cada plataforma em que quisermos estar, e adeus, Rust. [9:35] Então, não se apegue a essa ideia de que, ah, eu tenho que mudar de lado. [9:40] Os lados já não existem mais. [9:43] Não estamos criando novos. [9:46] Vou abordar o que pode ser ideal para os agentes um pouco mais adiante. [9:50] Acho que você tocou em uma ansiedade fundamental quando surge aquela ideia de [9:56] que, se você sente a energia — ela está lá fora e está disponível —, [10:00] mas se você não a sente por dentro, então há um abismo entre o que poderia ser [10:06] — é quase como o que se espera de você — e, bem, não sei, a ansiedade e o receio [10:11] diante das forças da natureza: como eu posso enfrentar isso? [10:15] Cada indivíduo precisa passar por essa experiência por conta própria. [10:20] É como ouvir que vai haver uma demissão em massa e, bem, que basta se requalificar, [10:26] fazer qualquer curso, aprender a programar. [10:29] E agora, o que fazer? [10:30] Então, quando falamos em “criador profissional cheio de energia”, [10:34] as pessoas estão sentindo isso? [10:37] E as pessoas que sempre sentiram isso já têm essa sensibilidade, [10:41] então não é nada de novo. [10:43] Mas, para quem está sendo convidado a adotar isso, é uma [10:47] disciplina totalmente nova. [10:50] Sim. [10:50] E, em parte, isso simplesmente requer que o tempo faça seu trabalho no ego. [10:54] É por isso que temos os cinco estágios do luto: para explicar às pessoas [10:59] que não é algo instantâneo. [11:00] Para mim, não foi instantâneo. [11:02] Talvez eu tenha passado por isso um pouco mais rápido do que a maioria, [11:07] mas ainda assim tive que passar por esses estágios, e acho que isso [11:11] é perfeitamente normal. [11:12] Deve haver espaço para sentir um pouco de nostalgia por algo de que você realmente [11:17] gostava antes de conseguir fazer a transição para algo que talvez [11:21] você goste mais — ou não. [11:22] Cada mudança de paradigma que tivemos na área de informática deixou algumas pessoas [11:28] desejando que isso não tivesse acontecido. [11:30] A internet foi exatamente assim. [11:32] A era dos celulares foi exatamente assim. [11:35] Havia pessoas que simplesmente não queriam embarcar nesse trem e ficaram na estação. [11:40] Haverá espaço para isso também. [11:43] É, o que me chama a atenção aqui é que comecei a usar Ruby sem nenhum interesse [11:47] no valor econômico da linguagem. [11:49] Gostava de Ruby porque era Ruby e era divertido de usar. [11:53] E era mesmo, no sentido de que, quando as pessoas — como no seu exemplo [11:57] com os retratos — não conseguem mais obter reconhecimento econômico por esse talento [12:01] e conhecimento, para onde elas são redirecionadas? [12:04] Bem, e se você nunca tivesse precisado disso, para começar? [12:08] Talvez o Ruby esteja voltando à sua forma natural. [12:12] É. [12:12] Ao contrário do DHS, tenho um enorme orgulho em relação ao Ruby. [12:20] E, sabe, toda a minha vida depende disso. [12:25] E então mas acho que sou parcialmente responsável, digamos, [12:32] pelo aquecimento global. [12:35] É uma afirmação ousada. [12:38] Consome muita, muita energia. [12:41] E, na era da IA, do ponto de vista puramente econômico, [12:48] financeiro, o Ruby não é a melhor opção. [12:52] Mas temos um enorme impulso e inércia em relação à gigantesca base de [13:01] código do Rails — ou da Ruby. [13:04] Então, este ano, comecei a trabalhar em um compilador alternativo para Ruby chamado [13:14] Spinel, que compila programas em Ruby em binários nativos. [13:21] E ele roda com uma rapidez impressionante e consome muito menos memória. [13:30] Quanto custa? [13:32] Conforme testamos, o programa realista, em condições reais, roda com 1/20 da memória. [13:40] Então, digamos que sua aplicação Rails consuma 100 megabytes de memória. [13:48] O binário nativo da aplicação compilada pelo Spinel consome 20 megabytes. [13:55] Portanto, isso significa que— [13:59] O quê? São 5,5 megabytes, quer dizer. [14:04] O sabe, eu só comecei o Spinel em março, então ele ainda é um bebê. [14:12] Mas tem um potencial e tanto. [14:16] E talvez da próxima vez ele escolha Ruby de novo. [14:22] E compile para o binário nativo pra criar o backend. [14:37] Mats, gostaria de saber mais sobre isso. [14:40] Afinal, você já tem a ideia do Spinel há muitos anos. [14:43] E você trabalha com o MRuby há muitos anos. [14:46] E cada um deles ocupa um lugar diferente no mundo da engenharia e do [14:51] desenvolvimento de software. [14:53] Então, você sempre refletiu sobre o que o Ruby tem a oferecer — no caso do MRuby, [14:58] a um ambiente embarcado — ou o que o Ruby tem a oferecer aos seres humanos? [15:04] E agora o Spinel parece responder à pergunta: o que o Ruby tem [15:08] a oferecer aos agentes? [15:09] O que faz do Ruby o Ruby? [15:11] Se você retirar certos elementos, ele ainda será o Ruby? [15:16] É, isso não é exatamente muito claro. [15:20] Mas eu, sabe, fui por tentativa e erro para definir o que é [15:25] Ruby e o que não é Ruby. [15:28] E o resultado é o CRuby que temos e que quase todo mundo usa. [15:33] Mas, sabe, não existe uma solução única para todos. [15:38] Então, algumas pessoas preferem o JRuby para aplicações corporativas. [15:45] O CRuby é grande demais para microdispositivos embarcados. [15:50] E então — ou talvez o próprio Ruby seja lento demais para — mesmo com o compilador [15:58] JIT que disponibilizamos recentemente. [16:01] Então, sabe, esse subconjunto de desempenho da [16:06] linguagem Ruby pode ser compilado em binário nativo e rodar com [16:12] uma rapidez impressionante. [16:14] E isso significa que, pelo menos por enquanto, [16:19] só eu posso traçar a linha entre o que é Ruby e o que não é. [16:28] Pensando no papel do Ruby em coisas como o Roundhouse — caso nem todos conheçam o [16:35] Roundhouse, trata-se de uma forma de tratar o Ruby como uma espécie de… [16:40] ou uma aplicação Ruby on Rails como uma espécie de oráculo de conformidade que um [16:46] agente pode consultar como uma especificação, e então ele gera Ruby [16:52] puro sem o Rails ou outras linguagens. [16:55] O scaffolding do Ruby está presente nisso, ou é um meio de preservar o Ruby, [17:01] ou é algo que seria um único passo e, depois disso, você deixaria [17:06] a aplicação em Ruby de lado? [17:10] Sabe, as pessoas são diferentes. [17:13] A criação de software envolve diversos aspectos. [17:18] E, muito provavelmente, prevejo que a maioria das pessoas se [17:25] concentre na, sabe, direção do produto e na gestão do mercado do produto. [17:32] Mas algumas pessoas se sentem muito motivadas pela, sabe, [17:38] parte da programação em si. [17:41] Então, isso seria, pelo menos como carreira, algo que nos [17:48] seria tirado em um futuro bem próximo. [17:52] Mas, ao mesmo tempo, isso nos faz aprender a nos concentrar em [17:58] resolver nossos problemas. [18:01] E se, no passado, nos faltava, digamos, capacidade, habilidade ou experiência para [18:10] oferecer ou criar, sabe, uma solução, agora os agentes podem nos ajudar de forma [18:18] que, mesmo sem conhecimento suficiente, possamos criar Podemos criar [18:26] uma solução de qualquer maneira. [18:29] Essa é a situação. [18:31] Mas, ainda assim, pelo que vejo, nem todo mundo vai… [18:37] nem todo mundo vai criar uma solução. [18:41] A maioria de nós, a maioria dos seres humanos, [18:46] está apenas esperando por soluções. [18:49] Então, nesse caso, os, você sabe, provedores de soluções são uma espécie [18:57] de “escolhidos”, como nós aqui. [19:01] Portanto, o aprimoramento — a única coisa que podemos fazer é aprimorar nossa [19:09] capacidade e oferecer uma solução para a humanidade como um todo. [19:16] Isso é mais importante do que fornecer tecnologia específica e focar em [19:23] tecnologia específica, como diz o DHH. [19:28] Mas, mesmo assim, mesmo assim, Ruby é uma linguagem legal. [19:33] E é a linguagem preferida de muita gente. [19:37] E o próprio Ruby motiva as pessoas. [19:41] Mesmo na era da IA, a motivação é o recurso mais importante [19:46] que os seres humanos podem oferecer — algo que só os seres humanos [19:52] podem oferecer, e não a IA. [19:57] Acho que o Ruby tem um papel maravilhoso a desempenhar nesse seu retorno à forma. [20:03] Lembro-me de quando aprendi Ruby pela primeira vez: foi por meio de artigos na [20:08] revista IEEE Magazine, escritos por Dave Thomas e outros autores, [20:13] que descreviam conceitos de código usando Ruby, e eu achava que eles [20:18] estavam escrevendo pseudocódigo. [20:21] Achava que não era executável, mas era. [20:24] E acho que, à medida que avançamos para esse cenário em que não seremos nós mesmos [20:30] a escrever a maioria das linhas de código, ocasionalmente vamos querer entender o [20:36] algoritmo e saber como ele funciona — e o Ruby é a melhor linguagem de [20:41] programação para explicar conceitos. [20:44] Portanto, se, em vez de Dave Thomas me explicar conceitos na revista [20:49] IEEE Magazine, eu agora tiver um agente que me explique meu código em Rust usando [20:55] Ruby, isso parece um retorno incrível à forma. [20:58] Outra coisa que eu diria é que acho que a maioria das pessoas tem dificuldade [21:04] em pensar além do “bolo fixo”. [21:06] E acho que é daí que vem parte da ansiedade. [21:09] Elas imaginam que o mundo do futuro terá o mesmo número de aplicativos que temos hoje [21:15] e, então, imaginam que precisaremos de muito menos programadores [21:20] para criar esses aplicativos. [21:23] E isso vai ser verdade. [21:25] O número de aplicativos que temos no mundo hoje vai exigir muito, [21:30] muito menos programadores para mantê-los e desenvolvê-los. [21:34] Mas podemos criar mais. [21:36] Vamos criar mais. [21:37] Essa é toda a exuberância do momento: estamos criando muito mais software. [21:43] Cada estatística que você vê no GitHub — e o motivo de o site ficar fora do ar a cada [21:49] 5 minutos — se deve à explosão na criação de software. [21:53] Esse é o florescimento. [21:55] Esse é o florescimento. [21:57] Teremos muito mais aplicativos para cuidar, e vamos precisar [22:02] de pessoas para fazer isso. [22:04] É por isso que tenho esse enorme otimismo em relação aos programadores que aceitam o [22:10] futuro e se dedicam ao seu novo papel como criadores de software. [22:15] Vamos trabalhar em muito mais coisas, e isso é empolgante. [22:19] É bom. É estabilidade no emprego. [22:22] Mas isso não vai acontecer se você se agarrar tanto ao lápis a ponto de não [22:28] conseguir imaginar que a calculadora possa te ajudar. [22:34] É interessante relembrar o início dos anos 2000 e a ascensão da programação extrema, [22:40] quando ter uma linguagem muito fluente valia muito a pena. [22:43] O custo de execução da linguagem era insignificante em comparação com [22:48] os custos de desenvolvimento. [22:50] E o — é claro — preço de alterar uma especificação, [22:53] ter um ciclo de desenvolvimento ágil e introduzir práticas como o [22:58] desenvolvimento orientado a testes. [23:00] E vejo uma ironia nada pequena na situação em que nos encontramos agora. [23:05] E quais são os artefatos do nosso trabalho? [23:08] É o Markdown? São as especificações? [23:10] É tudo o que existia antes da Programação Extrema e do qual nos livramos [23:15] por causa das características negativas do longo tempo de ciclo e do alto [23:20] custo — que agora são custo zero? [23:22] Então, voltamos ao “grande projeto inicial” e às metodologias em cascata? [23:29] Não sei. [23:30] Mas a metodologia específica e concreta é menos importante hoje em dia porque, sabe, [23:38] a estrutura do código tem menos importância, já que não [23:44] mexemos mais no código. [23:47] Mas, então, agora precisamos, sabe, formalizar e aprender. [23:53] Temos algo para formalizar e aprender nos próximos anos. [23:58] É como criar uma visão do software, qual deve ser a solução, [24:05] e determinar qual deve ser a solução, e o que é Qual é o problema? [24:12] E, sabe, eles gerenciam a IA para construir isso… [24:17] construir a solução. [24:19] Vocês conhecem o “vibe coding” e também já ouviram falar das histórias de fracasso do [24:28] “vibe coding”, tipo, tudo bem criar jogos como o Tetris, mas, [24:34] quando se tenta criar um aplicativo realista, muitas das tentativas [24:41] fracassaram miseravelmente. [24:44] Mas, em contraste, as pessoas ao nosso redor, ao meu redor, [24:50] como os colaboradores do Ruby, tentam programar ao vivo nas ferramentas, [24:58] como parte da filosofia do Ruby no estilo “live coding”. [25:04] E, surpreendentemente, elas têm uma taxa de sucesso surpreendentemente alta. [25:12] E isso significa que, sabe, nós, programadores com alguma experiência, [25:19] sabemos como conduzir a criação de software. [25:25] Ou sabemos como definir a meta para os agentes. [25:30] Esse tipo de coisa pode ser—É. [25:34] Sabe, precisamos formalizá-las e ensiná-las às próximas gerações [25:41] de desenvolvedores de software. [25:45] E então, por exemplo, sou o líder do “Bible coding” porque — nos [25:52] últimos 15 anos, venho praticando o “vibecoding”. [25:57] Tenho praticado o “vibecoding” porque, sabe, sou o líder da comunidade do núcleo [26:06] do Ruby, e pergunto aos committers: “Ok, que tal implementarmos esse recurso?” [26:17] E então [26:20] Inteligência orgânica. [26:23] A inteligência criou o software. [26:27] E eu testei, analisei e, tudo bem, vamos integrá-lo. [26:34] E que tal melhorar o coletor de lixo assim? [26:39] E os colaboradores apresentam o código: melhoramos tanto assim. [26:47] Ótimo. É assim que trabalhamos atualmente. [26:53] Todo mundo tem colaboradores principais ao seu redor. [27:00] É assim que trabalhamos. [27:03] É assim que vamos trabalhar daqui em diante. [27:09] Não se engane. [27:12] É uma promoção. [27:13] Ora, às vezes você é promovido para um cargo que não quer, [27:17] mas acho que essa promoção, se você der cinco minutos a ela, [27:22] vai ser imensamente gratificante, porque tive exatamente a mesma experiência [27:28] que o Matz teve com o Rails por muitos anos, talvez décadas. [27:32] Na primeira versão do Rails, escrevi tudo sozinho. [27:36] Na segunda versão, talvez metade. [27:39] E quando chegamos à 6ª e à 7ª, quase nada. [27:42] Apenas orientação. [27:43] Para onde queremos ir? O que é bom? [27:46] O que está na moda, o que está fora de moda. [27:49] É a isso que agora todos temos acesso. [27:52] O que também é verdade é que o dilema do inovador geralmente descreve o que [27:58] acontece com as empresas estabelecidas quando surge uma nova tecnologia. [28:04] Primeiro, a nova tecnologia parece um brinquedo. [28:07] Não é uma ameaça. [28:09] Ela só dá conta das coisas mais simples. [28:12] Por que nos importaríamos? [28:14] Temos a maior fatia do mercado e os grandes clientes, e eles não [28:19] se importam com brinquedos. [28:21] Qualquer um que estivesse por perto quando o Ruby ganhou destaque pela primeira [28:27] vez vai se lembrar dessa história. [28:29] “Não é escalável.” Lembra disso? [28:32] É o que as pessoas estão dizendo agora sobre a IA. [28:36] E estão erradas exatamente da mesma forma que estavam erradas sobre o [28:41] Ruby e o Rails lá no começo. [28:44] Porque a programação de vibrações não só funciona e produz ótimos resultados, [28:50] como também está evoluindo a um ritmo absolutamente astronômico. [28:55] Portanto, tudo o que hoje ainda não é escalável vai se tornar [29:00] escalável daqui a 5 minutos. [29:02] Isso está claro. [29:04] Por isso, precisamos tomar cuidado para não ficarmos estagnados [29:08] como os gigantes do setor. [29:11] Para não menosprezarmos essas novidades. Por falar em zombar. [29:15] Porque, por um breve momento, eles não fazem o que a gente quer. [29:17] Mas vão fazer. [29:18] Percebo ecos disso no desprezo pela IA, no fato de chamarem as coisas de [29:24] “porcaria” e se referirem a elas como “substitutos da carne”. [29:29] E até que ponto essas expressões — que são sugestivas e, em certo sentido, [29:35] muitas vezes verdadeiras — são, na sua opinião, diagnósticos reais, [29:40] e até que ponto são apenas uma forma de lidar com a situação? [29:46] 90% conseguem lidar com a situação. [29:50] Uau. [29:51] Não sei. Simplesmente não sei. [29:54] Detesto fazer previsões. [29:57] Não sou bom em prever o futuro. [30:01] É por isso que temos que lidar com probabilidades. [30:03] Não com previsões, nem com certezas, mas com probabilidades. [30:06] Probabilidade. [30:07] E é provável que isso seja apenas uma forma de lidar com a situação. [30:12] E quanto mais cedo você se livrar dessas muletas, mais cedo poderá correr. [30:16] E é verdade que, à medida que descobrimos como usar esses sistemas da melhor maneira [30:22] possível, tanto para nós quanto para eles, vamos acabar adotando algumas [30:26] formas subótimas de fazê-lo. [30:28] E o “meet proxy” é uma delas. [30:30] Se você está gastando tempo copiando e colando entre agentes e mensagens de erro, [30:35] deveria considerar simplesmente deixar o agente ler as mensagens [30:39] de erro diretamente. [30:40] Por que você está nesse ciclo? [30:42] Por que está aí atuando como um “proxy humano”? [30:45] Saia desse papel. [30:46] É insatisfatório e ineficaz. [30:48] Muitas coisas são assim quando você começa a colocá-las em prática. [30:52] Elas são um pouco precárias. [30:54] Ainda não estão totalmente aperfeiçoadas. [30:57] Não temos um processo perfeito. [30:59] Não temos ferramentas perfeitas. [31:01] E nos viramos por um tempo, mas devemos ter a ambição de [31:04] almejar algo mais elevado. [31:06] Portanto, o rótulo de “intermediário de carne e osso” é apenas uma tábua [31:11] temporária para ir de A a B. [31:12] A questão da “desleixada”, porém, é uma desculpa da pior espécie. [31:16] A ideia de que os agentes não conseguem escrever código original, [31:21] de alta qualidade e livre de bugs é, neste momento, simplesmente ilusória. [31:26] É muito mais delirante, muito mais uma psicose em torno da IA do [31:30] que o otimismo sobre o que ela pode fazer, porque é como enfiar a cabeça na areia. [31:36] Então, essa história do “slop”, acho que está na hora de aposentar. [31:41] Até mesmo a granada “slop” não vai durar muito mais por aí. [31:45] Acho que “granada de porcaria” capta algo que “porcaria” não consegue, porque é a [31:50] porcaria mais a forma como é apresentada. [31:53] E é aí que as pessoas sentem que é porcaria, quando isso [31:56] é jogado na cara delas. [31:58] E é como se não fosse levado até o fim. [32:00] Se você tem uma ideia, bem, quer dizer, é como receber um comunicado de imprensa [32:05] que não foi bem pensado, e agora cabe a você dedicar sua [32:09] atenção para analisá-lo e entendê-lo. [32:11] E a “granada de slop” é que você precisa descobrir se vale a pena lançar isso. [32:16] Então é há… o que está faltando aí? [32:18] Há mais do que apenas escrever o código. [32:21] Não me importo nem um pouco com “granadas de lixo”. [32:25] Eu simplesmente as vejo como sugestões e não preciso me preocupar em aceitá-las. [32:30] E se eu gostar da sugestão, meu agente vai analisar o código e [32:34] voltar com uma implementação impecável. [32:36] Prefiro, de longe, pull requests e issues abertos pelos agentes. [32:40] Eles são de qualidade superior à de qualquer pull request ou issue produzido [32:45] por um ser humano comum em qualquer repositório que já tive o [32:49] privilégio de gerenciar. [32:51] Isso não significa que eu tenha que aceitar a implementação. [32:54] Na verdade, é ainda melhor, porque, se você não escreveu o código, [32:59] não sentirá nenhum sentimento de perda quando eu descartar tudo e reescrever. [33:04] Bem, não serei eu quem reescreverá, e sim meu agente, mas você não estará [33:08] mais apegado às linhas de código. [33:10] Isso é uma bênção. [33:12] Grande parte do atrito nas comunidades de código aberto do passado vinha do fato de [33:17] as pessoas se apegarem às linhas de código porque, por acaso, haviam dedicado muita [33:22] energia a escrevê-las, e era difícil abrir mão delas quando [33:26] surgiam linhas de código melhores. [33:28] Nunca tive esse problema. [33:30] Acho que não restam muitas linhas de código na base de código do Rails [33:34] que eu tenha escrito pessoalmente. [33:38] Maravilhoso! Melhoria, progresso, algo melhor. [33:41] Acho que essa ideia de que não estamos mais escrevendo o código manualmente [33:46] permite que mais pessoas vivenciem isso: uma produção de linhas de código sem ego [33:51] e, portanto, um apego apenas às ideias, às ideias melhores e à melhoria. [34:06] É. [34:06] Acho que conseguimos lidar com a enorme quantidade de, você sabe, [34:14] PRs e issues do com a ajuda da IA. [34:18] Por exemplo, ontem, acordei, tomei banho e verifiquei meu GitHub, [34:25] e não tínhamos nenhum issue nem pull request para o spinout. [34:32] Isso é ótimo. E eu… [34:35] então acordei, vim a pé até aqui no local do evento e participei de uma discussão. [34:44] E, logo antes da palestra dele, recebi 20 issues e 1 pull request em apenas 1 hora. [34:55] E então [34:57] Então peguei meu celular e abri o aplicativo do Claude. [35:02] Pedi ao Claude para, bom, resolver esses problemas na solicitação de pull. [35:10] E, no final da palestra, quando terminei, o Claude já tinha resolvido [35:17] automaticamente aqueles 12 problemas. [35:21] É assim que fazemos — é assim que criamos o software. [35:27] Tudo mudou. [35:28] E podemos aproveitar o valor da IA usando a própria IA. [35:36] Isso me leva a outra coisa que eu ia perguntar. [35:39] Ao longo desses últimos nove meses, na verdade, à medida que as pessoas foram [35:44] aceitando, de modo geral, que, bem, esses modelos podem produzir um código [35:48] excelente, elas continuam procurando aquilo que eles não conseguem fazer. [35:53] E qual é essa pequena lacuna que não para de diminuir, representando o domínio [35:58] humano, onde sempre teremos algum tipo de superioridade? [36:02] E por que, afinal, insistir nisso? [36:04] Mas um deles é a sensação de ter bom senso. [36:07] Agora, quando vejo o Claude lidar com todas essas questões, [36:11] analisar cada uma delas e tomar as decisões certas, será que isso [36:15] ainda é um fator limitante? [36:17] São os humanos que estão exercendo seu bom senso, ou até que ponto [36:21] cedemos a decisão aos agentes? [36:25] Na medida em que sua competência o justifique. [36:28] E a competência deles é medida pela sua confiança de que a última solicitação de [36:34] pull foi tratada corretamente, exatamente como você faria com qualquer pessoa. [36:39] Eu observo os agentes e procuro os mesmos sinais que procuraria se fosse um [36:44] programador trabalhando na 37signals. [36:47] Essa pessoa está pronta para assumir mais responsabilidades? [36:51] Com que frequência preciso verificar o trabalho? [36:54] E quanto mais sênior o agente ou o funcionário se torna, menos eu verifico, [37:00] mais confio, mais presumo que ele tenha feito tudo certo e mais também aceito que [37:05] há o risco de que ele não tenha feito. [37:08] Se eu ler cada linha de código, saberei o que cada uma delas faz. [37:13] Se eu parar de ler as linhas de código, terei que confiar nos [37:17] resultados e na confiança. [37:19] E, ocasionalmente, o agente cometerá um erro. [37:22] Quem entre nós nunca cometeu um? [37:24] Quem entre nós nunca escreveu um código ruim, com bugs, [37:28] que poderia ser mais rápido? [37:30] Todos nós, o tempo todo. [37:32] Por que vocês têm essa exigência de que a nova inteligência deve ser perfeita e [37:37] isenta de falhas desde o primeiro dia? [37:40] Isso é a psicose da IA. [37:41] Isso é a ilusão da IA. [37:43] Essa inteligência está melhorando rapidamente, mas ainda não é [37:47] perfeita — e nós também não somos. [37:50] Então, qual é o problema? [37:53] Existe uma assimetria na norma. [37:54] Quero dizer, é semelhante ao que ocorre com os veículos autônomos, [37:58] em que qualquer colisão já é demais, e, no entanto, ocorrem dezenas de milhares de [38:03] colisões por ano, mas o ser humano está no controle. [38:06] Então, será que o fato de o ser humano estar no controle, ao volante, [38:09] torna isso mais justificável? [38:11] O fato de gerar falhas, erros e bugs e representar um risco? [38:15] Em uma sociedade dominada por processos judiciais, sim. [38:19] Em uma sociedade sensata, orientada por resultados, não. [38:23] Existem diferentes sociedades ao redor do mundo que lidam com esse problema [38:28] de maneiras muito distintas. [38:30] Na Dinamarca, não há processos por danos pessoais. [38:33] Simplesmente não existe essa categoria de ação. [38:36] Não é uma área do direito que tenha qualquer impacto sobre a forma [38:41] como as decisões são tomadas. [38:43] Essas sociedades se sairão melhor. [38:45] Porque, neste momento, infelizmente nos deparamos com o problema [38:49] de ter uma tecnologia de direção superior que, segundo os indicadores que vi, [38:54] tem cerca de 8 vezes menos probabilidade de se envolver em uma colisão do que o ser [39:00] humano médio; e, ainda assim, dizemos: ah, não sei, uma colisão já é demais. [39:05] Entre 40.000 e 45.000 pessoas morrem todos os anos nos Estados Unidos [39:10] em acidentes de trânsito. [39:12] Se pudéssemos melhorar isso agora mesmo e reduzir esse número para um oitavo, [39:17] 30 mil pessoas estariam vivas no final do ano que, de outra forma, não estariam. [39:22] Não é uma sociedade sensata aquela que opta por ignorar isso. [39:27] Então, sim, isso me faz pensar em outras aplicações dessas mesmas tecnologias, [39:31] porque não se trata de um fenômeno exclusivamente da programação. [39:35] As pessoas estão buscando aplicar essas mesmas tecnologias na área da [39:39] saúde e na engenharia como um todo. [39:41] Você gostaria que uma equipe de IA projetasse uma nova ponte? [39:45] Quero dizer, engenharia de verdade. [39:48] É. Mas tenho uma preocupação. [39:51] Mesmo que criemos o software, ao usar agentes sem conhecer os detalhes, [39:59] a solução ainda depende de componentes de software existentes, [40:06] como o compilador Rust, o Ruby on Rails ou o interpretador de [40:12] Ruby, seja lá o que for, o Linux ou o PostgreSQL. [40:17] E então, como dependemos cada vez mais dos agentes, os outros componentes se [40:26] tornariam cada vez mais transparentes. [40:30] E, embora esses componentes — em sua maioria, software de código aberto — sejam [40:38] muito importantes e viáveis para a sociedade, as pessoas não os veriam [40:46] e não se importariam com eles. [40:49] Essa é a minha maior preocupação. [40:53] Quanto mais os componentes se tornam transparentes, menos a sociedade se [41:00] importa com eles, com a manutenção e com a sustentabilidade. [41:07] Essa é a minha preocupação, e eu tenho que nós temos que trabalhar [41:14] para manter esses componentes, incluindo o Ruby on Rails, [41:20] o Linux e os bancos de dados. [41:24] Isso me faz pensar, David, no que você disse sobre as desvantagens da abstração. [41:30] Em que momento a gente acaba ignorando esses componentes e cada um [41:34] acaba inventando o seu próprio? [41:36] E penso em coisas como, por exemplo, quando falamos de bibliotecas específicas: [41:41] por que não, sei lá, ignorar uma biblioteca de WebSockets e [41:45] simplesmente implementar o protocolo WebSockets diretamente? [41:49] E todo mundo, quer dizer, é um ecossistema amplo com várias [41:53] implementações diferentes evoluindo de forma independente e com suas próprias [41:58] funções de aptidão, que precisam ser capazes de interoperar. [42:02] E minha mente de engenheiro imediatamente pensa: bem, existem essas desvantagens [42:07] claras, como ineficiências de escala; se houver um bug, você precisa corrigi-lo em [42:12] um único lugar, em vez de em 100 mil lugares. [42:15] Mas o que você acha? [42:18] Essa é a próxima fronteira. [42:20] Perceber que as abstrações em nossas próprias bases de código são obstáculos [42:26] à concorrência e ao paralelismo. [42:28] E o mesmo vale, até certo ponto, para nossas estruturas de trabalho [42:33] e nossas linguagens de programação. [42:36] E, eventualmente, chegaremos ao nível do fóton, diretamente à física. [42:41] E que todos os nossos esforços nos últimos 60 anos de desenvolvimento de software [42:47] tiveram como objetivo lidar com os limites da cognição humana. [42:52] E se esses limites não se aplicam mais, as soluções também não. [42:56] Portanto, consigo imaginar perfeitamente que o futuro do software se pareça mais [43:02] com a vanguarda da jogabilidade generativa que temos hoje. [43:07] Já existem modelos capazes de gerar mundos de jogo em tempo real. [43:12] A ideia de que poderíamos acabar em um mundo onde sistemas operacionais, [43:17] drivers de dispositivos, frameworks e linguagens sejam gerados em [43:22] tempo real parece ficção científica neste momento, mas o mesmo acontecia com a ideia [43:28] de que esses agentes poderiam escrever todos os nossos aplicativos web para nós e [43:34] nos livrar do lápis há muito pouco tempo. [43:37] Então, acho que, na verdade, precisamos de mais ficção científica, [43:42] de brincadeiras mais criativas, porque é isso que vai guiar nossa [43:47] imaginação daqui para frente. [43:49] Grande parte da nossa imaginação hoje está ancorada em obras como “2001: [43:55] Uma Odisséia no Espaço”. Hum-hum. [43:57] Grande parte da nossa percepção sobre os perigos da IA vem do HAL 9000, [44:02] do Exterminador do Futuro e de obras de ficção científica [44:07] escritas há 40 a 100 anos. [44:08] Precisamos de uma ficção científica melhor neste momento, [44:13] porque todas essas histórias já se tornaram realidade, em certa medida; e, [44:18] portanto, precisamos de novos horizontes que nos tragam nova inspiração sobre [44:24] como pode ser uma nova era da computação. [44:27] Você acha que existem limites de velocidade que estamos enfrentando [44:30] imediatamente aqui quando se fala, quer dizer, digamos que eu queira [44:34] contornar a libc e simplesmente se comunicar, sabe, por meio [44:37] de microcódigo com uma CPU? [44:38] É como se isso fosse exigir muito mais tokens. [44:41] Tipo, o que isso aciona dentro de um modelo? [44:43] Existem outros tipos de barreiras à eficiência além da eficiência em tempo de [44:47] execução e da eficiência no tempo de desenvolvimento. [44:50] Já reduzimos bastante o tempo de desenvolvimento. [44:53] É. [44:53] Ou, no ciclo de retroalimentação, o custo é quase zero. [44:56] Então dizemos: “Bem, não preciso arcar com o custo de nenhuma outra linguagem — [45:01] qualquer que seja a que me ofereça alta expressividade. [45:04] Portanto, vamos escolher o Rust, pois ele vai reduzir drasticamente [45:08] o custo de execução”. [45:10] Mas e quanto ao custo do ciclo, os tokens que são gastos para representar [45:14] a realidade e operar dentro dela? [45:17] Acho que estamos lidando com o Commodore 64 neste momento. [45:21] Temos um agente de 1 MHz. [45:23] E no ano que vem teremos um que rodará 10 vezes mais rápido, e no ano seguinte, [45:29] 100 vezes mais rápido, e os seres humanos são simplesmente [45:33] incapazes de compreender coletivamente o crescimento exponencial. [45:37] Portanto, todas as nossas preocupações atuais sobre a eficiência e o custo dos [45:42] tokens são relevantes neste momento, e você deve prestar atenção ou [45:47] sua conta de tokens vai explodir. [45:49] Mas essa atenção é uma consideração de curto prazo. [45:53] É claro que isso vai ficar mais barato. [45:56] Mais uma vez, esse absurdo apocalíptico do “decrescimento” — de que estamos prestes a [46:02] ser enganados pela Anthropic e pela OpenAI — é simplesmente ignorância econômica. [46:07] Os modelos de peso aberto já são fenomenalmente bons. [46:11] Existe concorrência. [46:12] Nunca houve tanta concorrência em um novo campo da computação quanto [46:17] temos agora com a IA. [46:18] Nenhuma das mudanças de paradigma anteriores teve algo parecido com [46:23] isso em termos de concorrência. [46:25] Quando os dispositivos móveis surgiram, tínhamos dois players: o Google e a Apple. [46:31] Quando o mercado de computadores de mesa se dividiu, tínhamos o Windows e a Apple. [46:37] Agora, temos um milhão de provedores de tokens. [46:40] Talvez a Anthropic e a OpenAI estejam na liderança, mas essa vantagem é [46:45] medida em meses, se não em semanas. [46:49] Não há nada com que se preocupar, pessoal. [46:51] As coisas vão melhorar. [46:52] Vão ficar mais baratas. [46:54] Vão ficar ainda melhores. [46:59] Há alguns meses, Matz Endo-san fez essa observação de que Ruby é a linguagem [47:05] mais eficiente em termos de tokens. [47:08] Sim. [47:09] Há alguns meses, nós — a equipe da Kaleido — analisamos várias linguagens, [47:16] incluindo Ruby, Python, JavaScript e TypeScript, [47:21] além de Rust, Kotlin, Go e Haskell. [47:25] E, curiosamente, há três linguagens entre — não me lembro bem, [47:31] provavelmente 13 linguagens — que apresentam bastante eficiência [47:37] em termos de tokens e de tempo. [47:40] E essas linguagens são Ruby, Python e JavaScript — JavaScript puro. [47:47] E, curiosamente, a tipagem estática não contribui nem para a eficiência de [47:54] tokenização nem para a eficiência de tempo. [47:59] Eu te disse! [48:00] Para complementar isso, considerando que os agentes têm o mais [48:04] próximo que consigo dizer é que eles se divertem com essas linguagens [48:09] eficientes em termos de tokens. [48:11] Eles conseguem chegar rapidamente ao resultado que buscam. [48:15] E se eu tivesse alguma medida mais precisa da satisfação dos agentes, [48:20] seria o fato de eles terem seguido o método de escalada de montanha. [48:25] É, é uma suposição um pouco ousada, mas acredito que, sabe, [48:30] uma linguagem de programação que seja agradável para os humanos, [48:35] projetada para proporcionar o prazer de programar, provavelmente essa linguagem [48:42] também seja agradável para as IAs. [48:47] Stream do Android em Ruby. [48:51] Então, o interessante aqui foi que Chad Fowler fez um teste de desempenho com [48:55] várias tarefas representativas, e o Ruby não foi escolhido em nenhuma delas. [49:00] E o que mais — ou melhor, as linguagens mais comumente utilizadas [49:03] foram Python, JavaScript etc., dependendo do tipo de problema. [49:07] E, hum, isso talvez reflita o pré-treinamento com [49:10] base no que eles viram. [49:11] Portanto, o que eles conhecem é o que eles usam. [49:14] Como você orienta um modelo? [49:15] Bem, no sentido de que estamos meio que nos desviando do assunto aqui. [49:19] Estamos dizendo que vamos permitir que os modelos façam tudo, mas os modelos já [49:24] têm seu próprio senso de “Rails” interno. [49:26] É nisso que eles foram treinados. [49:28] Então, como fazemos para que os modelos façam o que queremos? [49:32] E, quer dizer, talvez isso esteja distorcendo um pouco o [49:35] contexto, porque não é necessariamente fazer o que queremos, [49:38] mas recebemos o resultado daquilo em que eles foram treinados. [49:42] Será que é isso que queremos? [49:47] Não acho que os agentes se importem. [49:49] Se você quiser que eles se comuniquem com você em Ruby, eles falarão em Ruby, [49:54] e são muito bons nisso. [49:55] As avaliações dos agentes que temos realizado mostram exatamente isso. [50:00] Eles são eficientes em termos de tokens. [50:02] Ficam perfeitamente à vontade para se comunicar com você em Ruby. [50:06] Eles falam Python por padrão porque foi com essa linguagem que os pesquisadores de [50:11] aprendizado de máquina que vêm trabalhando nesses sistemas foram treinados. [50:15] Mas isso não tem influência sobre qual linguagem eles dominam melhor. [50:20] Eles poderiam muito bem falar Ruby com você. [50:22] Eles não se importam. [50:24] Eles falam todas as linguagens fluentemente. [50:26] Além disso, o foco no pré-treinamento se torna muito míope muito rapidamente, [50:31] e acho que ficamos presos nessa visão logo no início, quando estávamos pensando em [50:36] como poderíamos ajudar os laboratórios a ensinar melhor Ruby aos modelos, [50:40] porque tínhamos essa ideia de que eles precisavam ver muito Ruby [50:44] para escrever bem em Ruby. [50:46] Não, eles não precisam. [50:47] Os princípios do excelente desenvolvimento de software são universais, [50:51] e não importa se eles aprendem essas regras em JavaScript, Python ou Smalltalk. [50:56] Eles vão traduzir para a forma final com a mesma eficiência. [51:00] Esse é o segundo equívoco da era passada: achar que eles são papagaios. [51:04] Eles estão apenas repetindo o que lhes dissemos. [51:07] Não, não estão. São pensadores incrivelmente criativos. [51:11] Na verdade, é por isso que representam um desafio tão grande. [51:14] Na área de segurança, eles são incrivelmente criativos ao [51:18] encadear vários ataques combinados. [51:20] E é por isso que estamos tendo dificuldade em lidar com isso e precisamos de nossos [51:25] próprios agentes para nos defendermos contra eles. [51:28] A criatividade existe. [51:29] Na verdade, se há alguma diferença, eles são mais criativos do que [51:33] os humanos que os comandam. [51:35] Então, aproveite isso. [51:36] Peça que eles falem Ruby com você quando for isso que você preferir. [51:41] Quando você quiser examinar o código, é claro que eles devem falar Ruby, [51:45] porque Ruby é a melhor linguagem de programação para humanos. [51:49] Portanto, peça que eles traduzam para você, e depois eles podem voltar a falar [51:53] código de máquina em assembly diretamente com a CPU. [52:00] É isso que a Spinnit faz. [52:03] É. [52:03] Então, eu gostaria de falar um pouco sobre o que vem depois do Rails. [52:08] O Rails. Temos o Rails para desenvolvimento web. [52:12] É uma espécie de concretização específica do que nós, como programadores, [52:18] trazemos para o mundo da tecnologia. [52:20] Quero dizer, nos últimos 20 anos. [52:23] E isso está mudando. [52:25] Nosso domínio está mais sólido, mais abrangente. [52:28] Podemos fazer mais. [52:30] E, ainda assim, há uma sensação de: “Quero manter o Rails”. [52:35] E não precisa necessariamente ser a estrutura, mas e os valores do Rails? [52:40] E você, David, com o Amashi, está começando algo novo. [52:44] E os valores dele são atraentes. [52:47] E o Matz, com o MinaSwan O Matz é legal, então a gente também é legal. [52:52] Isso nunca me pareceu muito certo, porque é como se a gente não fizesse algo [52:58] só porque outra pessoa é de um jeito determinado. [53:02] Mas é quase como dar permissão para uma forma de interagir com uma linguagem. [53:08] Hum-hum. [53:08] Que é normal valorizar as coisas que o Ruby valoriza. [53:11] E, com essa permissão, há um ótimo filtro para identificar quem [53:15] se sente atraído por essa linguagem. [53:17] Então, vocês dois, como fundadores, o que vem por aí para vocês? [53:22] Não sei, mas respeito muito o Linus Torvalds porque ele criou o Linux. [53:30] Essa é uma grande conquista. [53:33] Mas, além disso, ele criou o Git. [53:37] Uma coisa já é uma história, mas criar duas grandes obras é uma espécie de lenda. [53:46] E então eu é por isso que respeito muito o Dalí. [53:52] Mas, sabe, ele criou o Ruby on Rails e o Naomachi, certo? [53:58] Ele está escrevendo uma lenda. [54:02] Estou criando o Ruby. [54:04] E quanto a outra coisa? [54:07] É, deixa eu pensar nisso. [54:12] Bem, acho que é muito importante que as pessoas encontrem seu grupo, [54:17] encontrem outras pessoas que gostem das mesmas coisas que elas, [54:21] que tenham a mesma visão de mundo — não exatamente igual, mas compartilhada —, [54:26] porque precisamos de um pouco de atrito. [54:28] Precisamos de um pouco de discordância para podermos aprender uns com os outros. [54:33] E eu realmente acho que a razão pela qual todos levantaram a mão quando perguntaram [54:39] “você se considera um Rubyista?” é que temos uma visão comum sobre a importância [54:44] do Ruby como forma de expressão ao programar máquinas. [54:47] Isso é realmente importante. [54:49] Nem todo mundo compartilha dessa visão. [54:52] Há muitas pessoas que detestam profundamente o Ruby. [54:55] Há muitas pessoas que não gostam do Umachi, do Rails ou de qualquer outra [55:00] coisa com a qual eu tenha me envolvido. Isso é bom. [55:03] Seria tão chato se todos nós gostássemos das mesmas coisas exatamente da mesma [55:08] maneira e houvesse apenas uma linguagem de programação, um framework, [55:12] um sistema operacional neste mundo. [55:15] Talvez fosse eficiente, mas com certeza não seria divertido. [55:18] Porque os seres humanos são tremendamente diversos em suas formas de pensar. [55:23] E respondem de maneira diferente a diferentes tecnologias, a diferentes [55:28] paradigmas, a diferentes metodologias. [55:30] O debate de longa data na comunidade de programação sobre tipagem estática versus [55:36] tipagem dinâmica é uma ilustração perfeita disso. [55:39] Você pode apresentar quantos argumentos quiser às pessoas de um lado ou de outro, [55:45] elas não mudarão de ideia porque não chegaram a essas posições por meio do [55:50] raciocínio; portanto, não é possível convencê-las a [55:54] abandoná-las com argumentos. [55:56] Algumas dessas posições são simplesmente fundamentais, quase que [56:01] predefinições em seus cérebros. [56:04] Emacs. [56:05] Exatamente! Tabulações x espaços, Emacs x Vim. [56:08] Essas são exatamente essas linhas divisórias, e devemos mantê-las, [56:12] e devemos celebrá-las. [56:14] Precisamos celebrá-las e precisamos encontrar novas. [56:17] Então, quando avançarmos para o futuro e os agentes estiverem escrevendo cada vez [56:22] mais do nosso código, precisaremos de novas maneiras de nos [56:25] conectar com os outros, criar camaradagem e encontrar um grupo. [56:29] Acho que essa comunidade aqui tem uma oportunidade única de fazer isso juntos. [56:34] Vocês já sabem que enxergam grande parte do mundo da mesma maneira. [56:38] Então, à medida que avançarmos para o que vier a seguir, fiquem por aqui. [56:42] Vai ser muito legal. [56:47] Então, se não podemos prever o futuro, quer dizer, talvez possamos nos [56:53] preparar para ele e celebrar o presente. [56:57] Na sua opinião, o que o Ruby on Rails realmente acertou nessas últimas décadas? [57:05] Para mim, o foco está na autonomia. [57:07] Programadores individuais capazes de ir muito mais longe do que iriam com [57:12] ferramentas menos eficientes, menos prazerosas e menos bonitas. [57:17] O Ruby, para mim, foi essa chave mágica, pois não só me proporcionou uma ferramenta [57:23] prática para criar aplicativos web, mas também foi uma fonte inesgotável de [57:28] alegria e motivação para me dedicar a esse trabalho. [57:32] Acho que nós, nas comunidades do Ruby on Rails, compreendemos isso melhor [57:37] do que qualquer outra pessoa. [57:39] Uma compreensão da psicologia humana, do que impulsiona a produtividade. [57:44] Um componente enorme disso é exatamente o que você disse. [57:48] É a motivação. [57:49] É trabalhar com ferramentas belas e ergonômicas que criam algo que, [57:54] à primeira vista, pode parecer frívolo. [57:57] Código que parece poesia. [57:58] Além da questão de ele rodar rápido. [58:01] Agora, essa é a outra questão sobre o momento atual. [58:05] Acho importante entender que existem aplicativos em que o desempenho é [58:10] fundamental e que podem ser aprimorados reescrevendo-os em algo como Rust. [58:15] E, por outro lado, há muitos, muitos, muitos, muitos outros em que [58:19] essa eficiência não importa. [58:21] A grande maioria dos aplicativos Rails já roda em um único Raspberry Pi. [58:27] Não precisa de mais velocidade do que isso. [58:30] E, quando for necessário mais hardware, você pode trocá-lo. [58:35] Então, vou continuar a iniciar todas as novas aplicações web que [58:39] escrever em Ruby on Rails. [58:40] É uma maneira maravilhosa de começar. [58:43] E terei grande satisfação em dar uma espiada nos bastidores e ver esse belo [58:47] código sendo gerado pelos agentes. [58:49] E então, se chegar o momento em que algo se torne tão popular que seja [58:54] economicamente vantajoso reescrevê-lo em Rust ou em código de máquina, [58:58] simplesmente faremos isso. [59:00] E então poderemos transformá-lo de volta em Ruby, se assim quisermos, [59:04] por um momento de pura alegria e apreciação da bela poesia do código. [59:09] Tudo isso é flexível. [59:10] Podemos seguir em uma direção ou na outra. [59:13] Você não precisa se prender a nada e pensar: “Meu Deus, agora tenho [59:17] que ser um programador de Rust”. [59:19] Eu não te condenaria a esse destino. [59:21] Confie em mim. [59:24] Graças a Deus. [59:28] Pelo que acredito, a maior contribuição da comunidade Ruby para o mundo é mostrar a [59:36] importância da alegria e da motivação em uma comunidade — no [59:43] cenário da programação. [59:45] Nós, seres humanos, precisamos de motivação para fazer qualquer coisa. [59:52] Portanto, precisamos estar motivados para criar software ou, sabe, [59:59] para criar qualquer coisa — e também para melhorar a sociedade. [60:06] E nós — quando sentimos alegria, podemos ser muito mais produtivos no produto — [60:14] É. [60:15] em desenvolvimento. [60:17] Esse tipo de coisa não fazia parte do senso comum há 30 anos. [60:22] Portanto, essa é a maior contribuição da linguagem Ruby. [60:27] E o princípio básico, acredito, é que, enquanto as preocupações humanas [60:34] continuarem as mesmas no futuro, isso permanecerá. [60:38] Portanto, a motivação é importante. [60:41] A alegria importa e a liberdade importa. [60:45] Esse tipo de coisa vai permanecer igual. [60:48] Mas, sabe, a tecnologia vem e vai, e talvez no futuro o Ruby seja menos [60:55] importante, venha a se tornar menos importante, mas, de qualquer forma, [61:01] a alegria, a motivação e a liberdade ainda serão muito importantes. [61:07] Obrigado. [61:07] Continuará sendo importante para todos nós, desenvolvedores ou criadores. [61:15] Claro que sim. [61:16] Sim, quando penso na felicidade do programador, é uma combinação [61:20] de autonomia e alegria. [61:21] E há algo sobre a felicidade do programador profissional, [61:25] talvez: também é receber pelo trabalho. [61:27] É o reconhecimento do que você está criando e da relevância dentro do âmbito [61:32] profissional — saber que você tem um futuro fazendo esse tipo de trabalho. [61:37] Então, para finalizar, olhando para trás — e isso é realmente [61:40] como uma parceria de 20 anos entre o Ruby on Rails, a autonomia e a alegria —, [61:45] pelo que você é mais grato? [61:50] Tenho muita gratidão ao Matz por ter permitido que eu e outros membros da [61:54] comunidade Rails concluíssemos o livro que ele começou. [61:57] Colocar o programador de aplicativos no mesmo nível que o criador da linguagem e [62:02] fazer com que não fosse possível distinguir a diferença entre os dois. [62:09] Agradeço ao DHH e à comunidade do Rails por terem divulgado o Ruby para o mundo. [62:18] Antes do Rails, o Ruby já existia, mas praticamente ninguém o conhecia. [62:26] E então, graças ao Rails, todo mundo começou a usá-lo, [62:32] e muitos aplicativos — incluindo o Shopify, o GitHub e as primeiras versões [62:41] do Twitter — foram desenvolvidos com Ruby on Rails, e todo mundo passou a usá-lo. [62:50] E, no passado, muitas, muitas, muitas startups usavam o Ruby on Rails, [62:58] e elas tiveram, você sabe, lucros e mudaram o mundo. [63:04] Isso é uma grande alegria para mim. [63:08] E me deu uma espécie de autoestima. [63:12] E, depois do Rails, pude trabalhar com Ruby em tempo integral. [63:19] Então, sim, eu estou mais do que, você sabe, eu agradeço muito, muito, muito [63:28] mesmo pela existência do DHH e do Rails. [63:34] Bem, Matz, David, obrigado a vocês dois por tudo. [63:37] Obrigado.