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.

Uma visão do Serradura

Escolher um capítulo
A força vem da combinação
  1. IA
    Amplia sua capacidadeExplore, implemente e revise com agentes.
  2. Rails
    Dá estrutura ao produtoConvenções e recursos que trabalham juntos.
  3. Fundamentos
    Dã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.

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.

Um produto. Um ecossistema inteiro.

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.

Seu produtoUma base de regras e dados, conectada a pessoas, sistemas e agentes.

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.
Seu produtoUma base de regras e dados, conectada a pessoas, sistemas e agentes.

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.

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.

Ver a apresentação do ecossistema na palestra Voltar aos capítulos

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.

Ver a discussão de escala na palestra Voltar aos capítulos

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.

Três campos. O mesmo princípio.

UX

Progressive disclosure

Mostrar o que é relevante em cada momento.

Carga cognitiva

Atenção e memória

Trabalhar com a informação que precisa caber na mente.

Arquitetura

Modularidade

Encontrar, compreender e mudar cada parte.

Revele o que importa

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.

Voltar aos capítulos

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 palestra
Modularidade e deploy são decisões diferentes.

Modularidade

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.

O contexto se revela em camadas.
  1. A tarefa começa no código.Codebase

    Nomes e organização revelam os conceitos.

  2. Quando o código não explica tudo.Projeto

    AGENTS.md e CLAUDE.md guardam decisões e restrições locais.

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

Voltar aos capítulos

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.

A organização muda. A avaliação de Agent-Friendliness também.

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) 25 20 15 10 5 0 10 1A 15 1B 17 2A 19 2B 14 3A 15 3B 16 3C 17 3D 16 3E 20 3F 21 3G 14 4A 18 4B 17 5A 18 5B 21 5C 23 5D 19 6A 22 6B 19 6C 21 6D 22 6E 19 6F 24 6G 19 7A 19 7B 17 7C 19 7D

Facilidade para agentes (0–25)

  1. Ponto de partida1A

    10/25
  2. Maior nota do estudo6G

    24/25
  3. Última versão7D

    19/25
Ver as 28 notas
  1. 1A
    10/25
  2. 1B
    15/25
  3. 2A
    17/25
  4. 2B
    19/25
  5. 3A
    14/25
  6. 3B
    15/25
  7. 3C
    16/25
  8. 3D
    17/25
  9. 3E
    16/25
  10. 3F
    20/25
  11. 3G
    21/25
  12. 4A
    14/25
  13. 4B
    18/25
  14. 5A
    17/25
  15. 5B
    18/25
  16. 5C
    21/25
  17. 5D
    23/25
  18. 6A
    19/25
  19. 6B
    22/25
  20. 6C
    19/25
  21. 6D
    21/25
  22. 6E
    22/25
  23. 6F
    19/25
  24. 6G
    24/25
  25. 7A
    19/25
  26. 7B
    19/25
  27. 7C
    17/25
  28. 7D
    19/25
Comparar as versões no Gradiente

Um vocabulário entre as camadas

O mesmo conceito pode ser reconhecido nas rotas, nos controllers, nos models e nas views.

5C-unified-vocabulary

Uma responsabilidade declarada

A regra encontra um lugar no model que responde pelos dados e pelo comportamento.

5D-model-authority

Orquestrações com nome

Operações que coordenam passos ganham um conceito que pode ser encontrado e revisado.

6G-named-orchestrations

Recursos que orientam as rotas

Nomes e recursos consistentes aproximam o domínio das convenções do Rails.

3F-resource-discipline

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

Voltar aos capítulos

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.

A visão do Serradura

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.

Ver o relato de DHH sobre o HEY Voltar aos capítulos

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.