Rails, fundamentos e IA para fazer acontecer.
Da interface ao deploy, Rails reúne recursos para construir um produto. Veja como convenções, modularidade e feedback ajudam agentes a encontrar contexto e você a conduzir as decisões.
Escolher um capítulo- IAAmplia sua capacidadeExplore, implemente e revise com agentes.
- RailsDá estrutura ao produtoConvenções e recursos que trabalham juntos.
- FundamentosDão direção às decisõesEntenda o problema e reconheça uma boa solução.
Fundamentos, Rails e IA se combinam para ampliar o que você consegue realizar.
Assistir à palestra26:28
Palestra em português no Tropical on Rails.
Uma base que já carrega muito do trabalho.
Web, mobile nativo, APIs e agentes podem acessar o mesmo produto. Rails e seu ecossistema conectam essas interfaces a dados, comunicação, deploy e observabilidade.
Interfaces para pessoas, sistemas e agentes
-
Web e PWA
Interfaces com Hotwire e recursos para levar a aplicação do navegador à tela inicial.
-
Mobile nativo
Apps para iOS e Android com Hotwire Native, combinando telas web e navegação nativa.
-
APIs e integrações
REST com Rails, GraphQL e gRPC com bibliotecas Ruby para conectar outros sistemas.
-
Agentes via MCP
Ferramentas e recursos do seu produto acessíveis a agentes pelo SDK oficial para Ruby.
Uma base para o produto
- Dados com Active Record
- Persistência, consultas e recursos para trabalhar com múltiplos bancos.
- Jobs com Solid Queue
- Trabalho em background apoiado no banco de dados.
- Cache com Solid Cache
- Uma opção de cache persistido em banco para sua aplicação.
- Arquivos com Active Storage
- Uploads e acesso a arquivos ligados aos dados do produto.
Comunicação e infraestrutura
- Tempo real com Action Cable
- Comunicação via WebSockets integrada à aplicação Rails.
- E-mail com Action Mailer
- Mensagens que participam dos fluxos e eventos do produto.
- Deploy com Kamal
- Publicação de aplicações em containers nos seus servidores.
- Observabilidade com Upright
- Verifica disponibilidade e fluxos de uso, com métricas Prometheus e traces OpenTelemetry.
Interfaces para pessoas, sistemas e agentes
Web e PWA
Mobile nativo
Apps para iOS e Android com Hotwire Native, combinando telas web e navegação nativa.
APIs e integrações
Agentes via MCP
Uma base para o produto
- Dados com Active Record
- Persistência, consultas e recursos para trabalhar com múltiplos bancos.
- Jobs com Solid Queue
- Trabalho em background apoiado no banco de dados.
- Cache com Solid Cache
- Uma opção de cache persistido em banco para sua aplicação.
- Arquivos com Active Storage
- Uploads e acesso a arquivos ligados aos dados do produto.
Comunicação e infraestrutura
- Tempo real com Action Cable
- Comunicação via WebSockets integrada à aplicação Rails.
- E-mail com Action Mailer
- Mensagens que participam dos fluxos e eventos do produto.
- Deploy com Kamal
- Publicação de aplicações em containers nos seus servidores.
- Observabilidade com Upright
- Verifica disponibilidade e fluxos de uso, com métricas Prometheus e traces OpenTelemetry.
Da interface à operação, um ecossistema para construir e sustentar o produto. Escolha as peças que seu contexto pede.
O que Rails oferece além de páginas e CRUD?
Rails reúne interfaces web, recursos para PWA, APIs REST, dados, arquivos, e-mail e trabalho em background. Hotwire Native leva os fluxos do produto a apps para iOS e Android. Bibliotecas e SDKs Ruby ampliam essa base com GraphQL, gRPC e MCP. Na infraestrutura, Kamal cuida do deploy e Upright oferece monitoramento sintético e integração com métricas e traces. São caminhos conectados para construir, distribuir e acompanhar o mesmo produto.
Por que ter essas peças integradas faz diferença?
Uma solicitação de produto costuma atravessar várias partes da aplicação. Convenções compartilhadas ajudam a conectar interface, regras, persistência e trabalho em background. Pessoas e agentes encontram caminhos recorrentes para realizar essas tarefas. Isso permite investir mais atenção no comportamento do produto e nas decisões que são próprias do seu negócio.
Preciso usar tudo que o ecossistema oferece?
Você escolhe os recursos de acordo com o problema. Uma aplicação pode começar com poucos componentes e incorporar outros quando surgir uma necessidade concreta. Entender o papel de cada ferramenta ajuda a avaliar suas configurações, dependências e custos de operação. A amplitude do ecossistema oferece opções para crescer com critério.
Espaço para crescer. Critério para evoluir.
Shopify mostra a escala que uma base Rails pode alcançar. Chegar lá envolve engenharia, observação e decisões que acompanham o negócio. Crescer também significa lidar com novas regras, dados e pessoas.
- Tráfego
- Onde o volume de uso encontra um gargalo?
- Dados
- Como consultas, volume e consistência afetam o produto?
- Domínio
- As regras ainda têm um lugar claro no código?
- Equipes
- Que mudanças exigem coordenação entre pessoas?
Rails escala?
Shopify é um caso concreto de Rails em grande escala. Sua trajetória mostra como o framework pode participar de um produto com grande volume de uso e complexidade. Essa capacidade vem acompanhada de trabalho em infraestrutura, dados, observabilidade e organização do código. O caso amplia o horizonte de quem começa e oferece decisões reais para estudar.
Preciso começar com microservices para poder crescer?
Um monólito pode crescer e desenvolver fronteiras internas claras. Separar serviços introduz contratos, comunicação e coordenação entre partes. Esses custos podem valer a pena quando há necessidades de isolamento, autonomia ou operação. A arquitetura deve responder às pressões que você observa no produto, com uma razão concreta para cada separação.
Como saber o que precisa evoluir?
Identifique a pressão que está aumentando. Um gargalo de consultas pede uma investigação diferente de conflitos entre equipes ou regras de negócio espalhadas. Observe uso, falhas e custo de mudança. Essas evidências ajudam a escolher entre otimizar uma operação, reorganizar o domínio, ampliar a infraestrutura ou separar uma responsabilidade.
Convenções dão contexto. Você dá direção.
Nomes, estruturas recorrentes e recursos conhecidos ajudam um agente a encontrar o caminho. O valor dessa base aparece quando ela se conecta a um objetivo claro e à verificação do resultado.
UX
Progressive disclosureMostrar o que é relevante em cada momento.
Carga cognitiva
Atenção e memóriaTrabalhar com a informação que precisa caber na mente.
Arquitetura
ModularidadeEncontrar, compreender e mudar cada parte.
Contexto na medida da tarefa.
Pessoas têm limites de atenção e memória. Agentes trabalham com uma janela de contexto. Organizar o acesso à informação ajuda os dois.
Por que as convenções do Rails ajudam agentes?
Convenções tornam partes do sistema previsíveis. Um nome sugere onde procurar; uma rota aponta para um recurso; um padrão conhecido ajuda a entender uma área nova. O agente pode usar esses sinais para navegar pelo código. Quando a aplicação conserva essa coerência, a intenção fica mais fácil de encontrar e relacionar ao comportamento.
Por que Garry Tan destacou Rails para construir com IA?
Garry Tan, da Y Combinator, elogiou publicamente a combinação de Rails com Claude Code. Em sua publicação, associa a expressividade do framework à produção de código por modelos de linguagem. A observação oferece um ponto de partida para investigar como a linguagem e o ecossistema podem ajudar no trabalho com agentes.
Ruby usa menos tokens?
A expressividade de Ruby permite representar ideias com pouco ruído, e a palestra apresenta estudos sobre eficiência de tokens. O custo de uma tarefa também depende do contexto carregado, das buscas e das tentativas necessárias. Avalie o percurso completo: encontrar o comportamento, entender a mudança, implementá-la e verificar se ela resolveu o problema.
Saber Rails basta para entregar uma feature?
Conhecer o framework ajuda a escrever e localizar código. Entregar uma feature exige também compreender o produto, respeitar restrições e verificar o comportamento esperado. Os estudos do Agents on Rails distinguem conhecimento do framework e implementação de features. Essa diferença ajuda a escolher o que pedir ao agente e como avaliar sua entrega.
A arquitetura aparece no custo da próxima mudança.
Encontrar, entender, modificar e verificar fazem parte do trabalho. A organização do código influencia cada etapa, tanto para uma pessoa quanto para um agente.
Ver progressive disclosure e arquitetura na palestraModularidade
Monólito modular
Limites claros em uma unidade de deploy.
Microservices
Limites claros e coordenação entre serviços.
Monólito emaranhado
Responsabilidades misturadas no mesmo deploy.
Sistema distribuído emaranhado
Responsabilidades misturadas e coordenação distribuída.
Unidades de deploy
Uma unidade de deploy
Monólito modular
Limites claros em uma unidade de deploy.
Monólito emaranhado
Responsabilidades misturadas no mesmo deploy.
Vários serviços
Microservices
Limites claros e coordenação entre serviços.
Sistema distribuído emaranhado
Responsabilidades misturadas e coordenação distribuída.
Distribuir o código muda a operação. A modularidade depende de como você define responsabilidades e relações.
- A tarefa começa no código.Codebase
Nomes e organização revelam os conceitos.
- Quando o código não explica tudo.Projeto
AGENTS.md e CLAUDE.md guardam decisões e restrições locais.
- Quando o padrão se repete entre projetos.Ecossistema
Skills reúnem conhecimento reutilizável para uma necessidade.
Conhecimento sob demanda, em cada nível.
O código mostra seus conceitos. As instruções explicam o contexto do projeto. As skills acrescentam repertório para a tarefa.
Por que arquitetura importa quando a IA escreve o código?
A IA amplia sua capacidade de executar mudanças. O sistema ainda precisa indicar onde agir, quais regras preservar e que consequências verificar. Responsabilidades misturadas e padrões conflitantes aumentam esse esforço. Uma arquitetura compreensível ajuda você a orientar o trabalho e avaliar se a mudança preserva o comportamento que o produto precisa.
O que é progressive disclosure no código?
É revelar o que a tarefa precisa e permitir acesso ao detalhe quando ele se torna relevante. Um bom nome aponta para um conceito. Esse conceito mostra seu comportamento e suas dependências. Assim, pessoas e agentes podem aprofundar a leitura conforme a necessidade, com um caminho claro entre a pergunta e a parte do sistema que responde.
O que um monólito oferece para esse trabalho?
Um codebase reunido facilita seguir relações, encontrar contratos e alterar referências em conjunto. Uma mudança pode ser testada e entregue como uma unidade. Essa proximidade ajuda a investigar o comportamento completo. O benefício depende também de nomes, limites e responsabilidades que tornem o código compreensível ao longo do percurso.
Modularidade depende de separar o deploy?
Modularidade nasce de responsabilidades e relações bem definidas. Você pode criar fronteiras dentro de uma aplicação e manter um único deploy. Separar a operação é outra decisão, com benefícios e custos próprios. Coesão e baixo acoplamento ajudam a mudar uma parte com atenção proporcional ao problema, qualquer que seja a topologia escolhida.
A mesma aplicação torna as escolhas comparáveis.
O Rails Whey App coloca essa investigação no código. Você pode examinar o que muda quando uma responsabilidade ganha nome, quando uma operação fica explícita e quando novas fronteiras entram em cena.
Adicionar fronteiras pode melhorar o isolamento e aumentar o esforço para compreender e alterar o sistema. As versões tornam esse tradeoff visível no código.
As notas seguem os critérios do estudo para este app e as tarefas analisadas. A rubrica descreve a estrutura do código; desempenho e consumo de tokens exigem testes separados. Compare os detalhes de cada versão no Gradiente. Ler o relatório de Agent-Friendliness
Facilidade para agentes (0–25)
-
Ponto de partida1A
10/25 -
Maior nota do estudo6G
24/25 -
Última versão7D
19/25
Ver as 28 notas
-
1A
10/25
-
1B
15/25
-
2A
17/25
-
2B
19/25
-
3A
14/25
-
3B
15/25
-
3C
16/25
-
3D
17/25
-
3E
16/25
-
3F
20/25
-
3G
21/25
-
4A
14/25
-
4B
18/25
-
5A
17/25
-
5B
18/25
-
5C
21/25
-
5D
23/25
-
6A
19/25
-
6B
22/25
-
6C
19/25
-
6D
21/25
-
6E
22/25
-
6F
19/25
-
6G
24/25
-
7A
19/25
-
7B
19/25
-
7C
17/25
-
7D
19/25
Um vocabulário entre as camadas
O mesmo conceito pode ser reconhecido nas rotas, nos controllers, nos models e nas views.
5C-unified-vocabularyUma responsabilidade declarada
A regra encontra um lugar no model que responde pelos dados e pelo comportamento.
5D-model-authorityOrquestrações com nome
Operações que coordenam passos ganham um conceito que pode ser encontrado e revisado.
6G-named-orchestrationsRecursos que orientam as rotas
Nomes e recursos consistentes aproximam o domínio das convenções do Rails.
3F-resource-disciplineO que a avaliação de Agent-Friendliness observa?
O estudo considera custo de contexto, descoberta, isolamento, previsibilidade e alcance da mudança. Esses critérios ajudam a examinar como cada versão organiza o trabalho para um agente. As notas descrevem o app e as tarefas analisadas. Os exemplos, arquivos e decisões permitem investigar o resultado e formar seu próprio julgamento.
Que mudanças práticas se destacam no experimento?
Unificar o vocabulário conecta as camadas da aplicação. Declarar a responsabilidade pelas regras dá um endereço às decisões. Nomear orquestrações torna os passos de uma operação visíveis. Organizar os recursos reduz exceções nas rotas. Você pode acompanhar essas mudanças nas branches, ler seus motivos e comparar as consequências no código.
Mais estrutura sempre melhora o trabalho do agente?
Estrutura pode trazer isolamento e também criar novos caminhos de busca, contratos e regras de coordenação. O experimento mostra esse tradeoff: o aumento de sofisticação não produz uma melhora contínua em Agent-Friendliness. A escolha precisa considerar a necessidade que a fronteira atende e o esforço que ela acrescenta para compreender e mudar o sistema.
Quanto precisa entrar nas instruções para o agente?
Instruções registram decisões, restrições e caminhos que o código sozinho não explica. Nomes e responsabilidades claros reduzem a orientação necessária para compensar uma estrutura confusa. Use a documentação para preservar o contexto importante e ajudar na descoberta. O código também deve comunicar seus conceitos e tornar visível onde cada comportamento acontece.
Ferramentas transformam critérios em feedback.
O ecossistema também ajuda a observar, investigar e verificar. Cada ferramenta responde a uma pergunta diferente sobre o trabalho que pessoas e agentes realizam.
Ver as ferramentas apresentadas na palestraBase estática
Estilo, fronteiras e contratos que podem ser verificados no código.
Feedback para orientar a próxima decisão
RuboCop, Packwerk e Sorbet ajudam a verificar o código. Ruby LSP e Tidewave ampliam o contexto disponível para investigá-lo.
Como avaliar o código que o agente produziu?
Comece pelo comportamento esperado e pelas consequências da mudança. Testes, linters e análise de código ajudam a transformar parte desses critérios em verificações repetíveis. Leia os resultados e examine o que eles cobrem. A revisão conecta esses sinais ao objetivo da tarefa, às regras do produto e aos riscos que ainda precisam de atenção.
Como o agente pode investigar além dos arquivos?
Indexação de código ajuda a localizar símbolos e relações. Integrações com a aplicação em execução podem oferecer contexto sobre dados, comportamento e erros. A palestra apresenta LSP e Tidewave como caminhos para aproximar essas informações do agente. Esse feedback complementa a leitura do código e ajuda a investigar hipóteses durante uma mudança.
Como escolher o ferramental adequado?
Parta da pergunta que você precisa responder. Consistência de código, contratos de tipos, fronteiras e comportamento em execução pedem verificações diferentes. Use o que já ajuda no projeto e amplie conforme surgirem necessidades. Uma ferramenta tem valor quando seu feedback orienta uma decisão e contribui para verificar o resultado que você pretende entregar.
Ser maker é fazer acontecer.
Escolha com critério, construa com as ferramentas disponíveis e use IA para ir além.
Fundamentos dão direção. A IA amplia sua capacidade de fazer acontecer.
Seja dev ou vibe coder, desenvolver critério ajuda você a orientar agentes, avaliar entregas e continuar evoluindo o que constrói.
Esta reflexão sobre makers, resultados e reescrita amplia a tese da palestra. Foi acrescentada pelo autor depois da apresentação.
Um app mais rápido é sempre um produto melhor?
Performance tem valor quando atende uma necessidade real. Um produto também precisa resolver problemas, alcançar pessoas e continuar viável para mudar. Uma arquitetura confusa pode tornar cada evolução mais cara, mesmo com agentes. O maker considera esse conjunto para decidir onde investir e como avaliar o que melhorou.
Uma reescrita significa que Rails falhou?
Uma aplicação em uso acumula regras, casos reais e entendimento do negócio. Uma necessidade específica pode justificar outra implementação, apoiada nessa experiência. O código, os testes e o comportamento existente oferecem uma referência para a mudança. Na visão do Serradura, essa continuidade pode fazer parte de uma trajetória que deu certo.
Como o caso do HEY se conecta a essa visão?
DHH anunciou uma reconstrução do back end do HEY em Rust com agentes. Serradura vê nesse relato o valor do conhecimento acumulado na aplicação Rails. Um produto compreendido oferece uma referência funcional para avaliar outra implementação. Essa leitura trata da capacidade de decidir e evoluir; o anúncio não estabelece, por si só, uma migração em produção.
Isso vale para devs e vibe coders?
Quem programa pode usar sua experiência para orientar e revisar agentes. Quem começou construindo com IA pode desenvolver repertório para reconhecer limites, formular perguntas e avaliar entregas. A profundidade técnica varia com o contexto. Ambos podem ampliar seus resultados com os fundamentos necessários para conduzir o trabalho e entender suas consequências.
O que significa fazer acontecer com fundamento?
Significa usar os recursos disponíveis para resolver um problema, observar o resultado e aprender o que o próximo passo exige. Você decide o que precisa ser feito e verifica o que foi entregue. A IA amplia essa capacidade. O Rails Whey compartilha código, ideias e conversa para você desenvolver seu próprio critério.
A palestra e as fontes desta leitura
O vídeo e os slides registram a apresentação original. As fontes do ecossistema apoiam esta leitura, e a reflexão posterior de Serradura está identificada na seção sobre makers.
A transcrição preserva a fala original em português e pode conter erros de reconhecimento. Esta página desenvolve as ideias com os slides e as fontes citadas.