The Monolith Strikes Back — Why AI Agents Love Rails
Rodrigo Serradura · Tropical on Rails
Vídeo / Video: https://www.youtube.com/watch?v=QFJrEngm3cA

Transcrição automática em português, recuperada do arquivo de fontes do projeto.
Preserva o texto registrado em 4 de outubro de 2026, com seus erros de reconhecimento.
Os tempos localizam blocos de fala e não sincronizam cada palavra.
Este arquivo é uma fonte histórica, não o texto editorial revisado da página.

Automatic Portuguese transcript recovered from the project source archive.
It preserves the text archived on October 4, 2026, including recognition errors.
Timestamps locate speech segments rather than individual words.
This is a historical source, not the edited article.

[00:02] [música] Então vamos lá, galera. Seguinte, por que AI Code Engents amam monolitos rails? Eu sei que a palavra é monólito, mas eu vou falar monolito, beleza? Seguinte, Serradura. Sidão já me anunciou, eh, além de estar trabalhando como principal lá na Welo, agora eu

[00:30] comecei a trabalhar fortemente com AI. Então, quem quiser falar sobre frameworks, como que tá fazendo, tal. Ontem no workshop a gente também falou bastante sobre isso. Ano pass além antes de falar de mim, de Rub e tudo mais, eu gosto sempre de anunciar que eu sou casado com a minha amada esposa Talita, paizão da Bela, da Lulu e agora do Dom. E foi a chegada do Dom que me fez me ausentar por um tempinho, porque, né, dá muito trabalho uma criança pequena em casa. Ano passado, junto de mais três

[01:02] sócios, desenvolvi o Simplo. Se você tá procurando para uma solução de pagamento, de recorrência ou até mesmo parceria em relação a isso, vem falar comigo, porque eu sou um cara de tecnologia que tô aprendendo a fazer negócio. Então, quem tiver interesse, vem conversar. Vamos lá. Pergunta: Rayos é relevante em 2026? Sim ou não? >> Sim. >> Não. Tô brincando. Vamos lá. Ros é relevante paraa codificação com agentes?

[01:30] Sim. >> Errado. Tô brincando. Vamos lá. Seguinte pergunta. Rails. Escala? >> Escala. Escala. Inclusive a gente tem essas métricas bizarras do Shopify e um lucro fenomenal, né? onde a gente vê bilhões de requisições, milhões de requisições, né, por minuto e, enfim, uma escala absurda. Bus escala Ruby é token efficient. A gente não só tem essas métricas aqui, deixa eu vir pro meio do palco, eu não sei, eu deixo ficar aqui. Enfim, não só tem essas

[02:01] métricas e que falam de eficiência, como o TAC que tá aqui também fez no canal dele, ele tava compartilhando comigo. Então, é eficiente. Qual que é o benefício disso? Toquem ao combustível do agente. Quanto menos você use mais longe você vai melhor. Certo? Ah, Y Combinator, que é a maior aceleradora, ela recomenda rails para desenvolvimento de produtos com coding agents. Então, quer fazer um bom vibe coding, vibe engineering, a Y combinator recomenda, tá legal? Qual versatil é o Rails, pô?

[02:33] Rail, você faz web, mobile API, background jobs, enfim, você tem um recurso agora de deploy, upywright, observabilidade, uma série de coisas, ou seja, é muito versátil. E o framework agora tá se posicionando de uma forma sensacional. Antes era do hello world to the IPO, agora é do prompt pro IPO, entendeu? E ele comunica aqui tem tudo que você precisa, né, para você, pros seus agentes. Só faltou

[03:00] agentes, entendeu? Vem, vem, vem com o pai. Faltou falar isso. Vamos lá. Então, Rayos Escala é tokenor recomenda para vibe coding e é versátil. Beleza? Que questões, que perguntas que eu quero trazer aqui para nós. O quão adaptável é o framework? Quanto de complexidade ele é capaz de suportar a nível de design, a nível de organização e por que code vão se beneficiar da arquitetura e da estrutura do R.

[03:31] E outra pergunta, por que que isso importa na era da IA? Por quê? E a resposta é o seguinte: engenharia de software tem a ver com o custo para promover mudanças. E qual que vai ser o principal motor ou combustível para promover mudanças? Alguém pode falar a palavra? Começa com T, começa com T e termina com quens. Isso aí, tokens, vocês são demais. Então o seguinte, a IA ela é uma amplificadora

[04:02] de capacidade. Se a sua base ela é fraca, você vai gerar resultados ruins, tá? O custo para executar tá caindo cada vez mais, o custo para gerenciar subindo cada vez mais, porque é mais importante você definir o que tem que ser feito, o quanto tem que ser feito, aonde tem que ser feito e revisar se o que foi feito é bom do que a execução.

[04:30] Eh, e com isso, domínio dos fundamentos se tornam chave. Então, a sua qualidade vai reverberar na na IA. A sua falta de qualidade também. Beleza. Beleza. Só que o seguinte, cara, a gente tá aqui, né? Quem é que fica falando de arquitetura de software em Ruby Rails, tirando careca lá do Brasil Brasil? Tô brincando. Mas enfim, quão comum é falar desse tema, né, de arquitetura de software em relação a

[05:02] raios. E o ponto é o seguinte, por que que será que isso importa ou não para agentes? Tá bom? Tem a Camila aqui que sempre falou desse assunto, vale mencionar. Então vamos lá. Seguinte, o experimento The Rails Way, né? Eu tô malhando agora, não dá para perceber, mas é isso aí. Seguinte, qual foi o experimento? E esse experimento tá disponível para toda a comunidade. É um presente. Fiquei ausente aí um ano e

[05:31] pouquinho. Tô voltando com tudo. Qual que é o experimento? Eu criei uma aplicação, um repositório, onde tem a mesma aplicação implementada de 28 formas diferentes, beleza? E ela explica passo a passo, basicamente, qual que é a o tradeoff e os benefícios, não só para os humanos, mas principalmente para os agentes, qual que é o custo de cada decisão, tá bom?

[06:02] Então, dentro de cada rm você vai ter o conceito, números, evidências, a perspectiva do agente e o próximo passo, tá? Então esse repositório ele vai abrir e ele vai servir de base, porque teve uma coisa que eu fiz bem legal junto do cloud, que foi criar um IVAL, um critério de avaliação do porquero, codebase ele pode ser mais ou menos amigável para coding agents, tá bom? Esse estudo também está disponível

[06:31] dentro desse repositório. Então vamos lá. Assunto importante. Quando a gente fala de a e de codificação, agora vou mais pro meio, tô ficando mais empolgado. A gente precisa falar de progressive disclosure, que significa o quê? A capacidade de descobrir ou utilizar algo sob demanda, tá bom? Só que esse tema ele não se aplica apenas para agentes, ele se aplica para diferentes assuntos. Quando a gente fala de Ox design, é a capacidade de você

[07:01] revelar apenas o que é necessário e relevante. Quando a gente fala de carga cognitiva, é você reter, prestar atenção apenas no que importa. Quando a gente fala de arquitetura de software, a gente tá falando de modularização e separação de responsabilidades. Ou seja, você deveria ser capaz de entender as coisas de maneira isolada, tá certo? Humano tem memória limitada e a gente contexto, beleza? E nessa aplicação a gente consegue ver

[07:32] vários princípios importantes. O primeiro deles, ortogonalidade. Quem aí fez meu curso? Que é, [risadas] vou perguntar para o que que é ortogonalidade. Ortogonalidade é a capacidade de você modificar algo sem comprometer outra coisa que não tem uma associação direta. Exemplo simples disso. Se você tem um controller, como é o caso da primeira versão desse repositório, que tem mais de 200 linhas e muita responsabilidade, às vezes o teu

[08:01] agente precisa alterar 10 linhas e pode ser que ele altere alguma coisa errada. E isso gere um um comportamento indesejado. Se você tem controllers específicos, a chance de isso acontecer e afetar algo que não estava diretamente associado se reduz. Então, quanto mais ortogonal, maior o controle sobre o comportamento, né, sobre as mudanças que vão acontecer no seu sistema, tá? Isso se aplica em

[08:30] diferentes níveis. Pode ser, desse exemplo simples a nível de de uma classe, como pode ser ah em níveis mais altos, como por exemplo, componentes, serviços e por aí vai. Beleza? Eh, um outro ponto importante, porque o tema dessa palestra é porque agentes amam monolit raus, porque o fato de você ter toda a sua aplicação em um único codebase facilita a compreensão. Afinal, o que o agente não pode raciocinar sobre aquilo que ele não pode ver, né? Ele não

[09:02] vê, enfim. Beleza? Agora, quando você tem uma solução distribuída, isso fica mais difícil. Você poderia falar: "Pô, Serra, eu posso ter um monoripo, mas não deixa de ser o fato de que a complexidade ela aumenta, tá? Tá, mas a gente pode falar, tá, Serra, se monolito é bala de prata, por que que o meu é tão ruim, né? Daí, beleza, faltou comprar meu curso.

[09:31] Tô brincando. Vamos lá. Por que que ele é pode ser tão ruim? Por que que ele pode ser tão bom?" E aqui a gente tem dois exemplos onde aquele score que eu eh comentei com vocês, ele foi aplicado e na primeira versão a gente tem um score de 10. Na segunda versão a gente tem o que quase bate a o score máximo de 25. E quais são os critérios para esse score? O primeiro dele é o custo da janela de contexto, tá? Quanta informação precisa ser carregada a fim do agente conseguir tomar uma decisão,

[10:01] conseguir compreender para então tomar uma ação? O segundo é a capacidade de descobrimento, tá? Então, um nome, ele está no lugar certo, a estrutura a qual ele está localizado eh faz sentido ou não, tá? O quão isolado ele tá. Então, o fato de eu ter componentes coesos, bem nomeados, bem localizados, eles facilitam o quê? A compreensão e consequentemente a promoção de mudanças. O quão

[10:31] previsível é esse código, que que acontece? Às vezes você tem um code base, uma parte dele que tá linda e todo o resto não. Daí o que acontece? Ou a gente, às vezes ele vai falar: "Opa, tava mexendo em A". Na hora que ele vai em B, ele simplesmente se perde por não tem uma palavrinha. Vamos lá, quero ver quem vai descobrir, hein? Vai ganhar um prêmio. É uma palavra, é um termo, desculpa, do livro The Myical Manh. Quando isso acontece, está faltando o

[11:01] quê? Coesão. Alguém falou coesão. By the way, coesão. Eu quero outra pergunta. Minha tá horrível. Minha O que está faltando? integridade conceitual, tá? É melhor você ter um Code base majoritariamente ruim em termos de práticas, mas ele é totalmente ruim do que você ter ele parcialmente bom, entendeu? Porque isso dificulta a compreensão, tá? Ah, então ter consistência faz diferença,

[11:32] tá? Então enfim, vocês entenderam a ideia. E o último item, basicamente, quantos arquivos precisam ser modificados quando algo precisa ser alterado, tá? Então beleza, sumiu. Era para ter um gráfico aqui, tá bom? O mais importante é o seguinte, onde tá aquele alvo? Deveria ter um gráfico que ele chega ali na linha do 24, tá? E era para mostrar

[12:00] um um desenhinho aqui. Beleza? O mais, acreditem em mim, tem um gráfico aqui, tá? >> [risadas] >> Mas dentro dessas 28 versões, a gente percebe que tem essa família seis, ela tem o melhor tradeoff entre todos para uma aplicação rayos. E a gente vai entender o motivo disso, tá? E o que faz essa família ser a melhor de todas é que primeiro ela tem um vocabulário unificado. Os nomes fazem sentidos nas views, nos controllers, nos models. Eh,

[12:31] o resource, se der tempo, eu vou abrir aqui. Você vê as rotas, você chora de tão lindo que aquilo lá, entendeu? É bem descrito, só usa DSL, dá um calorzinho no coração. É lindo. E daí você fala: "Pô, Serra, por que que uma boa rota bem nomeada faz diferença?" porque ela reflete que o seu domínio tá bem desenhado, tá? Então, quando você tem muita rota customizada, isso é um smell de que alguma coisa tá faltando ou muita coisa tá faltando. E um item que pode

[13:00] ser por alguns ou não eh controverso é você priorizar ações e operações de maneira mais explícita do que implícita. Exemplo, imagina que um agente tá passando por um controller e ele vê um objeto ponto save, ele vai ver aquele save, ele vai entender que talvez seja um active record, mas ele não consegue inferir se houve um envio de e-mail, se um outro

[13:30] registro foi criado, ele não consegue. Agora, se existe uma classe que faz algo, por exemplo, ali um user registration, tá? e ele vê essa classe, ele entra naquela classe, ele vê que, opa, tá salvando e também fazendo outras coisas, é muito mais fácil do agente localizar e consequentemente entender e com isso tomar a decisão do quanto ou não agir. Fez sentido? Então, no frigiro dos ovos é bons nomes, a disciplina de

[14:00] como você organiza o seu código e, por último, o cuidado em tornar as suas operações explícitas, tá? Era para ter outro gráfico aqui. E daí nesse gráfico, qual que era o paralelo? Qual versão exige mais ou menos instruções no seu agents MD ou no seu cloud MD? E a gente vai perceber que a família seis é a que menos exige, porque ela é a mais h

[14:30] ela é a mais intuitiva, tanto para humanos quanto para agentes. E essa família se ela segue a cartilha da 37 signals, tá? Então assim, se você entrar no fizley ou você entrar nesse code base, você vai ter dezenas de passos que vão te levar para aquela cartilha. E isso é muito bom, porque a gente tem só algo eh que, vamos dizer assim, valida uma forma de trabalhar o Code base, como também tem muita informação empírica

[15:00] aqui pra gente poder chegar pro nosso time e falar por fazer A melhor que B, quais são os tradeoffs, tá? Beleza? Vamos trazer alguns exemplos práticos. Quando o código passa a ser a documentação, a gente tem do lado esquerdo a primeira versão, os controllers. Do lado direito, a gente tem o que seria a 6G, que é o ápice dessa família de implementações. Do lado do controller, a gente consegue ver ali, ó, aqui a gente tá em users. Eu

[15:32] sei que existe users, eu não tenho ideia se existe notificações. Percebem? Conseguem ver? De um lado do controller, eu tenho ali, ó, web notification. [limpando a garganta] Eh, desculpa, web. notification. Tá falt. Ué, cadê o user aqui? Tá. É, mas tá faltando, eu não sei por, mas sumiu.

[16:01] Era para ter, era para eh talvez foi do VS Code na hora de fazer o print, mas era para ter a pastinha controllers, web, user, notification, tudo isso aqui tá aninhado dentro do namespace de user. Eh, e basicamente é porque o web notification tá péssimo, mas tem o user ali, eu posso provar para vocês, tá bom? O fato é aqui, o fato de você saber que algo está em user notification, isso revela qual que é a capacidade desse sistema, tá? Você não precisa de um

[16:31] manual para saber que existe a notificação, porque a estrutura de arquivos ela revela que essa intenção e esse comportamento existe, tá? O mesmo se aplica pros models, por de um lado eu tenho só os models. De outro quando eu olho a user aqui agora apareceu. Beleza. Aqui eu tenho algo que me fala que tem, né, um o, por exemplo, a notificação, ela tá dentro do nome do namespace de user. Ali eu só tenho notificação. Não tem nada que me dê um hint de que olha,

[17:01] a notificação belongs to user. Já aqui eu tenho uma correlação, uma clareza, né? Isso é um princípio que a gente chama muito, que é o common clure closure princip. Aquilo que faz sentido estar perto, fica perto, tá? Então, se eu tenho essas entidades que elas estão correlacionadas, elas deveriam ficar próximas, tá? E isso tem um valor semântico, tá? Enfim, então quando você trabalha no

[17:30] monolito, além de ter esses elementos, localizar algo para modificar, tá tudo dentro de um mesmo code base. O mesmo não se aplica quando você tem sistemas distribuídos. E quando a gente fala de progressive disclosure, isso não se aplica só a nível de código. Você também pode ter, se você tem pastas, nem uma boa organização, ter cloudis ou outras instruções por pastas, por níveis. Isso também ajuda na descoberta. Você pode ter skills que vão mapear algum conceito

[18:01] específico para suportar a decisão do agente. Então assim, se você, isso é um smell bem interessante, se o teu código não tá bom, provavelmente você tem muita instrução, entendeu? E você vai tá gastando mais token do que você deveria. Hoje quando a gente olha para ecosistema Rails, você tem uma fundação absurdamente boa. Quando a gente fala de ferramental, Rubocop, o Packwork, quando você começa a ter aplicações, você precisa delimitar

[18:30] melhor as fronteiras dentro de um codebase mais complexo. Sorb, hoje em dia, eu vejo uma adoção cada vez mais, uma escolha por linguagens tipadas por conta do rápido feedback que isso pode prover para o agente. E quando a gente fala da ah da integração com ferramentas agênticas, eu quero citar o HLSP, que se tornou um plugin oficial do cloud, ou seja, o fato do LSP indexar o teu Codebase, agora esse essa informação também passa a ser disponível pro seu

[19:01] agente. Se esse código for bem nomeado, bem organizado, bem localizado, vai eh inclusive potencializar o próprio agente. uma outra ferramenta criada por um brasileiro que é o José Valinho, Tide Wave, quem é que usa? Poucas pessoas, vocês estão perdendo a oportunidade de algo excelente. Testem o Tide Wave, tá? Porque ele te dá informação em run time do que está acontecendo na sua aplicação, tá? Além

[19:31] de várias community skills e dela eu quero citar a do Palcan, do Vladimir, que fala de arquitetura, várias práticas, não sei se ele tá aqui, que vale a pena também você conferir, se inspirar e utilizar, tá? Seguinte, naquele repositório ele para na família 7 num ponto e ela tem um score baixo, mas tem um arquivo lá que ele mostra um PEF de como iria evoluir. E esse arquivo basicamente é a minha promessa que eu vou implementar

[20:01] mais sete versões nesse repositório, tá? E tem documentação que aborda tudo isso lá. Tá bom? Então o seguinte, o que todo mundo quer basicamente é reduzir o número de deployments e maximizar a modulariz a modularização, tá bom? Esse é o objetivo que todo mundo quer. E aquela família seis, o jeito da turn signals de codificar o código, onde você usa bons nameces, faz uma separação

[20:30] eh boa, né, do teu código, mesmo tudo no mesmo banco de dados e tudo mais, ela te deixa pronta para um próximo passo, se for necessário, tá? E é isso que esse code base que eu fiz, ele apresenta. Ele mostra que quando você chega naquele estágio, dar o próximo passo se torna possível. Agora, se você não está nesse estágio, vai ser, não vou falar impossível, mas eh inviável, eu acredito eu, eh você conseguir realmente isolar.

[21:01] Nessa aplicação que eu fiz de exemplo, só para vocês entenderem, tem um momento onde os principais domínios eles não têm mais um has many belongs to. daí eu preciso usar uma chave fraca para associá-los, blá blá blá, mas o fato de fazer isso permite que agora eu tenha um banco de dados por domínio. Isso traz uma série de outros problemas. O ponto principal que eu quero trazer para vocês é que sem uma boa organização é impossível adquirir uma real modularização, tá? Existe um preço a ser

[21:32] pago. Então, os principais TKWs são: valorize os nomes, tá? tenha um vocabulário unificado. Muita gente aqui vai associar com certos conceitos de uma palavra que começa com D. Eu não vou falar, né? Eu não vou falar dos 3Ds. Tô brincando. Mas a gente deveria valorizar o quê? A maneira como eu dou bons nomes, tá? E de preferência nomes que façam relação com

[22:01] o negócio, com o domínio da sua aplicação, tá? Você também deveria se preocupar em como que você eh lida com a complexidade dentro desses objetos. Então você deu um bom nome, mas se você não garante que o comportamento correto está dentro deles, isso vai fazer com que você também não tenha uma boa representação. Aqui eu tô falando de Teldon ESC, eu tô falando, sabe, de fazer um um bom encapsulamento

[22:30] em como você trabalhar composição. Enfim, ao ter bons nomes e ao começar a isolar as coisas, você vai começar a perceber que se eu tenho muito, significa que eu preciso abstrair parte do meu comportamento. Isso deveria começar a criar um ecossistema que passa a representar um conceito. E a gente tá falando de como que a gente trabalha basicamente essa orquestração de complexidade que cai no item três, que é valorize objetos de domínio. Valorize objetos que trabalhem de maneira

[23:00] colaborativa para resolver algum tipo de problema mais específico, tá? e elimine a sobreescritas de rota, porque isso é um smell que o que atua. Porque quando a gente trabalha com aplicação Rails, majoritariamente a gente tá representando uma aplicação web ou uma IPI, algo desse tipo. E se o teu resource tá bagunçado, é porque esse core da aplicação, que é como, né, esse mecanismo de entrega deve est bem

[23:31] comprometido. Então, uma boa arquitetura, ela é premissa para um bom progressive disclosure, tá? Para qualquer operador. Por que que eu estou usando a palavra operador? porque ela pode ser utilizada para um operador humano ou um operador agêntico, tá? Então assim, se você não tem um bom, uma boa arquitetura, se você não tem bons isolamentos, se você não tem bons nomes, você vai compensar em documentação,

[24:00] tá? É isso. Esse é o tradeoff. Então, se for simples de encontrar e simples de entender, será simples de manter e evoluir. Então, essa esse requisito, essa constraint de memória limitada e janela de contexto, ela muda, porque pra gente é a janela de contexto, pro humano é a memória, mas o princípio ele é o mesmo, tá? Então, voltar às perguntas. Rayos é relevante? Vamos, gente. Relevante.

[24:32] Raz é relevante para coda, >> é token >> mais alto. Faz sentido com agents? >> É versátil? >> Então, beleza. Railway. Beleza. Compre mais próximo de você. Então, quem ficou interessado porque eu falei muito, né, e eu gosto muito de uma

[25:02] de uma de uma frase do Linus Torvolds que fala: "Talk is chip, show me the code." Tem muito código aqui. Eu mesmo levei 3 horas só para ler os readms que eu escrevi junto da IA, tá? E eu levei 13 horas só para revisar todo esse conteúdo. Foram 13 horas consecutivas na terça-feira para garantir que isso tivesse bem, sabe, estruturado para vocês. Eh, então tudo que eu falei vocês

[25:32] podem me cobrar e provar dentro desse repositório, tá bom? Eh, então por que agora? Porque se a tua capacidade ela for baixa, a sua capacidade de extrair da IA também será baixa. Ela pode compensar porque você pode usar skill de alguém, você pode usar prompts prontos, mas em algum momento quando você perceber que quem é que está no domínio é a IA ou

[26:00] é você. Então, o meu ponto que eu quero trazer essa essa questão de que o ferramental tá muito bom e se os seus fundamentos não estiverem, você está limitando aquilo que você seria capaz de fazer com eles, tá bom? Não seja o limite, não seja o limitador, seja o potencializador, tá bom? E é isso.