You can get the new build from our website or via the free Toolbox App.

Let’s take a look at the highlights of this release.

AI

RubyMine continues to evolve as an open platform that lets you bring your preferred AI tools directly into your development workflow. With RubyMine 2026.1, working with multiple AI agents and integrating them into your IDE experience is now easier than ever.

Use more AI agents in RubyMine

In addition to Junie and Claude Agent, you can now choose more agents in the AI chat, including Codex. Additionally, Cursor and GitHub Copilot, along with dozens of external agents, are now supported via the Agent Client Protocol (ACP). With the new ACP Registry, you can discover available agents and install them in just one click.

Work with connected databases directly in the AI chat

The AI chat integration for Codex and Claude Agent now offers full, native support for your connected databases. With that, you can now query, analyze, and modify your database state using natural language right from the IDE.

The same functionality is available for external agents via MCP server.

Get next edit suggestions throughout your file

Next edit suggestions are now available without consuming AI quota of your JetBrains AI Pro, Ultimate and Enterprise subscriptions. These suggestions go beyond what is offered by traditional code completion for your programming language. Instead of updating only what’s at your cursor, they intelligently apply related changes across the entire file, helping you keep your code consistent and up to date with minimal effort.

This natural evolution of code completion delivers a seamless Tab Tab experience that keeps you in the flow. 

Code insight

Try the new code insight engine (Beta)

RubyMine 2026.1 introduces a new, currently experimental, symbol-based language modeling engine.

This engine changes how RubyMine understands classes, modules, and constants (support for methods is planned for future releases), laying the groundwork for faster and more reliable code insight.

Our internal benchmarks show significant improvements.

Qualified first-element constant completion is about 40% faster, while the overall time for constant completion improved by roughly 50%. Type-matched completion for exceptions became dramatically faster – by about 95%. In addition, the performance of Find Usages improved by around 60% in large projects and by about 15% in typical cases.

Additional areas that benefit from the new engine include:

• Rename refactoring
  
• Quick Documentation, Quick Definition, and Ctrl+Hover hints
  
• Structure view
  
• Navigation (Go to Declaration and Go to Type Declaration)
  

Because the engine is still in Beta, it is disabled by default. You can enable it in Settings | Languages & Frameworks | Ruby | Code Insight.

Give it a try and share your feedback!

Remote development

Boost your productivity with Stable remote development

Remote development officially moves out of Beta and becomes Stable in RubyMine 2026.1.

You can now connect to your development environments via SSH, Dev Containers, or WSL 2, and the IDE backend will run on the remote machine while the user interface remains fast and responsive on your local device.

This setup gives you the full RubyMine experience wherever your code lives.

Rails

Work seamlessly with variables passed via render

RubyMine now correctly recognizes local variables passed via render.

Variables provided through the locals: option are no longer marked as unresolved and appear in code completion.

This behavior works consistently across views, layouts, partials, and templates (ERB and HAML), providing cleaner code insight and fewer unnecessary warnings.

Detect deprecated Rails associations instantly

Keeping Rails projects modern and maintainable is now easier with improved deprecation detection.

When a Rails association is marked as deprecated (for example, has_many :posts, deprecated: true), RubyMine highlights all its usages throughout your project and shows a clear deprecation notice in the Quick Documentation popup.

This helps you identify outdated APIs early and update your code proactively.

Use Rails virtual database columns

RubyMine 2026.1 adds recognition for virtual generated columns from PostgreSQL 18 (or later versions) in Rails projects.

These non-persisted columns behave just like regular attributes in the IDE. Code completion, type hints, and navigation to the column definition in schema.rb work seamlessly.

Ruby and RBS

Use endless methods with access modifiers

RubyMine now fully supports Ruby 4.0 endless methods with access modifiers. Code such as private def hello = puts "Hello" is now parsed correctly and no longer produces errors.

Use more Ruby and RBS operators in completion

You can now type Ruby and RBS operators (=, !, +, *, and others) directly in the completion popup without closing it. This keeps you in the flow and helps you finish expressions faster.

Rename global variables safely

RubyMine now validates global variable names during renaming.

Invalid names such as $foo!@# are no longer allowed, preventing broken code and syntax errors. The IDE ensures renamed variables follow Ruby’s syntax rules, making refactoring safer and more reliable.

Let RubyMine select the Ruby interpreter automatically

RubyMine 2026.1 can automatically detect the correct Ruby interpreter by analyzing configuration files such as .ruby-version or .tool-versions.

There are three scenarios:

• Single match found: RubyMine sets the interpreter automatically so you can start coding immediately.
  
• Multiple matches or no match found: RubyMine shows a notification and helps you choose the correct interpreter.
  
• No configuration file found: RubyMine selects the latest installed MRI Ruby version as a safe default.
  

If you prefer manual configuration, you can disable this behavior in Settings | Languages & Frameworks | Ruby. Find more details in our docs.

User experience improvements

Debug failing tests faster with the diff viewer

RubyMine 2026.1 introduces a diff viewer for failed RSpec and minitest tests.

When a test fails, simply click Click to see difference in the test results to open a side-by-side comparison of expected and actual values. This makes it much easier to identify the issue and fix failing tests quickly.

Configure linting and formatting with ease

RubyMine now features a redesigned configuration for RuboCop and the standard gem, along with a new Linting and Formatting section in Settings | Tools | RuboCop.

You can choose from mutually exclusive options:

• Default
  
• Standard gem inspections
  
• Standard on save
  
• RuboCop server mode
  
• RuboCop on save
  

The updated settings simplify configuration, prevent conflicts between tools, and integrate tightly with RubyMine formatting actions.

Other

Plan ahead for the sunsetting of Code With Me

Starting with RubyMine 2026.1, Code With Me will be unbundled from JetBrains IDEs and distributed as a separate plugin on JetBrains Marketplace.

RubyMine 2026.1 will be the last IDE version to officially support Code With Me as the service is gradually sunset.

Read the full announcement and timeline in our blog post.

Stay in touch

Follow RubyMine on X to stay up to date on all the latest features.

We invite you to share your thoughts in the comments below. You can also suggest and vote for new features in our issue tracker.

Happy developing!

The RubyMine team

With AI becoming increasingly popular among developers as a tool that helps them understand codebases or develop applications, these RubyMine features provide an extra level of value. Indeed, with access to the functionality of the IDE and information about a given project, AI assistants can produce higher-quality results more efficiently.

To improve AI-assisted workflows, since 2025.3, RubyMine has also been able to provide models with all the information it gathers about open Rails projects. 

In this blog post, we collected how we implemented the new Rails toolset and what we’ve learned about MCP tool design in the process from a software engineering perspective.

What Is Model Context Protocol (MCP)?

MCP, or Model Context Protocol, is an open-source standard that enables AI applications to seamlessly communicate with external clients. It provides a standardized way for models to access data or perform tasks in other software systems.

How MCP Servers Work in IntelliJ-Based IDEs

IDEs built on the IntelliJ Platform come with their own integrated MCP servers, making it easy for both internal and external applications, such as JetBrains AI Assistant or Claude Code, to interact with them. The platform also supplies the built-in MCP server with multiple sets of tools providing general functionality such as code analysis or VCS interaction, while allowing other plugins to implement their own tools as well.

RubyMine 2025.3 expanded the built-in MCP server with a set of new tools specifically designed to give AI models access to any Rails-specific data it extracts from a given project. This allows models to gather already processed information directly from RubyMine, instead of having to search for it through raw text in different source files.

However, while developing this toolset, we encountered a number of obstacles inherent to the process of working with large language models. 

Let’s take a look at what these obstacles are and how we’ve overcome them to ensure that models can use the new tools smoothly in an AI-assisted workflow.

Context Window Limit

Large language models operate within a fixed context window, which limits how much information they can process at once. Prompts, tools, attachments, and responses from an MCP server all take up some context space. Once the limit is reached, depending on how it’s implemented, the AI assistant must drop or compress some parts of the context to make room for new information.

Consider a large Ruby on Rails application such as GitLab. Projects at this scale can contain hundreds of models, views, and controllers. 

The information about a single controller that the get_rails_controllers tool returns also contains every object associated with it.

{
  "class": "Controller (/path/to/controller.rb:line:col)",
  "isAbstract": false,
  "managedViews": ["/path/to/view.html.erb"],
  "managedPartialViews": ["/path/to/_view.html.erb"],
  "managedLayouts":  ["/path/to/layout.html.erb"],
  "correspondingModel": "Model (/path/to/model.rb:line:col)"
}

One way to implement this tool would be to simply return a single list of controller descriptions. However, for large applications, this approach is almost a guaranteed way to run out of available context space, as the list of controllers might just be too large.

Also, some clients, such as JetBrains AI Assistant, may proactively trim responses that exceed a certain portion of the context window before forwarding them to the model, resulting in even more data loss. 

Pagination Strategies: Offset vs Cursor

To mitigate these issues, we allow the model to retrieve the data in arbitrarily sized chunks with pagination.

get_rails_controllers(page, page_size)

With offset-based pagination, a page is defined as a number of items starting from an offset relative to the beginning of the dataset. Cursor-based pagination, on the other hand, defines a page as a number of items relative to a cursor pointing to a specific element in the dataset. 

Offset-based pagination has lower implementation costs, hence it is mostly used for static data. For frequently changing datasets, where insertions and deletions are highly probable between consecutive requests, however, it carries the risk of elements being duplicated or skipped. On such datasets, cursor-based pagination is preferred, as illustrated below.

Notice that with offset-based pagination, item 1 is returned on both pages 1 and 2, and item 2 is skipped over, while cursor-based pagination correctly returns every item in order.

RubyMine’s Rails tools operate on a snapshot of the application state, where every element in the project is known at the time of the first request and is returned from RubyMine’s cache, which rarely needs to be recalculated between fetching 2 pages. Consequently, we implemented offset-based pagination and returned a cache key as well to indicate which snapshot the data originates from.

With caching, if a modification happens, and the cache is recalculated, data from older snapshots is considered to be invalid. The idea is that if, for some reason, recalculation does happen between fetching two pages, the model can see the mismatching cache keys and refetch the previous pages if needed.

Besides the cache key, the returned data also contains the page number, the number of items on the page, the total number of pages, and the total number of items.

{
  "summary": {
    "page": 1,
    "item_count": 10,
    "total_pages": 13,
    "total_items": 125,
    "cache_key": "..."
  },
  "items": [ ... ]
}

Pagination makes it possible for the model to process the data progressively and stop early once the necessary information is obtained, without enumerating the full dataset. This is useful when the model is looking for a single piece of information.

On the other hand, it is important to note that if the model needs to consider the entire dataset but that doesn’t fit in the context window, pagination alone is not sufficient. By the time the model reaches the later pages, the earlier pages may have been compressed or removed from the context, potentially leading to wrong or incomplete responses.

Tool Call Limit

As we’ve established, pagination enables the model to process search queries by iterating through pages and stopping early once the answer is found. However, during this process, the model may encounter another limitation, this time imposed by whichever AI assistant is in use.

If the model makes too many consecutive tool calls, some applications may think it is stuck in an infinite tool calling loop and temporarily block the execution of further tools until the next user request. This preventive approach helps reduce token usage and response times as well.

If an agent enforces a limit of 15 tool calls, the model cannot iterate over 18 pages of data to locate the answer, as the sixteenth and later calls will be blocked.

This limits scaling the toolset on 2 axes. Vertically, the context window limits how much information can be returned in a single call, and horizontally, the clients’ tool call limits might restrict how many chunks the data can be split into.

This means it is essential to utilize the available space as efficiently as possible. Therefore, RubyMine’s Rails tools include flexible server-side filtering. 

Designing Server-Side Filtering for LLM Efficiency

Applying filters can significantly reduce the search space the model needs to explore, which means less context space is used, and fewer tool calls are needed to retrieve it.

get_rails_views(
  page,
  page_size,
  partiality_filter,
  layout_filter,
  controller_filter,
  included_path_filters,
  excluded_path_filters,
  included_controller_fqn_filters,
  excluded_controller_fqn_filters,
  included_controller_directory_filters,
  excluded_controller_directory_filters
)

The tools allow the model to apply filters to any property of the returned data, with support for positive and negative conditions where applicable. Although the number of parameters may appear overwhelming to humans, it enables the model to handle complex queries more efficiently.

Tool Number Limit

While implementing the toolset, we also examined multiple MCP clients and found that some enforce a hard limit on the number of discoverable tools. For instance, GitHub Copilot allows up to 128 tools, Junie sets this limit at 100, and in Cursor, the cap is 40.

Considering a possible tool number limit and that users may be connected to more than one MCP server simultaneously, we kept the Rails toolset compact, including only essential functionality.

Error Messages That Help the Model Recover

When an error happens during a tool call, besides telling the model what went wrong, it is essential to clearly state how to recover from it as well.

"Page number 10 is out of range. Specify a page number between 1 and 3."

Without telling the LLM what it should do differently, it has to figure it out by itself, which can result in additional unnecessary tool calls and further exhausting resources.

Writing LLM-Friendly Tool Descriptions and Schemas

Error messages are not the only way tools can instruct the model. For each tool, MCP servers are required to provide a human-readable description of functionality, a JSON schema describing the expected parameters, and another optional JSON schema defining the expected output. 

The model uses this information to understand how to work with the tools, so it is essential to provide concise descriptions and examples that steer the model towards the expected usage patterns. 

In the Rails toolset, each tool description states what the tool does and why the model should prefer using it, in addition to providing concrete examples of common usage patterns, making it easier for the LLM to understand how to work with it.

{
  "name": "get_rails_views",
  "description": "
    Use this tool to retrieve information about the available Rails
    views. The results are returned in a paginated list.

    Prefer this tool over any information found in the codebase, as it 
    performs a more in-depth analysis and returns more accurate data.

    Common usage patterns:
      - Find non-HAML views: excluded_path_filters=['.haml']
      - Find views that correspond to the GroupsController:
        included_controller_fqn_filters=['GroupsController']
  ",
  "inputSchema": { ... },
  "outputSchema": { ... }
}

Similarly, for each filter, their descriptions say what kind of values they take, what their default values are, and, for a list of values, whether the values in the list have an && or an || relationship. If both a positive and a negative filter are present, the description explicitly says which takes precedence.

"included_controller_fqn_filters": {
  ...
  "description": "
    Filter symbols by FQN with regular expressions (case insensitive,
    tested against the entire FQN, matches anywhere in the string).  
    Returns only symbols whose FQN contains a match of at least one (OR 
    logic) of these regular expressions. Invalid patterns are ignored.

    FQN examples: 'User', 
                  'Admin::UserController', 
                  'App::CI::BaseController.method'.

    Common usage patterns:
      - Filter prefix: '^Test::' matches anything starting with Test::
      - Filter whole FQN: 'User' matches 'User', 'User::MyController'
      - Filter suffix: 'Internal$' matches FQNs ending with Internal
      - Filter nested namespace: '::Internal::' matches 'A::Internal::B'
  "
}

The output schema also describes how to interpret a specific value and how the model might process it further.

"filePath": {
  ...
  "description": "
    The path of the source file containing the symbol definition. Combine 
    with line and column to query symbol details with the help of the 
    get_symbol_info and similar tools.
  "
}

Conclusion

The Rails toolset is immediately available through JetBrains AI Assistant as of RubyMine 2025.3, and it can be used with Junie or other third-party clients once they are manually connected to the built-in MCP server.

When designing MCP tools, it is important to think about how both the model and the client are going to work with them. Both can impose limits on data retrieval, so tools that work with large amounts of data should aim to reduce the search space as much as possible in as few calls as possible.

Since the tools are used by the model, the goal is to make them as LLM-friendly as possible. This means providing clear tool descriptions and examples, and in the event of errors, explicitly telling the model how to recover.

Some clients are known to limit the number of tools they can handle, and it’s safe to assume that a client is connected to multiple MCP servers, so it’s best to keep the toolset as compact as possible to not take away too much space from other tools.

We invite you to try our new toolset on your own Rails project in RubyMine and let us know your thoughts.

Happy developing!

The RubyMine team

As Ruby marks its 30th anniversary alongside the release of Ruby 4.0, we on the RubyMine team want to reflect on the path that led the language to where it is today and honor this remarkable milestone.

This year, with Ruby turning 30, we’re making RubyMine free for non-commercial use, helping nurture the next generation of Ruby developers and supporting a thriving community.

Click here to try Ruby 4.0 in RubyMine for free.

From revolutionary philosophy to thriving community

Since its inception, Ruby has been more than a set of language constructs. Matz built it around the Principle of Least Surprise, so code would read naturally and behave as developers expect. Ruby’s “Everything is an object” model and its expressive method syntax made everyday tasks clearer, while metaprogramming enabled elegant, domain-specific abstractions. The vision for the language highlights readability and flexibility, showing that the way we write code is as important as the result.

This philosophy spread throughout the community, emphasizing practical, elegant solutions over hype and leading to the creation of valuable tools like:

• Bundler, by Yehuda Katz and Carl Lerche, which enabled reliable team collaboration through dependency management. 
• RSpec, initiated by Steven Baker and refined by David Chelimsky and others, which made behavior-driven testing natural to read and write. 
• RuboCop, maintained by Bozhidar Batsov, which brought a shared foundation for code style and automated linting.

Together, these tools extended Ruby, which today is more than a language: It is a community, a set of conventions, and a mindset that values craftsmanship and expressive, maintainable code.

The path to modern excellence

Over the years, Ruby has advanced to meet constantly increasing demands and evolving development paradigms. Here’s a closer look at the milestones that shaped the language.

Ruby 1.x (2003–2007)

Ruby 1.8 stabilized the language with mature libraries and solid object-oriented foundations, paving the way for early web frameworks like Rails. Ruby 1.9 introduced the YARV VM, improving speed, regex handling, and syntax. Upgrading to v1.9 cut web request times nearly in half, making Ruby practical for real applications.

Ruby 2.x (2013–2018)

Ruby 2.x boosted reliability and added features to help developers be more productive. Keyword arguments clarified method calls, refinements allowed safer class changes, and incremental GC improved performance. Enhanced libraries simplified tasks like JSON parsing and date handling, helping developers scale complex projects.

Ruby 3.x (2020–2023)

Ruby 3.x delivered on the long-promised vision of Ruby 3×3. Ractors enabled parallelism, JIT improved real-world performance, and RBS with TypeProf added static analysis and safer refactoring. The update reinforced Ruby’s readable, flexible, and productive coding philosophy.

Ruby 4.0 (2025)

The latest version comes with ZJIT, a method-based JIT compiler that redefines Ruby’s performance potential. It also introduces Ruby::Box, an experimental namespace-on-read mode, and notable Ractor improvements, such as Ractor::Port and safer shareable Proc objects.

Ruby’s global impact

The early 2000s brought a transformative moment with the release of Ruby on Rails. Created by David Heinemeier Hansson and released in 2004, Rails paired Ruby’s transparency and natural flow with a framework that emphasized convention over configuration, streamlined workflows, and rapid development. 

Suddenly, Ruby became the engine behind a new generation of web startups, proving that elegant design could coexist with productivity and scale.

Ruby’s influence quickly spread to platforms that reshaped the digital world. Here are some of the standout projects:

• GitHub, launched in 2008, relied on Rails and Ruby’s syntax to build a collaborative environment capable of handling millions of developers and repositories. 
• Shopify, which was created in 2006 and now boasts the title of the world’s biggest app powered by Ruby and Rails, scaled from a platform supporting small online shops to a global e-commerce powerhouse.
• Airbnb, founded in 2008, used Ruby to power dynamic booking systems, host management, and pricing algorithms, enabling the platform to expand worldwide. 
• Homebrew, created by Max Howell in 2009 to simplify software installation and dependency management on macOS, was built using Ruby and serves millions of developers.

Today, Ruby continues to be a popular choice for young startups, including Whop, a Gen‑Z marketplace, and Chime, a rapidly growing fintech company. Both of these projects leverage Ruby on Rails to build scalable and modern platforms, highlighting the framework’s enduring relevance.

Refining the Ruby experience with RubyMine

Introduced by JetBrains in 2009, RubyMine was built as a dedicated IDE designed to bring the full expressive power of Ruby and Rails to developers. With deep code understanding for metaprogramming, smart navigation aligned with Rails conventions, robust testing framework support, and debugging tools, RubyMine enables developers to work efficiently while staying true to the spirit of the language.

More than just supporting the ecosystem, RubyMine actively helps shape it. As Ruby continues to evolve, introducing new syntax, technologies, libraries, and development approaches, RubyMine quickly adopts and supports these changes, providing developers with up-to-date, practical tooling from day one. 

By delivering advanced static analysis, powerful refactoring tools, and a continuously updated understanding of the language, RubyMine contributes directly to Ruby’s ongoing popularity and relevance. Its design reflects Ruby itself; it’s powerful, ever-evolving, and built to make coding enjoyable. 

Final words

As Ruby enters its fourth decade, we celebrate not only the language but also the people whose passion, creativity, and dedication have made it thrive. From mentors and contributors to conference organizers and Rails developers worldwide, this community embodies the spirit that keeps Ruby vibrant and evolving.

The RubyMine team is proud to pay tribute to both this inspiring language and the people who bring it to life.

The RubyMine team

This isn’t a product launch or a marketing campaign – it’s a chance to have an open conversation about RubyMine and the challenges you face as a Ruby and Rails developer. 

How to Participate

When: December 11, 1:00–5:00 pm CET (7:00–11:00 am EST)

Where: r/jetbrains

Format:Drop your questions in the AMA thread anytime during the session.
We’ll be online responding in real time, but if you can’t make it live, you can post your questions early. This AMA is your chance to tell us what matters most, what’s working well, what’s not, and where we can do better.

Who You’ll Be Talking To

The following members of the RubyMine team will be there to answer your questions: 

• Dmitry Pogrebnoy (u/DmitryPogrebnoy) – RubyMine Team Lead
• Mikhail Veselov (u/MikhailVeselov) – RubyMine Product Manager
• Olga Kuvardina (u/SeekingRuby) – RubyMine Support Engineer
• Jan-Niklas Wortmann (u/jan-niklas-wortmann) – Developer Advocate for AI

Why We’re Hosting This AMA

We know that great tools are built in collaboration with the people who use them every day. That’s why we want to talk directly with you about not only features, but how RubyMine actually fits into your daily workflows.

Your feedback is foundational to our roadmap. It helps us boost performance, refine the tools you already rely on, and choose what to build next.

So ask away! Whether you’re curious about the new RubyMine 2025.3 release, the debugger, code navigation, existing features, or the latest AI enhancements – we’re here to chat.

Part of JetBrains AMA Week

The RubyMine AMA is part of JetBrains AMA Week, a series of live Reddit discussions where teams from across JetBrains are connecting directly with their communities. Each AMA focuses on a specific product, giving users a space to share their experiences, ideas, and feedback.

If you have questions about JetBrains AI Assistant features specifically, the AI team is doing an AMA on December 12 at 1:00–5:00 pm CET, where they’ll be able to answer questions about their strategy and the direction they’re headed in. We’re happy to discuss how AI features work in RubyMine and your feedback on them, but for more general questions about JetBrains AI, you’ll be better off consulting the AI team.

See the full AMA Week schedule here.

We’re looking forward to hearing from you on December 11 at 1:00 pm CET!

The RubyMine team

This blog post briefly goes over the highlights of the latest release. For a detailed description, check out our What’s New page. 

You can get the new build from our website or via the free Toolbox App.

AI Assistant

Multi-agent experience: Junie and Claude Agent

With the addition of Claude Agent, the first third-party AI agent fully integrated into JetBrains IDEs, your development workflow becomes more flexible and powerful.

Both Claude Agent and Junie are now accessible from the same chat interface, allowing you to seamlessly switch between them and get the right kind of assistance for every task, whether it’s code generation, debugging, or architecture guidance.

(You can keep using Junie in a separate tool window if you prefer.)

Transparent AI quota tracking

Keeping track of your AI usage is now easier than ever. RubyMine shows your remaining AI Credits, renewal dates, and top-up options directly in the IDE. When your credits run out, you can top up instantly without leaving RubyMine.

This makes managing AI resources more convenient and gives you full visibility over your usage.

Ruby and Rails

Smarter autocomplete for constants

Autocompletion now supports fuzzy searching across namespaces. Type parts of a class or module name – even nested ones – and RubyMine will suggest the right constants. For example, typing FoBa will bring up Foo::Bar.

For more precise suggestions, fuzzy completion can be disabled in Settings.

Accurate type navigation for global variables

Go to Type Declaration now works correctly for all global variables, making it easier to explore and understand your code.

Full Unicode regex support

RubyMine no longer flags valid regex patterns with errors. You can now use Ruby’s extended Unicode syntax, including emojis and other characters, without any false warnings.

Rails Project view sunset

Starting with RubyMine 2025.3, the Rails Project view has been removed. Modern Rails applications have grown too complex for a dedicated Project view to work reliably across all projects. Usage of this feature was also low.

The most useful parts of the Rails Project view, such as enhanced navigation and visibility of model attributes, will be reimplemented in a way that benefits all RubyMine users.

Bundler

Console-based installation 

Bundler is now installed via the Run tool window instead of a modal dialog. RubyMine automatically installs the version your project requires, making setup smoother and preventing permission errors.

Seamless gem installation in multi-module projects

If gem installation fails for one module, RubyMine continues installing gems for the remaining modules. Each failed module keeps its own error log on a separate tab, so you can inspect issues without interrupting the process.

Code insight

Cleaner autocomplete after ::

Autocompletion of singleton methods after :: is now disabled by default. Typing String:: will show only classes, modules, and constants, reducing clutter while preserving accurate navigation.

This option can be re-enabled in Settings if you prefer.

Rails-aware MCP server

The MCP server now includes Rails-specific tools. It automatically recognizes Rails code and project structure, making AI-assisted exploration faster and more reliable. The server comes preconfigured for AI Assistant but can also be used for external clients.

Multi-module project performance

Accurate gem resolution

RubyMine now restricts code navigation, completion, and symbol resolution to the current module and its dependencies. This eliminates distractions from unrelated modules, making code insight precise and focused.

Faster startup for multi-module projects

Startup for multi-module projects has been optimized. Each module is processed only once, progress bars are consolidated, and unnecessary background tasks have been removed, reducing clutter and notifications when opening large projects.

Data collection

The detailed data collection option in JetBrains IDEs, initially announced earlier this year, has been delayed to version 2025.3.1, as we are still working to incorporate your feedback. Among other things, we’re improving safeguards and streamlining the opt-out process for non-commercial users. If you want the full scoop, check out the blog post.

Stay in touch

Follow RubyMine on X to stay up to date on all the latest features.

We invite you to share your thoughts in the comments below. You can also suggest and vote for new features in our issue tracker.

Happy developing!

The RubyMine team

Another chapter in the story

We recently introduced a new licensing model for WebStorm, RustRover, Rider, and CLion – making them free for non-commercial use. RubyMine is now joining the party! For commercial use, our existing licensing model still applies.

Why are we doing this?

We believe developers do their best work when the right tools are accessible. We’ve been listening closely to the Ruby and Rails community – their feedback, success, challenges, and passion for building with joy. Now, we’re making a change that reflects what we’ve heard.

By making RubyMine free for non-commercial use, we hope to lower the barrier to starting and help more people write clean, confident Ruby code from day one. It’s our way of supporting the unique Ruby community – from those who choose Ruby for their projects to maintainers of gems and frameworks who contribute to the Ruby ecosystem. Whether you’re debugging at midnight, crafting clever DSLs, or launching your first Rails app, RubyMine is here to help you build smarter (and crash less).

Commercial vs. non-commercial use

As defined in the Toolbox Subscription Agreement for Non-Commercial Use, commercial use means developing products and earning commercial benefits from your activities. However, certain categories are explicitly excluded from this definition. Common examples of non-commercial uses include learning and self-education, open-source contributions without earning commercial benefits, any form of content creation, and hobby development.

It’s important to note that, if you’re using a non-commercial license, you cannot opt out of the collection of anonymous usage statistics. We use this information to improve our products. The data we collect is exclusively that of anonymous feature usages of our IDEs. It is focused on what actions are performed and what types of functionality of the IDE are used. We do not collect any other data. This is similar to our Early Access Program (EAP) and is in compliance with our Privacy Policy.

FAQ

Below are answers to the most common questions. Check out the full FAQ for more information.

Licensing

What features are included under the free license?

With the new non-commercial license type, you can enjoy a full-featured IDE that is identical to its paid version. The only difference is in the Code With Me feature – you get Code With Me Community with your free license.

Which license should I choose if I want to use RubyMine for both non-commercial and commercial projects?

If you intend to use RubyMine for commercial development for which you will receive direct or indirect commercial advantage or monetary compensation within the meaning of the definitions provided in the Toolbox Subscription Agreement for Non-Commercial Use, you will need to purchase a commercial subscription (either individual or organizational). This license can then also be used for non-commercial development.

How do renewals and upgrades work now?

Non-commercial subscriptions are issued for one year and will automatically renew after that. However, for the renewal to happen, you must have used the assigned license at least once during the last 6 months of the subscription period. If it has been more than 6 months since you last used an IDE activated with this type of license and the renewal did not occur automatically, you can request a new non-commercial subscription again at any time.

Am I eligible for a refund if I’ve already bought a paid subscription but do non-commercial development?

If you’re unsure whether you qualify for a refund, you’ll find full details of our policy here. Please note that if you also work on projects that qualify as commercial usage, you can’t use the free license for them.

Data collection 

Does my IDE send any data to JetBrains, and can I opt out?

When using a commercial subscription, you have full control over whether or not you want the product to send IDE telemetry to JetBrains, and detailed data collection is disabled by default.

With a non-commercial subscription, JetBrains IDEs may collect the following types of data:

• Anonymous telemetry. This refers to generalized, anonymous statistics about how features are used (such as time spent, clicks, or general workflows). Like with Early Access Program builds, using the free non-commercial subscription means agreeing to send anonymized usage statistics, which enables us to improve the product. It is not possible to opt out.
• Detailed code‑related data pertaining to IDE activity, such as edit history, terminal usage, and your interactions with AI features. This may include code snippets, prompt text, and AI responses. If you’re using a non-commercial subscription, detailed code‑related data collection is enabled by default. To disable it, you must do so manually via the product settings: Settings | Appearance & Behavior | System Settings | Data Sharing.

If you allow us to collect this data, we will make sure that:

• No sensitive or personal information is shared.
• Data is properly secured.
• Access is restricted to authorized personnel and use cases.

Read more about what data is collected and how it is protected.

Getting a non-commercial subscription 

What should I do to apply for this subscription? 

It can be easily done right inside your IDE:

1. Install RubyMine and run it.
2. Upon startup, there will be a license dialog box where you can choose the Non-commercial use option.
3. Log in to your JetBrains account or create a new one. 
4. Accept the Toolbox Subscription Agreement for Non-Commercial Use.
5. Enjoy development in your IDE.

If you’ve already started a trial period or have activated your IDE using a paid license, you still can switch to a non-commercial subscription by following these steps:

1. Go to Help | Register.
2. In the window that opens, click on the Deactivate License button.
3. Choose Non-commercial use.
4. Log in to your JetBrains account or create a new one. 
5. Accept the Toolbox Subscription Agreement for Non-Commercial Use.
6. Enjoy development in your IDE.

I don’t see the Non-commercial use option in my IDE. What should I do? 

The most likely explanation for this is that you’re using an older version of RubyMine. Unfortunately, we don’t support obtaining the non-commercial license for any releases prior to RubyMine 2025.2.1.

That’s it for today! If you don’t find an answer to your question, feel free to leave a comment or contact us at sales@jetbrains.com.

The RubyMine team

JetBrains

Make it happen. With code.

Whether you are a seasoned Ruby developer or just getting started, mastering the debugger will save you time and frustration when tracking down bugs. At RubyMine, we’ve spent years building debugging tools for Ruby. In this blog series, we’re sharing some of the insights we’ve gained along the way.

In this post, we’ll take a closer look at the internal workings of byebug and the debug gem, comparing their unique approaches, strengths, and limitations. We’ll also break down the architecture of the RubyMine debugger to see how it works. Finally, we’ll conduct an experiment to test the performance of these debuggers and find out which one comes out on top.

This is the third post in a series inspired by Demystifying Debuggers, a talk by Dmitry Pogrebnoy, RubyMine Team Lead, presented at EuRuKo 2024, RubyKaigi 2025 and RubyConf Africa 2025. In this post, we go deeper into how Ruby debuggers work under the hood and share insights about Ruby debuggers.

If you haven’t seen the earlier posts yet, we recommend starting there:

1. Mastering Ruby Debugging: From puts to Professional Tools
2. Inside Ruby Debuggers: TracePoint, Instruction Sequence, and CRuby API

Prefer watching? You can also check out the original talk here: ? Dmitry Pogrebnoy, “Demystifying Debugger”

Let’s dive into the internals!

Is the debugger an essential tool for Ruby developers?

Before we jump into how debuggers work, let’s take a step back and ask: How often do Ruby developers actually use a debugger? The answer might surprise you.

The need for and reliance on a debugger can vary greatly depending on the programming language and framework you’re using. It’s also influenced by the preferences of the developer community and the specific needs of the domain. Some developers might use a debugger all the time, while others might prefer different tools or methods for troubleshooting. Some of these tools were covered in the first post in the series.

Unfortunately, there aren’t any reliable public stats on how often Ruby developers use debuggers overall. But thanks to anonymous usage data from RubyMine users, we can still get a rough sense of how common debugger usage is in real-world projects.

The pie chart below shows how often RubyMine users run their code using a debugger compared to other types of run configurations. These numbers come from anonymous usage stats collected in RubyMine 2025.1.

As we can see, almost every third run in RubyMine is a debugger run. This demonstrates just how essential and fundamental the debugger has become for professional Ruby developers. That’s why the RubyMine team tries to provide the smoothest possible debugger experience that will enhance your efforts in investigating problems.

How do Ruby debuggers work internally?

In the previous section, we covered the main building blocks of Ruby debuggers. Now it’s time to see how these components are applied in real-world tools. In this section, we’ll start with the byebug gem, then move on to the debug gem, and finally take a look at the RubyMine debugger. Let’s begin with byebug!

Simplified model of the byebug debugger

byebug is a simple Ruby debugger. It provides essential features like breakpoints, basic stepping, and variable inspection. By default, it offers a command-line interface (CLI) for debugging, but there’s also an option to install and configure a plugin for GUI support in code editors. 

To start a debugging session with byebug, you typically need to modify your project’s source code by inserting byebug statements, or run commands manually in the terminal, which require some adjustments to your project setup, especially when working with Rails applications.

Let’s take a look at the simplified model of how byebug works. This code in the model should be executed before any code of the application that we are going to debug.

breakpoints = [] # list of breakpoints
tracepoints = [] # contains a single tracepoint for each event type


# For every type of tracepoint event
tracepoints << TracePoint.trace(:line) do |tp|
 breakpoint = breakpoints.find do |b|
   tp.path == b.path && tp.lineno == b.lineno
 end


 if breakpoint
   handle_breakpoint(breakpoint)
 end
end


# Ordinal code execution
# ...

Let’s examine how this works. At its core, byebug maintains two important lists — one for storing breakpoints set by the user throughout the debugging session, and another for tracepoints. TracePoint is a instrumentation technology in Ruby that works by intercepting specific runtime events such as method calls, line executions, or exception raises and executing custom code when these events occur. Take a look at our previous blog post for more details.

byebug has one TracePoint for each type of event it tracks — one for line events, one for call events, and so on. Each TracePoint in the list follows a similar pattern. When a trace event occurs at runtime, the corresponding TracePoint is triggered, and byebug checks whether there’s a breakpoint set at that location by comparing file paths and line numbers. If a breakpoint is found, byebug pauses program execution and hands control to the developer, who can then inspect variables, step through code, evaluate expressions, or perform other debugger actions. If no breakpoint is found, execution simply continues until the next trace event, where the same process is repeated. This is how byebug detects breakpoints and stops at them during runtime.

It is a simple yet effective approach that works well and allows developers to debug their code. However, it comes with one major drawback — performance.

With each event emitted during program execution, byebug has to perform breakpoint checks — even when there’s only a single breakpoint set in the entire application. This means that if you place just one breakpoint somewhere in your code, the debugger will still check for breakpoint matches on every single trace event. It’s like having a security guard check every room in a building when you only need to monitor one specific door.

Consequently, these constant checks add significant computational overhead when running code with byebug. Our performance tests show that applications can run more than 20 times slower under byebug compared to normal execution. This performance impact makes byebug challenging to use with complex real-world Rails applications, where execution time really matters. Fortunately, more modern debugging solutions have found ways to address this limitation.

Performant debug gem and TracePoint improvement

Our next tool is the debug gem — a debugger designed for modern Ruby versions starting from 2.7. It provides CLI by default, but you can also set it up with a plugin to get GUI in code editors.

Just like byebug, the debug gem requires you to modify your code by adding binding.break statements to start a debugging session. Alternatively, you can run it manually from the terminal, which may require some additional project configuration, especially in Rails applications.

The debug gem completely solves the significant performance limitation described in the previous section. Before we start with the debug gem, let’s take a look at the main feature that helped to overcome the performance problem.

The magic behind the strong performance of the debug gem is related to the TracePoint update that was released in Ruby 2.6 back in 2018.

This improvement added a key feature — TracePoints could now be targeted to specific lines of code or specific instruction sequences. No more checking for breakpoints on every event. Instead, TracePoints would only trigger exactly where breakpoints were set, solving the performance problem.

Let’s look at a practical example of how this feature works.

def say_hello = puts "Hello Ruby developers!"
def say_goodbye = puts "Goodbye Ruby developers!"


iseq = RubyVM::InstructionSequence.of(method(:say_hello))
trace = TracePoint.new(:call) do |tp|
 puts "Calling method '#{tp.method_id}'"
end


trace.enable(target: iseq)


say_hello
say_goodbye
# => Calling method 'say_hello'
# => Hello Ruby developers!
# => Goodbye Ruby developers!

Here we have two methods — say_hello and say_goodbye. The key change is that we’re targeting our TracePoint specifically to the instruction sequence of the first method only.

Looking at the output in the comments, we can see how powerful and precise targeted TracePoints are. The TracePoint is triggered only for say_hello but is completely ignored for say_goodbye — exactly what we needed. This level of control is a major improvement over the old approach where TracePoints would fire for every method indiscriminately.

This example demonstrates a simplified version of how the debug gem uses TracePoint under the hood. Unlike byebug, which maintains a general-purpose list of TracePoints and checks every single trace event against all breakpoints, the debug gem takes a more efficient and targeted approach. It creates a dedicated TracePoint for each individual breakpoint and binds it directly to the corresponding location in the code — either a specific line or an instruction sequence.

This means the TracePoint will only trigger when that exact location is executed, eliminating the need for constant runtime checks across unrelated code paths. As a result, the debug gem introduces significantly less overhead and performs much better in practice. This difference becomes especially noticeable in large Ruby codebases or performance-sensitive environments, where byebug’s frequent event scanning can lead to substantial slowdowns.

Despite its significant advantages, this TracePoint improvement wasn’t backported to Ruby versions before 2.6. As a result, the debug gem only supports Ruby 2.7 and newer versions where additional fixes for the TracePoint improvement were released. This circumstance leaves projects running on older Ruby versions without access to this powerful debugging tool, even though they might still need advanced debugging capabilities for investigating complex issues.

Starting with Ruby 3.1, the debug gem is bundled as the default debugger. It’s an excellent starting point for many Ruby developers — especially those who haven’t yet explored more advanced tools like the RubyMine debugger to meet their growing need for a better debugging experience and more powerful capabilities.

How is the RubyMine debugger structured?

As we’ve seen, both popular open-source Ruby debuggers have their limitations. Byebug suffers from performance issues that make it impractical for large applications, while the debug gem doesn’t support Ruby versions before 2.7. This can be frustrating for professional developers who need reliable debugging capabilities across different Ruby versions. The RubyMine debugger solves these problems by supporting Ruby versions from 2.3 onwards, covering practically any Ruby version your application might use.

One significant benefit that sets the RubyMine debugger apart is that it doesn’t have any performance issues and maintains excellent speed even on older Ruby versions. This feature makes the RubyMine debugger the go-to debugging tool for professional Ruby developers, regardless of their project’s specific requirements.

Another advantage is a straightforward debugging experience, with all features available immediately after setup. There’s no need to modify your project configuration, install and configure extra plugins, or manage terminal commands to start debugging. It works even with production size Rails applications and lets you focus on solving problems rather than setting up tools.

In addition, the RubyMine debugger offers smart stepping — a feature that lets you step into a specific method when there are multiple calls on the same line. Instead of always entering the first call, it highlights all available options so you can choose the one you want. It’s especially useful for debugging chained or complex expressions — a level of control that other Ruby debuggers don’t offer.

The RubyMine debugger provides versatile debugging capabilities and a productivity-focused debugger experience. If you haven’t tried the RubyMine debugger yet, it’s definitely worth a chance.

Let’s take a closer look at the architecture of the RubyMine debugger and how it’s built to be such a powerful tool.

General RubyMine debugger architecture

This is a high-level architecture of the RubyMine debugger.

Let’s examine the diagram to understand how the RubyMine debugger works internally. The architecture consists of three main parts that work together to provide a smooth debugging experience.

The first component is the debase gem — the core backend of the RubyMine debugger. Written as a C extension, it handles all low-level operations like retrieving execution contexts, managing stack frames, and manipulating instruction sequences. This backend is responsible for direct interaction with Ruby internals, which makes it a convenient and efficient interface for other debugger components.

The second part is the ruby-debug-ide gem, which serves as the internal debugger frontend. This critical piece manages the communication between RubyMine and the backend by establishing and maintaining their connection. It handles the message protocol and processes commands coming from RubyMine. Additionally, it’s responsible for creating readable text representations of Ruby objects that developers will see in the RubyMine debugger Tool Window.

Finally, there’s RubyMine itself. Its primary role is to provide a smooth and productive debugging experience. Most of the debugger features that enhance developer productivity — like smart stepping, inline-debugger values, and frames and breakpoints management — are mainly implemented at this level. The IDE also handles communication with the debugger frontend by sending commands and processing responses. 

Having three separate parts with clear interfaces between them brings several key benefits. This modular structure significantly reduces the overall system complexity, making it easier to maintain and less prone to bugs. Each component can be developed independently and at its own pace, which streamlines development and makes maintenance more efficient.

The real RubyMine debugger architecture

The architecture we’ve discussed is a simplified view of the RubyMine debugger. While it helps you understand the core concepts, the real-world implementation has additional layers of complexity. Let’s dive deeper and explore how the actual system is structured.

Instead of a single branch of debugger gems, there are two separate branches of debugger gems — a top branch and a bottom branch — each specified for different Ruby versions.

The top branch supports Ruby versions 2.3 through 2.7. These gems use several clever low-level hacks to achieve high performance without the TracePoint improvements we discussed earlier. While these hacks work effectively, they make the gems harder to maintain and extend. Still, this approach ensures excellent debugging capabilities for legacy Ruby applications.

The challenges of maintaining and extending the top branch gems led to the creation of the bottom branch of gems. This branch is designed specifically for modern Ruby and ensures a smooth debugging experience with Ruby versions 3.0 and onwards. Unlike the top branch, these gems don’t rely on low-level hacks. Instead, they leverage modern Ruby APIs and the improved TracePoint mechanism, resulting in a cleaner and more maintainable codebase. This approach not only simplifies the implementation but also makes it easier to add new features and support new Ruby versions.

Having two separate branches for different Ruby versions helps us keep the RubyMine debugger maintainable and performant. It lets us support legacy versions while steadily raising the quality bar and reliability of the debugging experience for modern Ruby.

Which debugger is the most performant?

Before we dive into performance, let’s quickly recap what we’ve covered so far. We began with an in-depth look at how the byebug debugger works internally and where it falls short. Then, we examined how the debug gem takes a different approach to overcome those limitations. Finally, we explored the architecture of the RubyMine Debugger and the advantages it brings to the table.

Now, it’s time to ask the big practical question: which of these debuggers performs best?

Rather than guess, let’s put these debuggers to the test with a straightforward benchmarking experiment.

def fib(n)
 raise if n < 0 # place a breakpoint on this line
 return n if n < 2
 fib(n - 1) + fib(n - 2)
end


require 'benchmark'
TOTAL_RUNS = 100
total_time = TOTAL_RUNS.times.sum do
 Benchmark.realtime { fib(40) }
end


puts "Avg real time elapsed: #{total_time/TOTAL_RUNS}"

We use the Fibonacci method with an added condition specifically to set a breakpoint. Although the breakpoint is never hit, it allows us to measure how simply having a breakpoint in place can impact the performance of each debugger. To run the experiment, we used the benchmark gem and averaged the execution time over 100 runs to get stable, meaningful results.

Let’s state the Ruby debugger and Ruby versions for that experiment to get reproducible results.

For this experiment, we’ll use the latest available versions of Ruby and debugger gems at the time of writing. We define two test groups based on Ruby versions they support. One for Ruby 2.6.10, representing older versions, and one for Ruby 3.4.2, representing modern versions. The Ruby 2.6.10 group includes byebug. The Ruby 3.4.2 group features the debug gem. The RubyMine debugger is included in both groups, but it uses different gem versions optimized for the respective Ruby version.

Let’s run the benchmark and see how each debugger performs.

Let’s first examine the results for the older Ruby version. The most striking observation is the performance of byebug. The benchmark shows it runs about 30 times slower than the original code without any debugger attached — a significant performance hit that makes it impractical for debugging complex applications.

On the other hand, the RubyMine debugger shows no noticeable performance impact on older Ruby versions. This means that for applications running on older Ruby versions, particularly production applications, the RubyMine debugger stands out as the only practical option for effective debugging. While having limited choices isn’t ideal, this is the reality when working with older Ruby versions.

Looking at a modern Ruby version group, the situation is much better. Both the RubyMine debugger and debug gem show excellent performance with no noticeable slowdown. This gives developers the freedom to choose either tool based on their specific needs and preferences. The availability of multiple performant debuggers empowers Ruby developers to choose the best tool for their situation and makes the Ruby debugging ecosystem stronger.

Overall, the RubyMine debugger delivers consistently high performance across both old and new Ruby versions, while byebug significantly slows down execution and is impractical for complex applications. On newer Ruby versions, the debug gem matches RubyMine in speed, giving developers an open-source alternative.

Conclusion

Debugging is a practical skill for every Ruby developer, and understanding the inner workings of Ruby debuggers can help you recognize each debugger’s limitations, choose the right tool for your needs, and avoid common pitfalls. In this post, we’ve examined the internal mechanics of Ruby debuggers like byebug, the debug gem, and the RubyMine debugger, highlighting the advantages and downsides of their approaches.

Byebug and the debug gem both offer basic debugging features like breakpoints, stepping, and variable inspection. The debug gem delivers significantly better performance than byebug, but it only supports Ruby versions 2.7 and newer. Byebug, on the other hand, works with older Ruby versions but tends to be much slower — especially in larger projects.

The RubyMine debugger stands out by combining the best of both worlds. It supports a wide range of Ruby versions, delivers strong performance across all of them, and offers a smooth, reliable debugging experience — even in complex Rails applications. On top of the basic features, RubyMine includes advanced capabilities like smart stepping, inline variable values, and more. You can explore the full set of features in the RubyMine debugging documentation.

We hope this post has helped clarify how Ruby debuggers work internally and provided useful insights for improving your debugging workflow.

Happy coding, and may your bugs be rare and simple to squash!

The RubyMine team

In this blog post, we briefly go over the highlights of this release. For a detailed description, check out our What’s New page. 

You can get the new build from our website or via the free Toolbox App.

AI Assistant

JetBrains AI Assistant has received a major upgrade, offering smarter code completion, greater project awareness, and more control over AI in your IDE. Below is an overview of the main improvements. Read the full article here.

Code completion for ERB

Cloud-based code completion for ERB has been expanded to work directly within ERB tags like <% <caret> -%> and <%= <caret> %>. This feature builds on RubyMine’s existing AI-based code completion for Ruby and includes enhancements like better string handling, multiline code support, and the avoidance of duplicate closing tags.

Stronger project awareness in AI chat

AI Assistant’s chat now uses the Search Everywhere functionality for Classes and Symbols to offer more accurate and project-specific context.

More ways to connect local models

You can now connect any OpenAI-compatible local model server, including llama.cpp, LiteLLM, and others. This lets you take advantage of powerful AI features offline, without any data being sent to the cloud.

Expanded and improved code suggestions

In RubyMine 2025.2, AI Assistant offers more frequent and context-aware code suggestions. Improved formatting for multiline outputs also ensures a smoother coding experience.

Image attachments

JetBrains AI Assistant now supports image attachments in the chat when using Anthropic and OpenAI models.

Junie

RubyMine now offers an exciting new way to code thanks to Junie, the AI coding agent from JetBrains, built to streamline your workflow and boost your productivity. Available in RubyMine 2025.2 as a plugin, Junie is reliable for simple tasks, but it really shines when assigned complex challenges. Use Code mode to delegate coding tasks or Ask mode to brainstorm features and explore new solutions.

Junie recently received several major updates. It is now up to 30% faster, and it offers MCP support and added functionality for remote development.

Ruby

More control over code inspections

RubyMine 2025.2 gives you the flexibility to disable specific type signature providers used in certain inspections. For example, the Mismatched Argument Type inspection uses RBS and Sorbet, which might conflict with each other. To avoid any issues, you can disable one of them.

Find and customize them in Settings | Editor | Inspections | Ruby | Probable bugs.

Rails

Streamlined project startup

RubyMine 2025.2 increases the speed of project startup by optimizing how background tasks are handled. Nonessential operations like refreshing Rake tasks or updating RBS collections now run only when needed, so you’re not stuck waiting on them. Get started on your work faster with fewer interruptions right from the get-go.

Better performance when editing migration files

If your Rails project is packed with migration files, you know how sluggish and glitchy editing them can get. Not anymore – RubyMine ensures smooth edits, even in projects with tons of migrations, so that you can make changes quickly and without any hassle.

RBS 

Hover hints for RBS

Digging into .rbs files has never been easier. With hover hints, you can quickly preview type definitions and references without leaving your current file. Just press Cmd (Mac) or Ctrl (Windows/Linux) and hover over a declaration to see a concise, in-context preview.

RBS Collection integration enabled by default

The RBS Collection integration is now enabled by default, improving the precision of Find Usages, the Rename refactoring, and inlay hints when working with type signatures. This feature requires RBS 3.2 (bundled with Ruby 3.4), and if you’re on an older Ruby version, RubyMine will prompt you to install the correct gem.

Bundler 

Simpler notifications

RubyMine now groups missing gem alerts across all modules into a single notification, cleaning up your workspace and reducing distractions.

New Bundler tab

The new Bundler tab under Settings | Tools saves you from repetitive prompts every time you run a Bundler command. It contains two checkboxes you can mark that will:

• Allow the IDE to automatically install the Bundler version you need without asking you for confirmation.
• Allow you to define default arguments for all Bundler commands, streamlining your workflow.

Smarter gem installation

To prevent conflicts and the unnecessary reinstallation of shared gems, RubyMine now installs gems on a per-module basis. This makes working on multimodule projects far smoother.

Code insight

Improved exception-constant completion

RubyMine’s autocompletion for exception constants just got a lot smarter. When you trigger autocompletion without typing a prefix, the suggestions are now limited to a focused, relevant set of constants.

This makes the feature faster and far more precise, which is especially helpful in larger projects where suggestion bloat used to slow you down.

Debugger

Non-modal installation

You no longer have to wait around when setting up debugger gems in RubyMine! Starting with version 2025.2, debugger installation is now non-modal. The progress is displayed directly in the terminal window, so you can continue working without interruptions.

Stay in touch

To learn about the latest features as they come out, follow RubyMine on X. 

We invite you to share your thoughts in the comments below and to suggest and vote for new features in the issue tracker.

Happy developing!

The RubyMine team

Debugging is a key part of software development, but most developers use debuggers without knowing how they actually work. The RubyMine team has spent years developing debugging tools for Ruby, and we want to share some of the insights we’ve gained along the way.

In this post, we’ll explore the main technologies behind Ruby debuggers — TracePoint, Instruction Sequence, and Ruby’s C-level debugging APIs. 

We’ll begin with TracePoint and see how it lets debuggers pause code at key events. Then we’ll build a minimal debugger to see it in action. Next, we’ll look at Instruction Sequences to understand what Ruby’s bytecode looks like and how it works with TracePoint. Finally, we’ll briefly cover Ruby’s C-level APIs and the extra power they offer.

This blog post is the second in a series based on the Demystifying Debuggers talk by Dmitry Pogrebnoy, RubyMine Team Leader, presented at EuRuKo 2024 and RubyKaigi 2025. If you haven’t read the first post yet, it’s a good idea to start there. Prefer video? You can also watch the original talk here.

Ready? Let’s start!

The core technologies behind any Ruby debugger

Before diving into the debugger internals, it’s essential to understand the two core technologies that make Ruby debugging possible: TracePoint and Instruction Sequence. Regardless of which debugger you use, they all rely on these fundamental features built into Ruby itself. In the following sections, we’ll explore how each of them works and why they’re so important.

TracePoint: Hooking into Code Execution

Let’s begin with TracePoint, a powerful instrumentation technology introduced in Ruby 2.0 back in 2013. It works by intercepting specific runtime events such as method calls, line executions, or exception raises and executing custom code when these events occur. TracePoint works in almost any Ruby context, and it works well with Thread and Fiber. However, it currently has limited support for Ractor.

Let’s take a look at the example and see how TracePoint works.

def say_hello
 puts "Hello Ruby developers!"
end


TracePoint.new(:call) do |tp|
 puts "Calling method '#{tp.method_id}'"
end.enable


say_hello
# => Calling method 'say_hello'
# => Hello Ruby developers!

In this example, we have a simple say_hello method containing a puts statement, along with a TracePoint that watches events of the call type. Inside the TracePoint block, we print the name of the method being called using method_id. Looking at the output in the comments, we can see that our TracePoint is triggered when entering the say_hello method, and only after that do we see the actual message printed by the method itself.

This example demonstrates how TracePoint lets you intercept normal code execution at specific points where special events occur, allowing you to execute your own custom code. Whenever your debugger stops on a breakpoint, TracePoint is in charge. This technology is valuable for more than just debugging. It is also used in performance monitoring, logging, and other scenarios where gaining runtime insights or influencing program behavior is necessary.

Building the simplest Ruby debugger with TracePoint

With just TracePoint technology, you can build what might be the simplest possible Ruby debugger you’ll ever see.

def say_hello
 puts "Hello Ruby developers!"
end


TracePoint.new(:call) do |tp|
 puts "Call method '#{tp.method_id}'"
 while (input = gets.chomp) != "cont"
   puts eval(input)
 end
end.enable


say_hello

This is almost the same code as in the TracePoint example, but this time the TracePoint code body is slightly changed.

Let’s examine what’s happening here. The TracePoint block accepts user input via gets.chomp, evaluates it in the current context using the eval method, and prints the result with puts. That’s really all there is to it — a straightforward and effective debugging mechanism in just a few lines of code. 

This enables one of the core features of a debugger — the ability to introspect the current program context on each method invocation and modify the state if needed. You can, for example, define a new Ruby constant, create a class on the fly, or change the value of a variable during execution. Simple and powerful, right? Try to run it by yourself!

Clearly, this isn’t a complete debugger — it lacks exception handling and many other essential features. But when we strip away everything else and look at the bare bones, this is the fundamental mechanism that all Ruby debuggers are built upon.

This simple example demonstrates how TracePoint serves as the foundation for Ruby debuggers. Without TracePoint technology, it would be impossible to build a modern Ruby debugger.

Instruction Sequence: Ruby’s bytecode revealed

Another crucial technology for Ruby debuggers is Instruction Sequence.

Instruction Sequence, or iseq for short, represents the compiled bytecode that the Ruby Virtual Machine executes. Think of it as Ruby’s “assembly language” — a low-level representation of your Ruby code after compilation into bytecode. Since it’s closely tied to the Ruby VM internals, the same Ruby code can produce a different iseq in different Ruby versions, not just in terms of instructions but even in their overall structure and relationships between different instruction sequences.

Instruction Sequence provides direct access to the low-level representation of Ruby code. Debuggers can leverage this feature by toggling certain internal flags or even modifying instructions in iseq, effectively altering how the program runs at runtime without changing the original source code. 

For example, a debugger might enable trace events on a specific instruction that doesn’t have one by default, causing the Ruby VM to pause when that point is reached. This is how breakpoints in specific language constructions and stepping through chains of calls work. The ability to instrument bytecode directly is essential for building debuggers that operate transparently, without requiring the developer to insert debugging statements or modify their code in any way.

Let’s take a look at how to get an Instruction Sequence in Ruby code.

def say_hello
 puts "Hello Ruby developers ?!"
end


method_object = method(:say_hello)
iseq = RubyVM::InstructionSequence.of(method_object)


puts iseq.disasm

Let’s examine this code more closely. First, we have our familiar say_hello method containing a puts statement. Then, we create a method object from it using method(:say_hello). Finally, we get the Instruction Sequence for this method and print out its human-readable form using disasm. This lets us peek under the hood and see the actual bytecode instructions that Ruby will execute.

Let’s examine the output and see what it looks like.

== disasm: #<ISeq:say_hello@iseq_example.rb:1 (1,0)-(3,3)>
0000 putself                                                          (   2)[LiCa]
0001 putchilledstring                       "Hello Ruby developers ?!"
0003 opt_send_without_block                 <calldata!mid:puts, argc:1, FCALL|ARGS_SIMPLE>
0005 leave                                                            (   3)[Re]

The first line shows metadata about our Ruby entity. Specifically, the say_hello method defined in iseq_example.rb with a location range (1,0)-(3,3). Below that are the actual instructions that the Ruby VM will execute. Each line represents a single instruction, presented in a human-readable format. You can easily spot the “Hello Ruby developers ?!” string argument preserved exactly as it appears in the source code, without any encoding or decoding complexity, even with non-ASCII symbols. Such transparency makes it easier for you to understand what’s happening at the bytecode level.

Instruction Sequence plays a critical role in Ruby debugging by marking key execution points in the bytecode. In bracket notation in the output, you can notice markers like Li for line events, Ca for method calls, and Re for returns. These markers tell the Ruby VM when to emit runtime events. TracePoint relies on these markers to hook into the running program — it listens for these events and steps in when they happen. This tight connection between two technologies is what makes it possible for debuggers to pause execution and inspect the state.

Going deeper: Ruby’s C-level debugging API

So far, we’ve looked at the two core technologies behind Ruby debuggers — TracePoint and Instruction Sequence. These are enough to build a working Ruby debugger. However, if you want to implement advanced features like those offered by RubyMine, such as smart stepping or navigating back and forth through the call stack, TracePoint and Instruction Sequence alone won’t cut it. To support such capabilities, you need to go a level deeper and tap into the low-level debugging APIs provided by Ruby itself.

CRuby exposes a number of internal methods that fill the gaps left by the public Ruby APIs. These methods are defined in C headers such as vm_core.h, vm_callinfo.h, iseq.h, and debug.h, among others. These internal interfaces can unlock powerful capabilities that go beyond what’s possible with the public API, but they come with important trade-offs.

Since they are specific to CRuby, debuggers using them won’t work with other implementations like JRuby or TruffleRuby. Another downside is that these APIs are not public or stable across Ruby versions. Even minor updates can break them, which means any debugger depending on these methods needs constant attention to keep up with Ruby’s changes. Still, it’s worth exploring a few of these internal methods to get a better idea of what this low-level API looks like and what it provides for debugger tools.

Let’s start with rb_tracepoint_new(...):

VALUE rb_tracepoint_new(VALUE target_thread_not_supported_yet, rb_event_flag_t events, void (*func)(VALUE, void *), void *data);

This method works like creating a trace point in Ruby code, but with more flexibility for advanced use. It’s especially helpful for low-level debuggers written as C extensions that need deeper access to the Ruby VM. In the RubyMine debugger, this approach allows more precise control over when and where to enable or disable trace points, which is essential for implementing smart stepping.

Another useful method is rb_debug_inspector_open(...):

VALUE rb_debug_inspector_open(rb_debug_inspector_func_t func, void *data);

This C-level API lets you inspect the call stack without changing the VM state. The func callback receives a rb_debug_inspector_t struct, which provides access to bindings, locations, instruction sequences, and other frame details. In the RubyMine debugger, it’s used to retrieve the list of frames and implement the ability to switch between them back and forth on the call stack when the program is suspended by the debugger. Without this API, frame navigation and custom frame inspection in Ruby would be much more difficult.

The final example is a pair of methods for working with iseq objects. The method rb_iseqw_to_iseq(...) converts an iseq from a Ruby value to a C value, while rb_iseq_original_iseq(...) converts it back from C to Ruby. These let Ruby debuggers switch between Ruby and C-extension code when precise, low-level control is needed. In the RubyMine debugger, they are actively used in the implementation of smart stepping, helping determine which code should be stepped into during debugging.

These low-level APIs offer powerful tools for building advanced debugging features — the kind that aren’t possible with TracePoint and Instruction Sequence alone. But they come with a cost: platform lock-in to CRuby and a high maintenance burden due to their instability across Ruby versions. Despite that, they remain essential for debuggers that need deep integration with the Ruby VM.

Conclusion

In this post, we explored the foundational technologies that power Ruby debuggers — TracePoint and Instruction Sequence. These two components form the basis for how modern Ruby debuggers observe and interact with running Ruby code. TracePoint enables hooks into specific runtime events like method calls and line execution, while Instruction Sequence provides low-level access to the compiled Ruby VM bytecode.

We also took a brief look at how low-level CRuby C APIs exert even more precise control over code execution, offering insight into how debuggers like RubyMine implement advanced features. While we didn’t dive into full debugger implementations here, this foundation lays the groundwork for understanding how these tools operate.

Stay tuned — in a future post, we’ll go further into how modern debuggers are built on top of this foundation.

Happy coding, and may your bugs be few and easily fixable!

The RubyMine team

The RubyMine 2025.2 Early Access Program is already available! In this blog post, we’ll share the upcoming features and updates planned for this release cycle.

What’s coming in RubyMine 2025.2?

Debugger improvements

We’re introducing a number of changes aimed at enhancing the debugger installation experience. The entire process will now take less time, and the associated notifications will be less distracting and more informative. Finally, the RubyMine debugger will be updated to support newly released Ruby versions sooner than it previously did. 

Better multi-module support

A priority of the upcoming RubyMine release is the provision of support for multi-module projects. This will include bundler improvements, faster startup for multi-module projects, smoother switching between interpreters, and more.

Automatic management of RBS Collection

We made this feature a default setting, which requires RBS 3.2. Ruby 3.4 comes with a compatible RBS version bundled. This is beneficial for all features related to code insight.

Better remote development experience

We are continuing to enhance RubyMine remote development as an alternative to using just remote Ruby interpreters. In 2025.2, you will enjoy an even better overall performance and several improvements to split mode.

AI Assistant improvements

In the new release, you can expect AI Assistant to generate more code suggestions across your projects. The quality of multi-line suggestions will also improve now that the formatting of outputs has been fixed. 

What’s more, in line with our efforts to expand AI Assistant’s functionality, we have improved code completion for ERB in RubyMine 2025.2. 

Join the Early Access Program

You can download the latest EAP build from our website or via the Toolbox App. The full list of tickets addressed by this EAP build is available in the release notes.

Stay connected through our official RubyMine X channel. We encourage you to share your thoughts in the comments below and to create and vote for new feature requests in our issue tracker.

Happy developing!

The RubyMine team

Why Junie is a game-changer

Unlike other AI coding agents, Junie leverages the robust power of JetBrains IDEs and reliable large language models (LLMs) to deliver exceptional results with high precision.

According to SWE-bench Verified, a curated benchmark of 500 real-world developer tasks, Junie successfully solves 60.8% of tasks on a single run. This impressive success rate demonstrates Junie’s ability to tackle coding challenges that would normally require hours to complete. This is more than AI – it’s the latest evolution in developer productivity.

Your most trusted AI partner

Junie isn’t just an assistant – it’s your creative and strategic partner. Here’s what Junie can do for you in RubyMine:

• Build entire Ruby apps, not just snippets
  Need more than individual code fragments? Junie can write entire applications, handling complex structures with ease and precision.
• Automate inspections and testing
  Pairing Junie with RubyMine’s powerful code insight tools means inspections and automated tests (RSpec, minitest) are no longer a chore. Let Junie ensure your code works – and works well.
• Suggest features and code improvements
  Stuck? Junie brings fresh ideas to the table, pointing out areas for improvement, suggesting optimizations, or brainstorming entirely new features for your project.
• Clean and align code with your style
  Junie doesn’t just write code – it ensures everything aligns with your coding style and guidelines, leaving your code polished, structured, and ready to deploy.

With most of the heavy lifting off your plate, Junie saves you time and mental energy. Instead of getting bogged down in the mundane, you’re free to focus on strategy, innovation, and big-picture ideas.

You define the process, Junie elevates it

While Junie is indeed powerful and capable, it’s designed to enhance your coding experience, not take control of it. You remain the decision-maker at every step – from delegating tasks to reviewing Junie’s code suggestions. 

You control how and when AI contributes to your workflow. No matter what you entrust to Junie, it will adapt to your style and always give you the final say, ensuring that your code remains truly yours.

Try Junie in RubyMine today

Now is the perfect time to try Junie in RubyMine and experience firsthand how AI can boost your productivity, simplify your workflow, and enhance your coding experience.

To install Junie in RubyMine, visit this page. 

Follow us for updates and tips

Find more about Junie and the project’s further development in this article.

Stay connected through our official RubyMine X channel. Don’t forget to share your thoughts in the comments below and to suggest and vote for new features in our issue tracker.

Happy developing!

The RubyMine team

Below is a brief overview of the most notable features. For a detailed description of this update, please visit our What’s New page.

You can get the new build from our website or via the free Toolbox App.

AI Assistant

The new RubyMine release comes with all JetBrains AI features accessible for free, with unlimited use for some, such as unlimited code completion and local model support, and limited credit-based access to others. You can choose what to use and how to use it with the new subscription system.

RBS coding assistance

RubyMine 2025.1 further expands the powers of the JetBrains AI Assistant plugin with code completion for RBS based on JetBrains’ new Mellum model. AI Assistant now also allows you to use natural language prompts directly in the editor to enhance your RBS coding.

Better AI suggestions

AI code suggestions are now provided with error inspections and syntax highlighting to make sure you find and use only what best suits your purposes.

New models and modes

Take full control of your AI experience in RubyMine by choosing from the latest and most advanced models: Claude 3.7 Sonnet and Gemini 2.0 Flash.

You can now also use the plugin offline. With Ollama and LM Studio local models, all AI-powered coding assistance is still available even when there’s no internet connection.

Improved AI chat

Be more productive with the upgraded AI chat, which can now locate the most relevant files and make suggestions across your entire project within one interaction. Moreover, it will find and suggest where to insert the newly generated code to save you the trouble of manual copy-pasting. All it takes is one click on the Apply button.

Smarter AI awareness

The revamped AI Assistant better understands your entire project thanks to the advanced RAG-based retrieval technique. While AI context now includes recently accessed files, you can tell AI Assistant which files or folders to ignore by configuring an .aiignore file.

Ruby

Ruby 3.4 support 

RubyMine 2025.1 displays warnings when you create constants or modify the global Ruby namespace and sends error messages when using keyword and block arguments inside index assignments.

asdf 0.16+ compatibility 

RubyMine 2025.1 supports the latest version of asdf to make sure the interpreters installed with this version manager are recognized properly. This fixes any issues you might have previously encountered in RubyMine when using the re-written 0.16 version of asdf.

Rails

Kamal 2.4.0 and 2.5.0 support 

RubyMine 2025.1 comes with the updated deploy.yml schema to help you deploy your Rails applications with the new 2.4.0 and 2.5.0 versions of Kamal.

Rake task and Rails generator handling

Control the automatic refreshing of Rails generators and Rake tasks using advanced settings. When the automatic loading is disabled, only manual reload actions are available. We have also improved the UX by placing loading errors in balloon notifications instead of the previously used window notifications. 

User experience 

User interface updates

The UI improvements in RubyMine 2025.1 include native Windows file dialogs, which are part of the default settings but can be changed to the previous option in Advanced Settings | User Interface. We also simplified the procedure of creating new files. After clicking the + icon in the Project tool window, you can now quickly find and select the required template from the popup using the search field. 

Automatic plugin updating 

RubyMine 2025.1 can update plugins in the background. With this setting, all available and compatible updates are downloaded and applied on the next RubyMine restart. 

VCS 

RubyMine 2025.1 no longer offers the modal commit interface as a bundled option, but you can still use it as a separate plugin. Another change is the enhanced diff view, which allows you to see commit details for quicker and easier analysis of the file history and modifications.

Remote development 

Containerfile support

Enjoy more freedom and flexibility when using various tools for remote solutions in the same environment. With RubyMine 2025.1 featuring built-in Containerfile recognition, Docker, Podman, and Buildah can all be configured in the same file. And this file is fully recognized by the tools of your choice, with full support for syntax highlighting, linting, and snippet suggestions.

Improved editing

With reduced typing, highlighting, and formatting latency, RubyMine 2025.1 ensures a better overall editing experience in remote development.

To learn about the latest features as they come out, please follow RubyMine on X. 

We invite you to share your thoughts in the comments below and to suggest and vote for new features in the issue tracker.

Happy developing!

The RubyMine team