- JetBrains — My wishlist
I've been a JetBrains customer for probably close to 20 years. First IntelliJ IDEA, then when I switched to Ruby, RubyMine, of course, but when AI coding agents started to pop up RubyMine presented it in a way that looked somehow dated, behind, and potentially charge for extra. I still use RubyMine once in a while, but I've been experimenting with multiple languages and so Cursor and Zed have replaced the tools I once used. I will admit I've only used WebStorm and the DataGrip — great tools both of them, and in general your tools are top notch.
Innovation is hard. You've been innovating IDEs for 20 years and we (engineers) have noticed. Hell yes. But as per usual pattern, enormous changes within the industry create a ripple effect that sends waves and affects literally everyone. You are not an exception.
The majority of engineers I know switched away from RubyMine quite a while ago, because they wanted to use AI features of Cursor with Claude or ChatGPT/Codex models, etc. At some point I saw some AI offering in RubyMine, but it didn't seem free or even as cheap as cursor ($20/month), plus I've never heard of that model and didn't care to try it.
Eventually we switched to Claude CLI, Codex CLI, running in parallel in multiple folders.
Then came the orchestrators: that run swarms of agents. I recently left my agent swarm running overnight. It was building a complicated feature. I was certain it will break in the middle and need my input. Turns out — no. I gave it enough harness (how to run tests, linters, typechecks) and made it create a Cypress E2E suite, that the AI was able to loop until these were all passing and green. 🟢
And now there Zed — the IDE writen in Rust that flies compared to Java-based IDEs. SO this is your once in a lifetime chance.
Caution
Why? Because you need to pull ahead of vscode, cursor and zed. And these folks aren't stopping either. So it's going to be hard, very hard.
Because you need to offer things that nobody is currently offering, unique and powerful enough that people will want to switch back to RubyMine in a heartbeat.
Note
Everything here relates the same way to all other JetBrains IDEs.
There are seveal ways to do this and I will enumerate these brilliant ideas for you to think if it's feasible or not.
Java is dead.
And, unfortunately, and very much unlike in "Pulp Fiction", Zed's not dead. Not dead at all.
Back in late 2000s, when JetBrains released IDEs for Mac and Windows Desktop written in Java (or Kotlin, whatever) — they felt surprisingly snappy. Many of us were shocked. Many subscribed just because of that. Many gave up Eclipse because of that.. Over the years it remained relatively snappy, particularly for large apps, and if you give it half of your laptop's RAM.
But Java is going to a nursing home. Rust is fast, memory safe, multi-core enabled, and people are doing amazing things with Ratatui.rs and other libraries.
And Zed Editor proved that Rust can produce UI-rich editor that's also blazing fast.
You must have so much slope in your 20-year Java/Kotlin codebase. Start from scratch. I kid you not. You know what people use, focus on that. Less used features, screw them. You'll add them later.
So, for the love of performace, quick and helpful IDEs, my firm belief is that to remain relevant you guys need to rewrite your core in Rust. And then build language-specific — either installable extensions, OR precompiled binaries with each language built in. Although we all know the developers prefer the first model.
Finally, assuming you release one IDE (Artificial IntelliJ — Bright IDEA) that can pull in Ruby, Python, Go, C++, CMake, TypeScript, JavaScript, ReactJS, etc — all in one monorepo project because that's what today's projects look like.
Sorry for a TV reference, but it fits.
This will help developers to go to sleep right after launching a long-running multi-agent, multi-step workflow (one or more per IDE instance) with some guardrails, with continuous testing and linting, with a self critique agent, strict for clean design agent, readabiliy agent, and the right level of abstractions agent, review agent. You must allow the developers tell each IDE instance (one instance per git-project top level directory) what needs to be run to verify that things are not going haywire. Whether it's bundle exec rspec or it's rubocop or maybe you have whole bunch of formatters in lefthook.yml, leave a list of commands that verify everything.
If you are like me and that command is just ci, then perhaps you are not as ..., well we all have our moments 😊
If you let Night Agent DO something at night, not juts write pretty documents, it should ALSO update the relevant documentation because nothing goes out of sync with reality faster than the markdown files written by developers six months ago. So part of Night Agent's jobs (or one of it's subagents) must find relevant markdown files, worst case — create a README.md per folder, and make sure that it contains up-to-date current information that no longer mentions something that was fixed, and maybe mentions something that is now working better and different.
What separates a great Cursor/Claude experience from a shitty one is the intention put into creating a PLAN for the task. Essentially, my job a senior engineer, is to break a large feature into smaller implementation chunks that are much easier to understand, much clearer to each agent that receives the output of the previous Agent to perform. This can be done in cooperation with an agent while you are still not sleeping 😉
Right now I have to be super specific as not to end up with 💩
The smarter the AI, the better it should undrestand semi-ambiguous tasks, because it has the advantage of scanning the entire repo for similar patterns, perhaps some of the code is already available somewhere. The multi-agent workflow uses markdown files to go through each item and wrap it up with complete implementation, new tests, UI tests using Cypress or something else, basically do it like a brilliant engineer in a corner that everyone hates because he's so much better than them.
Inline refactoring currently sucks ass in Cursor, but could always be done so much better in RubyMine. You select the block of code that's ugly and that you want to extract to a function or refactor. Press Cmd-A-R (I think Cmd-A should just be a consistent prefix for all AI commands), and the agent starts refactoring the code in place, showing you the diff of the old and the new with "Accept" and "Reject" buttons (per block, and one globally), as well as "Modify" for manually modifying the AI-generated code.
The Agent should always first attempt to find a test or rspec that touches the problematic file, and run it. If it passes, it should add several specs that are failing due ot the bug. It must add the broken specs prior to the changing the code and commit and push. This represents a chunk of important work you did, and proved that there is an issue somewheeer.
Now, if the agent or you can't find the unit test for the existing functionality, your first coding task is to provide tests for the old code. Here, and I can't stress it enough, you must extract the existing coding conventions rspec style from the existing specs codebase, unless explicitly given instructions about how to write specs, or unless they contradict latest rspec version's preferred syntax.
For multi-agent operations, they typicallhy need to be fed (or create) a plain text or markdown file that defines all sub-agents, and defines the chain of responsibilities, and every agent after that in a tree-like fashion. Try to parallelize agents that work on unrelated things, but then bring them together quickly to avoid having to do a 10-way merge from each worktree.
I would love to see a small widget that is not associated with any tab and shows all background agents, with a short string about what they are doing in a mini-view that can be maybe stuck at at the left bottom corner, where the hierarchy is — that shows a trees (clusters) of Agents doing some work.
If there are multiple workflows that might happen at the same time, do not create tabs for them, but show them all on the same window, just disconnected tree after another tree. This gives a developer a quick sense of what's going on with the AI-agentic coding scenarious.
In the new project generator you should add "Applied AI Project" templates and "Dry-Rb"-based projects.
Many recent Ruby aficionados are using dry-rb gems such as monads and Ruby as a functional language. I personally do not, so I don't have much to say on the subject but the RubyMine integration with ActiveRecord and Rails must be no better than the integration with Sequel gem.
And web projects should be generated not just for Rails, but for Hanami, Sinatra and Roda at the very least.
First, I am going to bitch about BASH v3 on MacOS. That's annoying as hell.
But that aside, every single paid version of your IDEs MUST include the goddamn upgraded paid version of the BASH extension. Every single project uses BASH scripts, every single project fucks them up. I have a BASH framework to simplify script development —https://bashmatic.dev (mostly for onboardings scripts), but in RubyMine I had to pay for the extension to get decent BASH coverarage that is better than most, but is still kind of sucks. Default the dialect either to ZSH or BASH v5 — installable via Homebrew and include tools for setting up Bats testing tooling locally, and creating a simple tests to demonstrate.
The IDE must have syntax recognition for literally everything. It doen't need to have LSP of every language hooked up, but my RubyMine should have tightest integration with Ruby, and yet consistently understand the codebase written in other languages or at least prompt the user to install the appropriate extensions (e.g. Cmd-Mouse-Click on a method always works in RubyMine, and that's always been one of your killer features).
Now I haven't worked with Docker much, but Docker integration when the app is started via Docker Compose should behave as close to native as possible. The giant Docker windows showing running containers and images is NOT useful, especially as everyone is switching to Rust-based TUI (tui) tools, because we, developers, love the command line. Make Docker default view tiny, show running containers, allow right click on each and restart, or debug, etc.
And shortcuts. Jesus. You guys need to revisit this, I swear. Keep the old ones for backwards compatibility, but make brand new key scheme:
- Run this file
- Run this file from this line
- (same for debug)
- Add the ability to add a prefix to all Ruby commands that the IDE executes. Those that are rightfully encrypting their .
env(there are at least two solutions, dotenvx.com and 1Password — CLI for which installs asopand you must prefix all commands withrun op bundle exec ...In fact, the prefix could also contain bundle exec! And you'd just check two check boxes in a run config and type "rails -s" and "sidekiq", what a joy. - Open Preview (for markdown)
- Open File
- Open Command
- Auto-fix this file from RubCop errors.
- rubocop -a fixes easy crap.
- rubocop -A can break your code. But it will be up to the latest prettiness.
- Therefore, NEVER run rubocop -A on a file that does not have a spec. If there are too many, ask the user: a) disable them per file, b) disable them in the repo, c) run
rubocop --auto-gen-configso they stay in therubocop_todo.yml
- Open Browser (detect output saying shit like "listening on 0.0.0.0:3000") and open browser for that port. If the app takes a while to start retry every few seconds.
- There are of course more that I use daily, all the Cmd-1, 2, etc.
And for crying out loud make it easy to onboard a large legacy Rails app and start it up. Read the README.md, understand any bin/setup scripts, attempt to start it (all can be done at night), etc. Install Brew packages and anything missing add to the top level Brewfile (and if it's new to the repo, add it and leave it there so that the team may want to commit it)
The main killer feature I'd like to propose is a low-energy, slow background AI agent that methodically and meticulously, specifically at night — while the user is not using their laptop — spends CPU cycles constantly but not intensely looking through the codebase for various bugs, prioritizing the fixes focused first on the changed or staged files. This agent does not write any code. If it discovers issues, it creates a top-level files in order of severity:
FIX_IT_NOW.mdFIX_IT_SOON.mdandFIX_IT_EVENTUALLY.mdEach file is broken up up into sections such as "Performance", "Business Logic", "N+1 Detected", "Database Optimization Possible", etc. It needs to have "Risk" as one of the first chapters, and it should be split into two risk types:- Business Risk (may go down, broken feature affects many customers), etc.
- Technical Risk (potentially dangerous from performance standpoint, performance, memory leaks detected, dead code found, very convoluted code area discovered, needs refactor badly or you won't be able to fix bugs in that codebase.
In addition to this, I suggest that the agent populates the folder called
docs/technical-debtwith markdown files that are updated nightly. See below on the Technical Debt.
RubyMine needs to monitor Ruby processes by injecting a lightweight instrumentation (of course it can be turned off, but should be on by the default) that, in real time, detects code inefficiencies, bugs, bad traces. Essentially, I want RubyMine that starts Rails server via Foreman or directly, to work like NewRelic or Datadog APM locally each time it starts the ruby process.
Note
Just like Zed is an underdog, and Cursor has taken over the IDE market, you might want to consider partnering with yet another underdog: HoneyComb. What if the IDE, when it runs your code, always sends traces to HC and can fetch ands show them within the IDE? How god damn cool would that be?
You don't need to keep months of data, just keep a week max (and honestly, daily might be sufficient too, because we all have Datadog as well). Make your AI use a Datadog MCP server so that it can correlate some of it's own traces (btw Datadog can be run on a laptop, and I've done it many times). If you can reach datadog in a readonly mode, search for slow but frequent queries, 503 errors, database logging complaints, etc. Most importantly for junior or mid-level developer: trace for us DB performance queries, and cross reference them with Datadog's production data making it easy to extract useful APM information from running just the local test suite. Make sure an environment variable controls if the suite runs against database, or uses mockups for speed. At night we want to test database constraints and hopefully discover nothing. If this type of instrumentation blows up the RAM, then add a gem for CircleCI and GitHub Actions that collects this info from all the parallel hosts, and there is only one report at the end. Having all the traces, flame graphs, here locally, no need to go to NewRelic.com - you get graphs directly in the IDE showing:
- process args
- memory (RSS)
- Number of Threads (ensure there are no leaks
- Number of context switches (and make it green/yellow/red with a [?] explaining why)
- Recommend number of Puma and Sidekiq threads observing the ratio of IO bound operations and CPU
- eg if CPU if 20% and IO is 80%, then the factor is 5x. For each vCPU Puma can perform 5 concurrent tasks on average that's close to it's utilization.
- Track file write IO of each Ruby component as well as read IO to/from disk
- Track process Network trasnfer rates in and out
- Show a trend line on every graph so that any bro mofo can understand that they have a memory leak
- Flame graphs within Ruby process
- Links to similar traces in Datadog etc.
All of this is awesome, but in addition, make RubyMine's primary AI a usage priced feature, and share instructions on how to minimize the number of tokens, or better yet — start with a flat fee $20/month. Just like Cursor did. Allow people to bring their own Claude and ChatGPT API keys, or authenticate with the browser.
I typically launch 3-5 RubyMine processes in different folders. They need to communicate, for several reasons:
- They need to coordinate running of background AI worfklows so that they don't steal each other of CPU.
- This can be done by starting one, watching load average, and if remains low, starting another, and so on until the machines are utilized to 90% at least.
- On My 2-hear old laptop that's 12 CPU cores.
Important
It must be a single natively multiu-threaded process. One Tab per project. Different Ruby per Project. But not three RubyMines.
The time of the dedicated instance of the IDE attached to a single repo folder is gone. Bye bye! I want to define my projects, and have top level tabs for each folder instead of running five RubyMine's just because I have five repos that need work. I should be able to easily swich my view between each of the folder/tags + their agents that may be working, or perhaps already finished, committed, and pushed while creating a PR.
One of the core ideas behind the multi-agent repo scan at night is that it can identify and extract and document technical debt that the team may not be aware of.
Create a folder called docs/tech-debt (of course configurable). Every tech-debt-like issue you find you that does not fit into the "FIX_NOW" three categories above, goes here as a separate file:
"Night Agent" that runs on computer that doesn't sleep — creates markdown files with well thought out, reviewd, rehashed multiple times, criticized and updated — plans for reducing technical debt, or reducing cost, or improving performance: most likely there will be a single goal that this Agent tries to achieve.
Example:
docs/tech-debt/001-drop-unused-indexes.mddocs/tech-debt/002-fix-jwt-token-security-bug
Note
Allow users to prioritize various topics higher than others, using CLAUDE.md in the docs/tech-debt folder, but start with some sane defaults. Here is my list:
- security and vulnerability
- slop, unused code
- huge database tables (to get the size of the database tables, just show us (and let us copy into a clipboard) a giant read-only join query to run once on their production, giving you every table and index stats you need to make these suggestions)
- ask for top 20 queries (complete, not cutoff) from
pg_stat_statementsas a CSV file with headers. GIve the exact command to export that from psql to the eventually agreed upon place in the repo. Likelydb/statistics/*.rb - log and prioritize bugs affecting all customers
- log the bugs affecting some customers
- use MCP, whatever to connect to Datadog (and maybe also NewRelic if some people still use it)
- use MCP to connect (read-only) to the Rails development database. This can help exploration of thes chema, asking plan English questions that get translated into SQL.
- Dig into rail traces, ensure that any custom metrics are properly tagged, and maybe even validated.
Important
I honestly believe that JetBrains will come back with vengence. Too much great talent there. So I am rooting for you, JB, and hope that you'll surprise us once again, but with something maybe I am not even able to imagine yet.
Good luck, and thank you for the fantastic 20 years of partnership. I shipped a TON of code using JetBrains IDEs, and I am grateful that you built these IDEs, at the time when NetBeans and Eclipse were the only (and prerry aweful) options. Some tiny company out of Prague and St Petersburg (back then), threw together something that was so much better than Eclipse built by IBM that people paid hundreds of dollars to use latest and gratest.
And that concludes my JetBrains love story, and wishes full of hope that they will recover and figure something out that neither Cursor, nor VSCode, nor Zed, had yet invented. Godspeed, fellas!