Rails, fundamentals, and AI to make things happen.
From interfaces to deployment, Rails brings together tools for building a product. See how conventions, modularity, and feedback help agents find context and help you guide the decisions.
Choose a chapter- AIExpands your capacityExplore, implement, and review with agents.
- RailsGives the product structureConventions and resources that work together.
- FundamentalsGive your decisions directionUnderstand the problem and recognize a good solution.
Fundamentals, Rails, and AI combine to expand what you can accomplish.
Watch the talk26:28
A talk in Portuguese at Tropical on Rails.
A foundation that already does much of the work.
Web, native mobile apps, APIs, and agents can access the same product. Rails and its ecosystem connect these interfaces to data, communication, deployment, and observability.
Interfaces for people, systems, and agents
-
Web and PWA
Hotwire interfaces and support for bringing your app from the browser to the home screen.
-
Native mobile
iOS and Android apps with Hotwire Native, combining web screens and native navigation.
-
APIs and integrations
REST with Rails, GraphQL and gRPC with Ruby libraries to connect other systems.
-
Agents via MCP
Your product's tools and resources accessible to agents through the official Ruby SDK.
A foundation for the product
- Data with Active Record
- Persistence, queries, and support for working with multiple databases.
- Jobs with Solid Queue
- Background work backed by the database.
- Caching with Solid Cache
- A database-backed caching option for your application.
- Files with Active Storage
- Uploads and file access connected to the product's data.
Communication and infrastructure
- Real time with Action Cable
- WebSocket communication integrated into the Rails application.
- Email with Action Mailer
- Messages that participate in the product's flows and events.
- Deployment with Kamal
- Deploying containerized applications to your servers.
- Observability with Upright
- Checks availability and user flows, with Prometheus metrics and OpenTelemetry traces.
Interfaces for people, systems, and agents
Web and PWA
Native mobile
iOS and Android apps with Hotwire Native, combining web screens and native navigation.
APIs and integrations
Agents via MCP
A foundation for the product
- Data with Active Record
- Persistence, queries, and support for working with multiple databases.
- Jobs with Solid Queue
- Background work backed by the database.
- Caching with Solid Cache
- A database-backed caching option for your application.
- Files with Active Storage
- Uploads and file access connected to the product's data.
Communication and infrastructure
- Real time with Action Cable
- WebSocket communication integrated into the Rails application.
- Email with Action Mailer
- Messages that participate in the product's flows and events.
- Deployment with Kamal
- Deploying containerized applications to your servers.
- Observability with Upright
- Checks availability and user flows, with Prometheus metrics and OpenTelemetry traces.
From interfaces to operations, an ecosystem to build and sustain the product. Choose the pieces your context needs.
What does Rails offer beyond pages and CRUD?
Rails brings together web interfaces, PWA support, REST APIs, data, files, email, and background work. Hotwire Native brings the product's flows to iOS and Android apps. Ruby libraries and SDKs extend this foundation with GraphQL, gRPC, and MCP. For infrastructure, Kamal handles deployment, while Upright provides synthetic monitoring and integration with metrics and traces. These are connected paths to build, deliver, and observe the same product.
Why does having these pieces integrated matter?
A product request often crosses several parts of an application. Shared conventions help connect the interface, rules, persistence, and background work. People and agents find recurring paths for these tasks. That lets you invest more attention in the product's behavior and the decisions that belong to your business.
Do I need everything the ecosystem offers?
Choose resources to fit the problem. An application can start with a few components and adopt others when a concrete need appears. Understanding each tool's role helps you assess its configuration, dependencies, and operating costs. The breadth of the ecosystem gives you options to grow with judgment.
Room to grow. Judgment to evolve.
Shopify shows the scale a Rails foundation can reach. Getting there involves engineering, observation, and decisions that follow the business. Growth also brings new rules, data, and people.
- Traffic
- Where does usage meet a bottleneck?
- Data
- How do queries, volume, and consistency affect the product?
- Domain
- Do the rules still have a clear home in the code?
- Teams
- Which changes require coordination between people?
Does Rails scale?
Shopify is a concrete example of Rails at large scale. Its journey shows how the framework can support a product with substantial usage and complexity. That capability comes with work on infrastructure, data, observability, and code organization. The case expands the horizon for someone getting started and offers real decisions to study.
Do I need to start with microservices to grow?
A monolith can grow and develop clear internal boundaries. Separating services introduces contracts, communication, and coordination between parts. Those costs can be worthwhile when isolation, autonomy, or operational needs call for them. Architecture should respond to the pressures you observe in the product, with a concrete reason for each separation.
How do I know what needs to evolve?
Identify the pressure that is increasing. A query bottleneck needs a different investigation from conflicts between teams or scattered business rules. Observe usage, failures, and the cost of change. That evidence helps you choose between optimizing an operation, reorganizing the domain, expanding infrastructure, or separating a responsibility.
Conventions provide context. You provide direction.
Names, recurring structures, and familiar resources help an agent find its way. This foundation becomes useful when it connects to a clear goal and verification of the result.
UX
Progressive disclosureShow what is relevant at each moment.
Cognitive load
Attention and memoryWork with the information that needs to fit in the mind.
Architecture
ModularityFind, understand, and change each part.
Context that fits the task.
People have limits of attention and memory. Agents work with a context window. Organizing access to information helps both.
Why do Rails conventions help agents?
Conventions make parts of a system predictable. A name suggests where to look; a route points to a resource; a familiar pattern helps explain a new area. An agent can use these signals to navigate the code. When an application maintains that coherence, its intent becomes easier to find and connect to behavior.
Why did Garry Tan highlight Rails for building with AI?
Garry Tan, of Y Combinator, publicly praised Rails paired with Claude Code. In his post, he connects Rails' expressiveness with code generation by language models. That observation provides a starting point for exploring how a language and its ecosystem can support work with agents.
Does Ruby use fewer tokens?
Ruby's expressiveness lets you represent ideas with little noise, and the talk presents studies of token efficiency. A task's cost also depends on the context loaded, searches, and attempts required. Assess the complete journey of finding the behavior, understanding the change, implementing it, and verifying that it solved the problem.
Is knowing Rails enough to deliver a feature?
Knowing the framework helps with writing and locating code. Delivering a feature also requires understanding the product, respecting constraints, and verifying the expected behavior. The Agents on Rails studies distinguish framework knowledge from feature implementation. That difference helps you choose what to ask an agent and how to assess its delivery.
Architecture shows up in the cost of the next change.
Finding, understanding, modifying, and verifying are all part of the work. Code organization affects each step, for people and agents alike.
Watch progressive disclosure and architecture in the talkModularity
Modular monolith
Clear boundaries in one deployment unit.
Microservices
Clear boundaries and coordination between services.
Monolithic big ball of mud
Mixed responsibilities in the same deployment.
Distributed big ball of mud
Mixed responsibilities and distributed coordination.
Deployment units
One deployment unit
Modular monolith
Clear boundaries in one deployment unit.
Monolithic big ball of mud
Mixed responsibilities in the same deployment.
Multiple services
Microservices
Clear boundaries and coordination between services.
Distributed big ball of mud
Mixed responsibilities and distributed coordination.
Distributing code changes operations. Modularity depends on how you define responsibilities and relationships.
- The task begins in the code.Codebase
Names and organization reveal the concepts.
- When the code does not explain everything.Project
AGENTS.md and CLAUDE.md record local decisions and constraints.
- When a pattern repeats across projects.Ecosystem
Skills bring reusable knowledge to a specific need.
Knowledge on demand, at every level.
Code shows its concepts. Instructions explain the project's context. Skills add knowledge for the task.
Why does architecture matter when AI writes the code?
AI expands your ability to make changes. The system still needs to show where to act, which rules to preserve, and which consequences to verify. Mixed responsibilities and conflicting patterns increase that effort. A comprehensible architecture helps you direct the work and assess whether a change preserves the behavior the product needs.
What is progressive disclosure in code?
It means revealing what a task needs and providing access to detail when it becomes relevant. A good name points to a concept. That concept reveals its behavior and dependencies. People and agents can deepen their reading as needed, with a clear path from the question to the part of the system that answers it.
What does a monolith offer for this work?
A unified codebase makes it easier to follow relationships, find contracts, and change references together. A change can be tested and delivered as one unit. This proximity helps you investigate the complete behavior. Its value also depends on names, boundaries, and responsibilities that make the code understandable along the way.
Does modularity depend on separate deployments?
Modularity comes from clearly defined responsibilities and relationships. You can create boundaries within an application and keep a single deployment. Separating operations is another decision, with benefits and costs of its own. Cohesion and loose coupling help you change a part with attention proportionate to the problem, whatever topology you choose.
The same application makes choices comparable.
Rails Whey App puts this investigation into code. You can examine what changes when a responsibility gets a name, an operation becomes explicit, and new boundaries enter the picture.
Adding boundaries can improve isolation while increasing the effort needed to understand and change the system. The versions make that tradeoff visible in the code.
The scores follow the study's criteria for this app and the tasks analyzed. The rubric describes code structure; performance and token use need separate tests. Compare the details of each version in the Gradient. Read the Agent-Friendliness report
Agent-friendliness (0–25)
-
Starting point1A
10/25 -
Highest study score6G
24/25 -
Final version7D
19/25
See all 28 scores
-
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
One vocabulary across layers
The same concept can be recognized in routes, controllers, models, and views.
5C-unified-vocabularyA declared responsibility
The rule has a home in the model responsible for its data and behavior.
5D-model-authorityNamed orchestrations
Operations that coordinate steps become a concept that can be found and reviewed.
6G-named-orchestrationsResources that guide routes
Consistent names and resources bring the domain closer to Rails conventions.
3F-resource-disciplineWhat does the Agent-Friendliness assessment examine?
The study considers context cost, discoverability, isolation, predictability, and the reach of a change. These criteria help examine how each version organizes work for an agent. The scores describe this app and the tasks analyzed. Examples, files, and decisions let you investigate the results and form your own judgment.
Which practical changes stand out in the experiment?
A unified vocabulary connects the application's layers. Declaring responsibility for rules gives decisions a home. Naming orchestrations makes the steps of an operation visible. Organizing resources reduces exceptions in routes. You can follow these changes in the branches, read their reasoning, and compare the consequences in the code.
Does more structure always help an agent?
Structure can bring isolation while also creating new search paths, contracts, and coordination rules. The experiment shows this tradeoff. Increasing sophistication does not produce continuous improvement in Agent-Friendliness. The choice must consider the need a boundary serves and the effort it adds to understanding and changing the system.
How much guidance does an agent need?
Instructions record decisions, constraints, and paths that code alone does not explain. Clear names and responsibilities reduce the guidance needed to compensate for confusing structure. Use documentation to preserve important context and support discovery. The code should also communicate its concepts and make it clear where each behavior takes place.
Tools turn criteria into feedback.
The ecosystem also helps you observe, investigate, and verify. Each tool answers a different question about the work that people and agents perform.
Watch the tools presented in the talkStatic foundation
Style, boundaries, and contracts that can be checked in the code.
Feedback to guide the next decision
RuboCop, Packwerk, and Sorbet help check the code. Ruby LSP and Tidewave expand the context available to investigate it.
How do I assess code produced by an agent?
Start with the expected behavior and the consequences of the change. Tests, linters, and code analysis turn some of those criteria into repeatable checks. Read their results and examine what they cover. Review connects those signals to the task's goal, the product's rules, and the risks that still need attention.
How can an agent investigate beyond files?
Code indexing helps locate symbols and relationships. Connections to a running application can provide context about data, behavior, and errors. The talk presents LSP and Tidewave as ways to bring this information closer to the agent. That feedback complements reading the code and helps investigate hypotheses during a change.
How do I choose the right tools?
Start with the question you need to answer. Code consistency, type contracts, boundaries, and runtime behavior require different checks. Use what already helps in the project and extend it as needs arise. A tool has value when its feedback guides a decision and helps verify the result you intend to deliver.
Being a maker means making things happen.
Choose with judgment, build with the tools available, and use AI to go further.
Fundamentals give you direction. AI expands your ability to make things happen.
Whether you are a developer or a vibe coder, developing judgment helps you guide agents, assess deliveries, and keep evolving what you build.
This reflection on makers, results, and rewrites extends the talk's thesis. The author added it after the presentation.
Is a faster app always a better product?
Performance has value when it serves a real need. A product also needs to solve problems, reach people, and remain viable to change. Confusing architecture can make each improvement more expensive, even with agents. The maker considers the whole picture to decide where to invest and how to assess what improved.
Does a rewrite mean Rails failed?
An application in use accumulates rules, real cases, and understanding of the business. A specific need may justify another implementation informed by that experience. The code, tests, and existing behavior provide a reference for the change. In Serradura's view, that continuity can be part of a journey that succeeded.
How does the HEY story connect to this view?
DHH announced a reconstruction of HEY's back end in Rust with agents. Serradura sees the value of knowledge accumulated in the Rails application in that account. A well-understood product offers a functional reference for assessing another implementation. This reading concerns the ability to decide and evolve. The announcement alone does not establish a production migration.
Does this apply to developers and vibe coders?
Developers can use their experience to direct and review agents. People who started building with AI can develop the understanding to recognize limits, ask useful questions, and assess deliveries. Technical depth varies with context. Both can expand their results with the fundamentals needed to guide the work and understand its consequences.
What does making things happen with fundamentals mean?
It means using the resources available to solve a problem, observing the result, and learning what the next step requires. You decide what needs to be done and verify what was delivered. AI expands that capacity. Rails Whey shares code, ideas, and conversation to help you develop your own judgment.
The talk and sources behind this article
The video and slides record the original presentation. Ecosystem sources support this article, and Serradura's later reflection is identified in the section about makers.
The transcript preserves the original talk in Portuguese and may contain recognition errors. This page develops its ideas with the slides and cited sources.