Can Ruby Power AI features? What It Handles Well and Where It Stops

The ruby-openai gem, a client for integrating OpenAI models into Ruby applications, has surpassed 43 million downloads, and in 2025, OpenAI, Gemini, and Anthropic released official Ruby SDKs. These developments show that leading model providers now recognize Ruby as a first-class language for AI integration.

Yet teams building products with Ruby on Rails still hear the same advice: AI requires Python, so a rewrite is inevitable. That assumption can be costly. Rebuilding an application can stall the product roadmap and consume months of engineering time before a single AI feature reaches users, while 88% of organizations already use AI regularly in at least one business function.

For most products, however, a rewrite is unnecessary. Python remains the leading choice for training machine learning models, but delivering AI-powered features is a different task. Most companies access AI through APIs, making implementation primarily an integration and orchestration challenge that Ruby can effectively handle.

In this article, we explore which AI workloads Ruby supports and where its limitations begin. We also share Leobit’s experience in developing AI-powered software with Ruby and provide a practical checklist to help you choose the right approach for your technology stack.

Ruby is a general-purpose programming language designed around developer productivity, with Ruby on Rails as its flagship web framework. Questions about the framework’s decline have circulated for years, and we explored them in our Is Ruby on Rails Dead? article.

Yet production data offers a cleaner answer than industry commentary. During the 2025 Black Friday and Cyber Monday weekend, Shopify’s Rails-based platform processed $14.6 billion in merchant sales, with traffic peaking at 489 million requests per minute. Among the companies using Ruby for AI-driven solutions are market giants like GitHub, GitLab, Shopify, and Discourse. A language proven at this scale provides a stable foundation for adding AI capabilities.

Ruby’s AI ecosystem has also matured. Applications can now connect to all major model providers through official or well-maintained client libraries, while tools for retrieval, embeddings, and orchestration have become suitable for production use. We examine the most relevant Ruby AI libraries later in this article.

None of these challenges threatens Python’s leading role in AI research and model development. For businesses, however, the more useful question is not where Ruby ranks among AI languages, but which parts of an AI initiative can remain within the existing stack and which genuinely require Python. The next section draws that boundary.

Python dominates machine learning research and model training because the entire toolchain, from PyTorch to Hugging Face, is built around it. If your company plans to train models from scratch or fine-tune them at a serious scale, your data science team will work in Python. On this point, the common advice is correct.

The more relevant question is how many businesses actually need to build models themselves. According to Menlo Ventures’ 2025 State of Generative AI in the Enterprise report, 76% of enterprise AI use cases are now bought rather than built. This marks a sharp shift from 2024, when companies developed roughly half of their AI applications in-house. The same report found that foundation model APIs accounted for $12.5 billion in enterprise AI spending in 2025. In practice, most companies access advanced models in much the same way they use payment processing or email delivery: through an API.

This changes the meaning of the language debate. When intelligence is delivered through an API, the competitive advantage moves to the product layer: how well the feature fits the user’s workflow and how quickly the team can improve it. In most cases, integrating AI into an existing Ruby application is far less expensive than rebuilding the product around a new Python stack.

A rewrite means recreating years of business logic, integrations, and operational knowledge before delivering a single AI feature. By contrast, an API integration lets the existing application gain AI capabilities while the team continues shipping product improvements. The result is lower cost and significantly less implementation risk.
The same separation applies to custom models. Training can take place in Python, while the finished model is exposed through an API that any application can call. Our fire inspection project, discussed later in this article, followed exactly this approach.

Ruby on Rails can support production-ready AI features through mature model integrations, established vector search tools, and orchestration capabilities refined over two decades. Together, these components cover the full path from a model API to a user-facing feature.

Connecting a Rails application to an AI model is standard integration work. The official OpenAI and Anthropic SDKs support capabilities such as streaming, function calling, and structured outputs, while the official AWS SDK for Ruby provides access to Amazon Bedrock.

Our Ruby developers work with OpenAI and Amazon Bedrock as part of our standard technology stack, alongside tools such as Tesseract for OCR and PyTorch.

Beyond provider SDKs, Ruby now has dedicated frameworks for building AI-powered applications. Langchainrb, a Ruby framework for LLM applications, has surpassed 1.3 million downloads and supports retrieval-augmented generation (RAG), prompt management, and multiple model providers through a unified interface.

Ruby LLM offers a similar abstraction for chat, embeddings, and multimodal workflows. For vector search, the Neighbor gem integrates pgvector directly with Active Record, allowing Rails applications to store embeddings and perform semantic search in the PostgreSQL database they already use.

When a project requires a dedicated vector database for larger datasets or more advanced retrieval workloads, Rails applications can also integrate with platforms such as Pinecone or Milvus through their Ruby SDKs. In practice, we typically work with maintained forks of these SDKs when appropriate, allowing us to incorporate new features or project-specific enhancements without waiting for upstream releases.

For agentic AI workflows, the Ruby ecosystem also offers ActiveAgent, a framework designed around familiar Rails conventions. It allows developers to build AI agents in much the same way they create models or mailers. This, in turn, reduces the learning curve and keeps agent logic consistent with the rest of the application. This Rails-native approach makes it faster and more convenient for Ruby teams to develop, test, and maintain AI agents without introducing an unfamiliar programming model.

The ecosystem also supports the Model Context Protocol (MCP) through the official Ruby SDK. This allows Rails applications to expose business capabilities as MCP servers, enabling AI agents to securely access data, execute actions, and interact with existing systems through the emerging open standard for AI integrations.

Much of the engineering work behind an AI feature happens around the model call rather than inside it, and this is where Rails is particularly effective. AI requests can be slow or occasionally fail, so they are well-suited to background processing with Sidekiq or Rails’ built-in Solid Queue. Responses can be streamed to the browser through AnyCable or Action Cable, while costs and rate limits can be managed with the same caching, retry, and throttling patterns Rails teams already use for other external services.

For developers, this means an AI feature may require additional product work, but they can still be built within a familiar framework rather than on an entirely new platform.

The result is a shorter path from idea to production. With the right AI development support, a Rails team can prototype a capability using a provider API, validate it with real users, and prepare it for production without changing languages or splitting the application across multiple stacks.

Ruby on Rails has always followed the Convention over Configuration principle. Instead of allowing every project to organize its architecture however it wants, Rails encourages consistent patterns for folder structure, business logic, naming conventions, and application design. As a result, most Rails applications look and behave in broadly similar ways.

The Ruby community reinforces this consistency through well-established coding standards, including the widely adopted Ruby and Rails Style Guides. Tools such as RuboCop, Reek, and Brakeman are commonly used to enforce these conventions, identify code smells, detect security issues, and keep codebases aligned with community best practices.

Many production Rails applications also adopt Sorbet for static type checking, bringing TypeScript-like guarantees to the Ruby ecosystem. Type annotations provide additional context about method signatures, expected arguments, and return types, helping both developers and AI coding assistants reason about the codebase more accurately. They also make it easier to catch issues such as incorrect method arguments, broken references after refactoring, or renamed methods that were not updated everywhere in the application.

As AI coding assistants become part of the everyday development workflow, Rails’ convention-driven architecture provides another practical advantage. An AI agent working in a standard Rails application does not have to infer where business logic belongs or how the project is organized. Familiar directory structures, consistent naming conventions, and predictable design patterns allow it to navigate the codebase more effectively. This results in more accurate code suggestions, safer refactoring, and faster onboarding for both developers and AI-powered engineering tools.

Ruby is well-suited to AI initiatives that extend an existing product or bring a new one to market quickly. Projects centered on model development, however, are generally better served by Python. The following three scenarios cover most of the decisions businesses face in practice.

This is the most common use case. An established product already contains the two things AI features need most: structured business data and proven user workflows. Capabilities such as semantic document search, automated report review, content generation, or intelligent customer support can often be added through model APIs without rebuilding the underlying platform.

In this scenario, iteration speed matters more than access to the most advanced model tooling. According to McKinsey’s The State of AI 2025 survey, only 39% of organizations using AI report a measurable impact on enterprise-level EBIT. Achieving that impact typically requires several rounds of testing and refinement based on real user feedback. A team working within a familiar stack can complete those cycles faster than one that is simultaneously learning and maintaining a new technology.

Rails has long been a strong choice for startup MVP development, and access to AI through provider APIs makes it even more practical. Because the model does not need to be built from scratch, the main priority becomes validating the product quickly.

A small Rails team can launch an AI-powered product, test it with real users, and confirm market demand before investing in more complex infrastructure.

Some AI initiatives require Python from the outset. Training proprietary models and building large-scale data pipelines depend heavily on Python’s machine learning libraries, GPU tooling, and broader data science ecosystem. Python is also the more suitable choice for latency-sensitive local inference. When a custom model is the core product rather than a supporting capability, its development should generally remain in Python.

The two technologies do not have to be treated as competing choices. A common architecture keeps the product and user-facing workflows in Rails while placing model training and inference in dedicated Python services connected through APIs. Leobit supports this approach with expertise across both stacks, drawing on more than 15 delivered Python projects and over 10 AI projects.

The next section shows how this separation worked in a real Ruby-based platform.

The architecture above, a Rails product layer consuming models built in a dedicated machine learning environment, is exactly how our team added AI capabilities to a fire inspection SaaS platform for a US fire protection company.

The customer has operated in the US market for decades and employs more than 50 people. Its SaaS platform allows businesses and private customers to request, schedule, and manage fire inspections. Leobit provided the Ruby team responsible for the platform’s back end, while a dedicated .NET team supported other parts of the project.

Our Ruby specialists redesigned the application architecture to support future growth and new functionality. They also optimized the AWS-based back end shared with the mobile application and improved the platform’s multi-tenant database infrastructure.

The AI capability was introduced into the reporting workflow. Our team integrated the platform with custom machine learning models built in Amazon SageMaker. The models automatically review fire inspection reports and identify missing information, formatting problems, and inappropriate wording before the documents are delivered to end clients.

The platform did not need to change languages. Model development remained within the SageMaker environment, while the Rails back end consumed the model output as another integrated service. As a result, the customer gained automated report quality control without rewriting the product or separating AI functionality from the team responsible for maintaining the platform.

AI can be integrated into a Ruby app as a feature, but it can also be used to enhance the development workflow itself. With its ability to boost productivity in particular industries by 60%, AI adds even more to Ruby’s already fast development speed, one of the framework’s key advantages.

The benefits are practical: AI handles repetitive tasks, shortens feedback loops, and gives developers more time to focus on business logic and product quality.

AI helps generate RSpec tests for new functionality and improve overall test coverage, reducing the risk of regression bugs. It works with the existing test suite (unless there is a clear reason to change it), which helps preserve established behavior and prevents new changes from hiding problems in older tests.

Before a pull request reaches a human reviewer, an AI assistant can perform an initial quality check. It identifies common issues such as unclear naming, missed edge cases, and style inconsistencies, allowing reviewers to focus on architecture, business logic, and other higher-value concerns. This reduces unnecessary back-and-forth and helps shorten review cycles.

For standard CRUD endpoints and basic API logic, AI can follow examples already present in the codebase. This reduces repetitive copy-and-paste work and lowers the risk of overlooking validation, authorization, error handling, or other required steps. Instead of creating a new implementation from scratch, the assistant applies the patterns and conventions the project already uses.

On the front end, AI assistants can work directly with markup and styles. Developers can use them to apply specific Tailwind or brand guidelines, add media queries for different breakpoints, and adjust layouts across screen sizes.

This makes routine interface decisions, such as spacing, alignment, and responsive behavior, faster to implement. As a result, developers can spend less time on repetitive styling adjustments and more time delivering the underlying business functionality.

The right technology choice depends on the nature of your AI initiative. Before committing to a rewrite or introducing a new stack, consider the following five questions.

If your planned features rely on provider APIs or pre-trained models, your existing stack can usually support them. AI assistants, document summarization, semantic search, classification, and content generation all fall into this category. The model provides the intelligence, while your team focuses on integrating it into the product and user workflow.

Building AI is a different undertaking. If your competitive advantage depends on training proprietary models with your own data, you will likely need Python, dedicated data engineering, and machine learning expertise. The distinction matters because these two paths require very different teams, infrastructure, timelines, and budgets.

A mature application contains much more than visible features. Over time, it accumulates business rules, edge cases, integrations, permission models, compliance controls, and operational knowledge. A rewrite must reproduce all of this before it can deliver additional value.

An API integration, by comparison, adds AI capabilities to the product that already works. Before treating migration as inevitable, estimate the rewrite in engineer-months and include the opportunity cost of features that would be postponed during the transition. Then compare that total with the cost of integrating AI into the current platform. In many cases, this comparison makes the more practical option clear.

Iteration speed has a direct effect on how quickly an AI feature begins producing measurable value. The first version is rarely the final one. Prompts need refinement, workflows need adjustment, outputs require validation, and real users reveal issues that no initial specification could anticipate.

A team working in a familiar framework can respond to that feedback quickly. A team that is also learning a new language, rebuilding development processes, and hiring for unfamiliar skills will move more slowly. Under deadline pressure, this can affect both product quality and the long-term maintainability of the codebase.

External model APIs are sufficient for most product features. Document review, report analysis, content generation, and support conversations can usually tolerate response times measured in seconds. Background jobs and asynchronous processing can also keep longer operations from interrupting the user experience.

Dedicated services become more appropriate when inference must run locally, data volumes make network transfers impractical, or strict real-time requirements leave little room for an external API call. Large-scale data pipelines and workloads that depend heavily on GPUs may also justify a Python-based service. Evaluate each feature against its actual performance requirements rather than applying the most demanding architecture to the entire product.

You do not always have to choose between Rails and Python for the whole system. A hybrid architecture can keep business logic, user workflows, and product functionality in Rails while moving model training, inference, or data-intensive processing into separate Python services.

The two layers communicate through a defined API, allowing them to be developed, scaled, and maintained independently. Our fire inspection project followed this model: machine learning development remained in Amazon SageMaker, while the Rails back end consumed the results. This approach also preserves flexibility because either side can evolve or be replaced without requiring a full rebuild of the other.

Leobit combines Ruby development expertise with hands-on AI development experience. Our Ruby team has delivered more than 30 projects over eight years and has been recognized by Clutch as a Top Ruby on Rails Developer.

Leobit combines proven engineering expertise with mature AI delivery capabilities with 6+ years of experience developing AI solutions for both internal needs and client projects. The company has also been recognized as a Top AI Code Generation Company by Clutch and continues to deepen its AI expertise through advanced certifications, including undergoing the Anthropic certification process and having Anthropic Claude Certified Architects.

In practice, our expertise covers every scenario discussed in this article. If you want to extend an existing Rails product, our engineers assess the application, identify the AI use cases with the clearest business value, and integrate them without disrupting your roadmap. If you are validating a new AI-powered product, we assemble a dedicated team that takes it from concept to MVP on Rails. And when your initiative requires model work beyond the product layer, we staff hybrid teams across Ruby, Python, and .NET, as we did for the fire inspection platform described above.

Ruby’s role in the AI landscape reflects a broader shift in the market: advanced models are increasingly delivered as services, while competitive advantage comes from turning their capabilities into reliable, useful product features. This shift favors teams that can integrate AI into real workflows and iterate quickly, making Ruby on Rails a practical foundation for AI-powered products.

For most businesses, the choice is less dramatic than the rewrite debate suggests. Use the existing product stack to consume AI models, and introduce dedicated Python or other specialized services only where model development, data processing, or performance requirements genuinely demand them.

Companies get the most value from AI by releasing features, monitoring user behavior, and refining them based on real-world usage. An established Rails product, supported by a team that already understands its users, data, and business logic, provides a strong environment for doing exactly that.

If you are weighing the options for your own product, a short conversation with our team can save you months of exploration. Contact us for a consultation on your Ruby and AI initiative.