Olá, Rubista! Tudo bem com você? 👋
Essa semana eu não precisei farejar muito longe. O assunto estava no palco principal, em Las Vegas.
O Matz abriu a RubyConf 2026 com uma palestra chamada “Extreme Vibe Coding”. Contou, sem rodeio nenhum, que usa Claude Code para revisar e mergear pull requests em massa. Pausa pra pensar nisso comigo: o criador do Ruby, falando de vibe coding, na abertura da conferência.
E ainda deixou a frase que eu queria ter escrito:
“Abra mão das teclas, não da responsabilidade.”
Guarda essa, porque ela volta várias vezes ao longo da edição. Quase tudo que separei pra hoje gira em torno da mesma pergunta: o que continua sendo seu depois que você delega o resto?
Fora isso tem bastante coisa boa. Performance, banco de dados e uma discussão sobre open source que ainda vai render muito pano pra manga.
Esta é a edição #04 do Radar da Semana. Vem comigo!
Ruby & Rails
Um tipo polimórfico não é uma foreign key
Brandon Weaver abriu a série “Rails, as partes afiadas” mirando em algo que quase todo projeto Rails carrega sem pensar: associações polimórficas. O argumento é direto. Elas não são foreign keys de verdade, não têm as garantias de integridade referencial que você assume que têm, e o preço aparece em dados órfãos e em constraints que o banco não consegue impor.
A posição dele não tem meio-termo. Quando perguntam sobre relações polimórficas, a resposta é simplesmente não faça.
Eu não sei se concordo com essa dureza toda, confesso. Mas ele traz código na mão, e depois de ler fica difícil usar o padrão no automático como a gente costuma fazer.
Quando uma query do Active Record realmente roda?
Syed Aslam destrincha um ponto que confunde muita gente boa: uma ActiveRecord::Relation é intenção de query adiada, não verdade do banco. O texto mostra em que momento a query dispara de fato, por que isso importa pra N+1 e pra memória, e como o encadeamento de scopes engana você sobre o que já foi ao banco.
É daquele tipo de leitura que separa quem sabe usar o Active Record de quem entende o que ele faz por baixo.
Mastodon no Spinel: até onde a compilação AOT de Ruby vai
Sam Ruby já tinha compilado um app Rails básico no Spinel, o compilador AOT do Matz que transforma Ruby em executável C nativo. Agora ele foi atrás da pergunta que interessa: e um app grande, de verdade? O trabalho pra rodar o Mastodon está em andamento e já rendeu subprodutos úteis, como clientes Redis e Postgres específicos pro Spinel.
Se você nunca ouviu falar do Spinel, comece pelo texto do Nikita Drachevskii. Ele explica o que a ferramenta é e, principalmente, o que ela não é. São cerca de 11,6x de ganho sobre o CRuby em computação pura, mirando CLIs, programas de sistema e extensões nativas. Rails não está no alvo, porque depende justamente da metaprogramação que o Spinel abre mão de suportar.
🔗 Mastodon no Spinel · Spinel explicado
Pra ficar no seu Radar
Três releases de Ruby na semana. O 4.0.6 saiu no dia 14, de rotina. O 3.3.12, no dia 16, traz correções de segurança pro
erbe pronet-imap, e o 3.4.10 da semana passada também mexeu nonet-imap. Se você está em qualquer série anterior à 4.0, vale olhar hoje. Patch de segurança adiado cobra juros. 🔗 4.0.6 · 3.3.12 · 3.4.10Novo tutorial oficial do Rails: Product Reviews estende o app de e-commerce do “Getting Started” com uma feature de avaliações. Material canônico e atualizado, bom pra indicar a quem está subindo de nível. 🔗 Guia
SimpleCov chegou ao 1.0 depois de mais de 15 anos em 0.x. Nova UI de relatório, API de configuração redesenhada e melhor suporte a testes paralelos. 🔗 Changelog
Rails 7.2 chega ao fim da vida no mês que vem. Se seu app ainda está lá, o relógio corre.
Gems & Bibliotecas
Lexxy ganha casa própria
Um ano depois de ser apresentado como substituto do Trix, o Lexxy amadureceu. Já é o editor de rich text principal do Basecamp e agora tem homepage própria, com Markdown, smart links, syntax highlighting de código e integração nativa com o Action Text.
Se você monta interfaces de conteúdo em Rails e vive espremido pelas limitações do Trix, a troca ficou fácil de justificar.
Hotwire Native 1.3
Lançamento grande do framework que transforma apps Hotwire renderizados no servidor em apps nativos de iOS e Android. Continua sendo a aposta mais séria do ecossistema em server-driven mobile, com aquela promessa de um time pequeno entregar web, iOS e Android a partir de uma base só.
rails-paradedb: full-text search sem um segundo sistema
A gem oficial do ParadeDB traz busca full-text com ranking BM25 direto pro ActiveRecord, consultando suas tabelas Postgres vivas. Sem ETL, sem job de sincronização, sem um cluster de search pra manter de pé.
Junto com o pgvector e o Extralite 3.0, ela entra numa leva de ferramentas que empurram capacidade pra dentro do banco em vez de pedir mais uma peça na infraestrutura. Repara nisso ao longo da edição, porque o assunto volta.
🔗 rails-paradedb · Extralite 3.0
RDoc 8.0
Stan Lo entregou a maior release do RDoc em anos. O parser saiu do Ripper legado pro Prism, as assinaturas RBS agora aparecem ao lado da doc dos métodos (em HTML e no ri), tem servidor de preview com live-reload, e arquivos RBS podem servir como fonte de documentação.
Reparei num efeito colateral que quase ninguém comentou. Documentação melhor e com tipos é exatamente o que agente de codificação consome pra não alucinar API. Escrever doc decente virou, sem querer, investimento em infraestrutura de IA.
🔗 Release
Performance & Infraestrutura
Kino: os Ractors do Ruby 4 finalmente trabalhando
Yaroslav Markin lançou um web server experimental que coloca os Ractors reformulados do Ruby 4 pra valer. Um front-end em Rust (tokio + hyper) cuida da rede, enquanto Ractors paralelos rodam seu app Rack num único processo, sem fork e sem cópia de memória por worker.
Os números vieram de uma máquina AWS de 8 núcleos: 1,5 a 2x à frente de um cluster Puma em rotas leves de I/O, 34% mais rápido em CPU pura, e 7x menos RAM. Rails ainda não roda em Ractors, mas o fallback com threads já gasta 4x menos memória, e o comando kino --check lista o que no seu app bloqueia o modo Ractor.
Ainda é experimental, vale dizer. Mesmo assim, é a primeira vez que anos de trabalho em Ractors aparecem em número que dá pra olhar.
“Ruby é lento” e o benchmark que desmonta o mantra
Irina Nazarova rodou oito stacks em cinco hosts, medindo custo real. Os achados incomodam os dois lados da briga. Async versus threaded pesa cerca de 10x mais que a escolha da linguagem. O overhead do ActiveRecord é praticamente zero, enquanto Prisma e SQLAlchemy chegam a cortar pela metade a vazão das suas próprias stacks. E Ruby async, via Rage, supera todas as stacks baseadas em ORM, dobrando o NestJS.
Todo time tem aquele colega que aparece na thread de performance pra dizer que o problema é a linguagem. Que Ruby é lento por natureza, que em Go isso rodaria em microssegundos, e que a saída passa por escovar bit: trocar um map por loop manual, reescrever o método em C, economizar alocação de objeto.
Os dados dizem outra coisa. Enquanto ele economiza três milissegundos no laço, o request está parado quatrocentos esperando um I/O bloqueante que ninguém olhou. O ganho nunca esteve no bit. Estava no modelo de concorrência e no ORM, as duas decisões que ele classificou como detalhe de infraestrutura e não quis discutir.
Não estou dizendo que Ruby ganhou a corrida. Estou dizendo que otimizar sem medir é vaidade com syntax highlighting. Antes de trocar de linguagem por performance, abre o log.
O Kamal ganhou uma cara
O Kamal consolidou o deploy sem PaaS como caminho legítimo no Rails 8, mas o custo de adoção sempre foi o mesmo: você troca o git push heroku por abas de terminal, sessões SSH e uma boa dose de confiança no seu próprio YAML.
O Polaris, de Cengiz Gürtusgil, ataca esse atrito. É um app nativo de macOS que coloca uma camada visual por cima do Kamal. Dá pra rodar e re-rodar comandos com output ao vivo, abrir console Rails remoto, inspecionar containers Docker via SSH, enxergar o roteamento e o TLS do kamal-proxy, e transformar log de acesso em métrica de latência e erro. Os rollbacks são conscientes do commit. Custa US$ 29,99 pra até três Macs.
A ressalva é honesta: é pago e, por ora, só roda em macOS. Quem está no Linux ou no WSL segue no terminal, que convenhamos é onde o Kamal sempre funcionou bem.
O que me chamou atenção não foi a ferramenta em si, foi o que ela sinaliza. Quando começam a aparecer camadas de conforto em volta do Kamal, é porque ele saiu da fase “coisa de quem gosta de sofrer” e virou infraestrutura de gente que precisa entregar. Rodar sua aplicação em servidor próprio virou decisão de custo, não mais de ideologia.
E custo, aqui, tem número. O Judoscale migrou um app Ruby de alto tráfego do Heroku pro Render e publicou a conta: o compute caiu, mas o egress fez a fatura final subir. O fundador do Render respondeu publicamente confirmando melhorias a caminho. É o tipo de armadilha que só aparece depois da migração, e reforça o argumento de que trocar de PaaS resolve menos do que parece.
🔗 Polaris · Judoscale on Tour: Render
IA & Desenvolvimento Agêntico
“Pare de promptar agentes. Desenhe loops.”
A frase circulou o mês inteiro. Peter Steinberger e Boris Cherny, criador do Claude Code, chegaram nela de forma independente. Nate Berkopec, mantenedor do Puma, traduziu pro pragmático: pare de ser babá do modelo, construa uma aplicação de IA não-interativa. E Matt Van Horn deu a definição mais limpa que eu vi, um loop é cron com um tomador de decisão no corpo.
Os primitivos já estão embutidos nas ferramentas, e já existe até uma Loop Library com 70 loops prontos, cada um com seus checks e condições de parada.
O detalhe que separa quem entendeu de quem só repetiu a frase bonita: um loop rodando sozinho também erra sozinho. Ele vale exatamente o que valem o feedback e os guardrails dentro dele.
O agente “consertou” os testes flaky numa noite. Levou duas semanas pra virar sustentável.
Esse foi o texto que mais me incomodou na semana, no bom sentido. Fritz Meissner conta como o Opus, no Claude Code, resolveu numa única noite testes Hotwire flaky que se arrastavam havia anos, re-rodando em lotes cada vez maiores até zerar as falhas.
Só que ele enterrou o fix real de cada teste sob sleeps e cruft no-op. Transformar aquilo em algo sustentável exigiu duas semanas de julgamento humano separando correção de coincidência.
A lição não é que IA não funciona. É que o difícil nunca foi fazer o teste passar, e sim entender por que passou.
Por que o agente falha justamente no código bem-feito
Luc Diallo apontou agentes de IA pra dois codebases Rails exemplares, Chatwoot e Solidus, e encontrou um paradoxo bem desconfortável. Os bons padrões (associações polimórficas, concerns, service objects, background jobs, gems modulares) escondem relações que um agente baseado em grep simplesmente não enxerga. No Chatwoot, ele perdeu nove das dependências críticas do model Inbox.
Vira uma regra prática meio contraintuitiva: quanto mais idiomático e desacoplado o seu código, mais contexto explícito o agente precisa receber. ADRs, context docs, skills, ou ferramentas com acesso ao runtime, como o Tidewave Rails Agent, que o Hugo Baraúna acaba de repaginar com demos por ferramenta.
Skills tratadas como código de produção
O time da Justworks conta como passou a versionar, testar e revisar skills do Claude com o mesmo rigor do resto do código, num contexto onde errar custa caro: cálculo de folha de pagamento.
Na mesma linha, Daniela Baron mostra como rodar a skill Rails Audit da Thoughtbot contra um app maduro e transformar o relatório em issues do GitHub priorizadas. E Andrés Coronel ensina a impedir que mudanças de prompt degradem a saída do LLM em produção, com evals que travam o CI.
Os três apontam pro mesmo lugar. Disciplina em volta do agente é o que separa resultado de vibe coding.
🔗 Justworks · Rails Audit · Prompt regression
Contraponto necessário
Duas leituras pra você não sair daqui achando que é tudo festa ou tudo tragédia.
Avdi Grimm, uma das vozes mais ponderadas da comunidade, rebate a tese de que ninguém entrega bom código com IA. Ele diz entregar hoje mais código bem-fatorado e testado do que antes, e credita isso a disciplina: colaboração próxima, review de verdade, padrões, testes. Vibe coding em produção, pra ele, está fora de questão.
Já a Evil Martians puxa o freio no hype de MCP. Boa parte dos servidores MCP sendo escritos por aí resolve um problema que uma API ou CLI decente resolveria melhor.
Comunidade & Ecossistema
Matz abriu a RubyConf com “Extreme Vibe Coding”
A conferência aconteceu de 14 a 16 de julho, em Las Vegas, e a abertura já valeu o ingresso. Yukihiro Matsumoto subiu ao palco pra explicar como ele mesmo trabalha com IA hoje.
Segundo Gary Tou, que estava na plateia, Matz usa Claude Code pra revisar e mergear pull requests em massa, e também como ferramenta de prototipagem, pra iterar rápido. Não teve tom de cautela, nem defesa envergonhada. Foi o criador da linguagem mostrando o próprio fluxo de trabalho.
Mas o que ficou da palestra foram duas frases. A primeira, anotada por Mike Dalton:
“Abra mão das teclas, não da responsabilidade.”
A segunda, que Joe Masilotti chamou de uma das melhores leituras que já ouviu sobre conviver com código gerado por IA:
“O julgamento não escala, então eu o gasto só no que importa.”
A leitura prática do Masilotti é boa: deixe a IA fazer os 90% chatos, revisar, empurrar, mergear, deployar, tudo automático. Nos 10% que exigem julgamento humano, você entra e decide, porque é ali que a visão do projeto se mantém de pé.
E o “extreme” do título não é força de expressão. Irina Nazarova registrou a parte mais reveladora da palestra: quando o modelo diz “não dá pra fazer isso com Ruby”, Matz responde que dá. Só que ele lista o que você precisa ter pra poder responder isso:
testes e benchmarks em que você confia de verdade
conhecimento suficiente pra imaginar o código que deveria existir
coragem de dizer “não, tenta de novo”
coragem de jogar o código fora
Repara que nenhum dos quatro é sobre prompt. Os dois primeiros são infraestrutura e repertório. Os dois últimos são caráter. Bem o oposto do vibe coding que virou meme por aí.
De resto: metade das submissões de CFP deste ano foram sobre IA, os temas oficiais eram “Living with the Robots”, “Beautiful Ruby” e “Weird Ruby”, e no Community Day o Matz dividiu o palco com Jessica Kerr, Obie Fernandez, Dave Thomas, Rich Kilmer, Chad Fowler e Chad Pytel pra discutir pra onde o Ruby vai. Teve também um momento bonito de saudade coletiva, com mais de um participante lembrando publicamente do Jim Weirich.
Os vídeos ainda não saíram. Quando saírem, o keynote do Matz é parada obrigatória.
Dave Thomas: “você não está escrevendo Ruby, está escrevendo C++ com sintaxe Ruby”
Fora de Las Vegas, saiu esta semana o vídeo da keynote de encerramento da RubyConf Áustria, que aconteceu lá em maio. É o Dave Thomas com o argumento que ele vem afiando faz tempo, agora com título afiado também: Start Writing Ruby: Classes Are Evil.
A provocação central é que boa parte do que a gente chama de design orientado a objetos em Rails é herança de outra linguagem. Sua classe de job é, na prática, uma função com cerimônia em volta. E os 834 métodos que o ActiveRecord::Base despeja no seu model não configuram relação “é um” com coisa nenhuma.
Concordar é opcional, claro. Mas repara que ele conversa direto com a série do Brandon Weaver lá em cima. Os dois estão cutucando o mesmo lugar: padrões que a gente repete por hábito, sem nunca ter parado pra justificar.
lobste.rs migrou de MariaDB para SQLite
O agregador de links, que é um app Rails open source que boa parte de nós usa, concluiu depois de anos a migração completa pra SQLite rodando numa instância única.
É o estudo de caso que faltava pra era Rails-on-SQLite. Não é benchmark de laboratório nem post de fundador vendendo simplicidade: é um site com tráfego real que fez a troca e documentou o caminho. Na sequência, o Aaron Patterson publicou como detectar full table scans no SQLite e levantou a pergunta de se isso não deveria virar aviso no próprio Rails.
Somado ao ParadeDB, ao pgvector e ao Extralite, fecha aquele assunto que eu pedi pra você reparar lá em Gems. Dá pra fazer muito mais com o banco que você já tem.
🔗 lobste.rs no SQLite · Detectando full table scans
Shopify entra para a Ruby Alliance
Uma das maiores organizações Ruby do mundo passou a financiar formalmente a infraestrutura crítica da linguagem, via o programa de membros corporativos da Ruby Central. Depois dos meses tensos em torno do financiamento e do RubyGems, é um sinal de estabilidade que a comunidade estava precisando.
🔗 Anúncio
O que os rubyistas ativos estão usando em 2026
Hiroshi Shibata, mantenedor do RubyGems, leu os dados do survey do RubyKaigi. A amostra é enviesada pra quem entrega e mantém código, e é exatamente por isso que ela interessa. Ruby 4.0 já com uso forte, VS Code dominando, e a maioria rodando Claude Code e Docker Compose no dia a dia.
O RubyGems.org, aliás, ganhou repaginada com tema claro e escuro. Nem todo mundo curtiu.
O debate que não vai se resolver tão cedo
DHH publicou que projetos open source erguendo barreiras contra contribuições assistidas por IA estão traindo a missão fundadora do movimento, e chamou as políticas anti-agente de neoludismo, ressentimento disfarçado de princípio. NetBSD, Zig e Flathub estão entre os projetos com regras desse tipo.
Do outro lado do balcão estão os mantenedores que recebem enxurrada de relatório de segurança gerado por IA sem valor nenhum. O próprio Linus reclamou que a lista de segurança do kernel virou quase ingerenciável de tanta duplicata, e o curl encerrou seu programa de recompensas. A dor é real, não dá pra fingir que não é.
Só que o mesmo Linus escolheu o caminho oposto ao do portão. O Linux não é um projeto anti-IA, e quem tiver problema com isso que faça um fork. A régua que ele propõe é rejeitar código ruim por ser ruim, e não por ter nascido de um modelo.
O Daniel destrinchou esse debate por inteiro num artigo. Está logo ali no Destaque, e vale a leitura.
Destaque da Academia do Ruby
O curso de Claude Code está com inscrições abertas
Volta comigo às frases do Matz lá do começo. Abra mão das teclas, não da responsabilidade. O julgamento não escala, então gaste no que importa. A pergunta que sobra pra quem assiste isso de longe é sempre a mesma: como fazer isso na prática, sem entregar o projeto na mão de um agente e torcer pro melhor?
É o que o Claude Code para Devs Rails ensina. O Daniel montou o curso em torno de uma tese que agora tem o aval do criador da linguagem: você instala os guardrails que fazem a IA trabalhar dentro das suas regras, e não por cima delas. São quatro camadas de controle. A postura, em que você é dono do diff. O CLAUDE.md como constituição do projeto. Hooks que barram automaticamente o que não pode passar. E skills e subagents que revisam o código antes de você olhar.
Não é curso de prompt mágico, e os números que sustentam a proposta são bem desconfortáveis. 45% do código gerado por LLM sai com alguma vulnerabilidade do OWASP Top 10, segundo a Veracode. PRs feitos com IA carregam cerca de 1,7x mais issues que os humanos, num levantamento do CodeRabbit com 470 PRs reais. E 5,2% dos pacotes que os modelos sugerem simplesmente não existem, o que abre espaço pra alguém registrar o nome e montar um ataque de supply chain. Modelo maior também não resolve: a taxa de 45% ficou parada do GPT-4 ao GPT-5.
Repara que os pré-requisitos que o Matz listou no palco são quase um índice do curso. Testes em que você confia, repertório pra imaginar o código, coragem pra recusar e jogar fora. O que o guardrail faz é transformar isso em rotina, em vez de depender do heroísmo de quem está no teclado naquele dia.
São 7 módulos, 16 vídeo-aulas e 7 lessons escritas, construindo o Acordeon, um SaaS B2B de gestão de contratos em Rails que você termina com 3 PRs merged, todos passando pelos gates. Você sai com o repositório, as tags m1→m7 pra estudar commit a commit, biblioteca de skills, templates de hooks e 3 subagents configurados.
E se você já é Membro da Academia, o curso já está disponível sem custo adicional.
“Com a IA podem copiar seu código. Mas ser você, não dá.”
Aquele texto do DHH que citei na seção de comunidade rendeu um artigo do Daniel, e ele vai bem além do comentário de rodapé.
O argumento central: banir contribuição feita com IA é um portão cravado no meio do campo aberto. Não segura código ruim, não segura código malicioso, só obriga quem contribui de boa fé a se curvar. A analogia que ele constrói é a melhor parte. Os EUA passaram anos apertando o cerco ao mel chinês, e o esquema respondeu ultrafiltrando o produto pra remover o pólen, que era a única pista da origem. Regra anti-IA faz igual. Quem quer burlar reescreve e entra invisível. Quem é pego é justamente quem declarou o uso. Como o Linus resumiu, quem produz slop não vai carimbar o patch como slop.
E tem a parte que mais me tocou, que é onde ele para de falar dos outros e fala de si. O Daniel conta que mandou um PR pro RubyLLM feito com Claude, testado e com critério. O Carmine Paolino fechou o PR e escreveu uma solução própria, melhor que a dele. Ninguém o acusou de nada. O que valeu ali não foi o código ter entrado, porque não entrou. Foi o caminho: achar um problema real, formular hipótese, testar, submeter, levar um não bem fundamentado e ver nascer coisa melhor por causa disso.
O fecho do texto é o que amarra a edição inteira. Sintaxe e comando decorado são copiáveis e nunca foram seus. O que ninguém clona é o seu julgamento.
E aqui eu preciso registrar uma coincidência, porque ela me deixou pensando. O Daniel escreveu isso sem saber o que o Matz tinha dito no palco em Las Vegas poucos dias antes. E o Matz disse, com outras palavras, exatamente a mesma coisa.
Conselho da Semana
Pediram pra importar um CSV. Um arquivo, formato fixo, 800 linhas, uma única vez. Você entregou um framework: adapters por formato, mapeamento de colunas configurável em YAML, suporte a XLSX e JSON “caso um dia precise”, validação plugável, retry, dry-run e uma classe base abstrata.
Ninguém pediu isso. O script ia rodar uma vez e nunca mais, mas o código genérico ficou no repositório, com testes que alguém mantém e dependências que alguém atualiza. Um dia ele vai quebrar num upgrade do Rails e obrigar um colega a entender uma abstração criada pra casos que nunca existiram. Generalizar sem demanda não é visão de futuro, é adivinhação. E adivinhação cara, porque quem paga é o time inteiro: em code review, em onboarding, em horas debugando uma camada de indireção que não precisava existir.
Escopo é dado, não opinião. Escreve o script burro que resolve este arquivo, deixa explícito que ele é descartável (no nome, na pasta, num comentário dizendo por que existe e quando pode ser apagado) e segue em frente. Se o segundo formato aparecer, e quase nunca aparece, aí você generaliza com informação real na mão. Até lá, resista à tentação de provar competência pela complexidade do que você constrói.
O código mais fácil de manter continua sendo aquele que você não precisou escrever.
Até a próxima!
Ainda não há comentários. Seja o primeiro a comentar!