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.

A perspective from Serradura

Choose a chapter
Strength comes from the combination
  1. AI
    Expands your capacityExplore, implement, and review with agents.
  2. Rails
    Gives the product structureConventions and resources that work together.
  3. Fundamentals
    Give your decisions directionUnderstand the problem and recognize a good solution.

Fundamentals, Rails, and AI combine to expand what you can accomplish.

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.

One product. An entire ecosystem.

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.

Your productShared rules and data, connected to people, systems, and agents.

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.
Your productShared rules and data, connected to people, systems, and agents.

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.

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.

Watch the ecosystem introduction in the talk Back to chapters

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.

Watch the discussion of scale in the talk Back to chapters

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.

Three fields. The same principle.

UX

Progressive disclosure

Show what is relevant at each moment.

Cognitive load

Attention and memory

Work with the information that needs to fit in the mind.

Architecture

Modularity

Find, understand, and change each part.

Reveal what matters

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.

Back to chapters

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 talk
Modularity and deployment are different decisions.

Modularity

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.

Context unfolds in layers.
  1. The task begins in the code.Codebase

    Names and organization reveal the concepts.

  2. When the code does not explain everything.Project

    AGENTS.md and CLAUDE.md record local decisions and constraints.

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

Back to chapters

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 organization changes. So does the Agent-Friendliness assessment.

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) 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

Agent-friendliness (0–25)

  1. Starting point1A

    10/25
  2. Highest study score6G

    24/25
  3. Final version7D

    19/25
See all 28 scores
  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
Compare versions in the Gradient

One vocabulary across layers

The same concept can be recognized in routes, controllers, models, and views.

5C-unified-vocabulary

A declared responsibility

The rule has a home in the model responsible for its data and behavior.

5D-model-authority

Named orchestrations

Operations that coordinate steps become a concept that can be found and reviewed.

6G-named-orchestrations

Resources that guide routes

Consistent names and resources bring the domain closer to Rails conventions.

3F-resource-discipline

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

Back to chapters

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.

Serradura's perspective

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.

Watch DHH discuss HEY Back to chapters

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.