Ruby всё ещё в продакшене. Но кто будет писать на нём через 10 лет?

Ruby хоронят уже столько лет, что сама фраза «Ruby умер» не вызывает эмоций. При этом Rails продолжает получать новые версии: 24 сентября 2026 года вышел Rails 8.1.4. У Rails больше семи тысяч контрибьюторов за всю историю, крупные компании продолжают использовать его в продакшене, а некоторые Rails-приложения существуют уже больше десяти лет. Поэтому вопрос «умер Ruby или нет» мне кажется довольно бессмысленным.

Интереснее другой вопрос: кто будет писать на Ruby через 5–10 лет?

Представим, что в 2032 году компании нужен senior Ruby-разработчик. Требования вполне обычные: 5–6 лет Rails, PostgreSQL, Redis, Sidekiq, опыт работы с большими системами. Остаётся небольшой вопрос: где в 2026 году этот человек должен начать получать свой опыт? И другой вопрос: будет ли у человека с опытом в другом стеке желание свичнуться в Ruby ради позиции в компании?

Ситуация на рынке

Я сам работаю с Ruby и не считаю язык устаревшим. После работы с Go некоторые вещи в Ruby кажутся уникальными. Ruby позволяет довольно быстро превратить идею в работающий продукт благодаря зрелым фреймворкам, таким как Rails. Фреймворк закрывает огромное количество типовых задач, у него мощная экосистема и документация, а готовых решений хватает почти на всё.

Но если посмотреть не на саму технологию, а на рынок, возникает интересная ситуация. Есть зрелые Ruby-проекты, которые продолжают развиваться и которым нужны разработчики. Причём часто нужны люди, которые действительно хорошо знают Rails, PostgreSQL, умеют разбираться в большом существующем приложении и понимают последствия изменений в системе, которая живёт много лет. То есть нужны middle и senior, а вот мест, где человек может стать этим middle или senior, заметно меньше.

Даже выдача вакансий выглядит интересно. По запросу «Ruby-разработчик» можно получить не только Ruby-позиции, но и вакансии системных аналитиков, Golang-разработчиков, DevOps и другие позиции, где Ruby просто упоминается в требованиях. Это, конечно, не полноценное исследование рынка, но ощущение от рынка всё равно получается довольно специфическое.

Путь в ruby через rails

У Ruby есть ещё одна интересная особенность. Исторически на рынке очень часто искали не просто Ruby Developer, а именно Ruby on Rails Developer. Для сравнения: человек может изучить Go, а потом оказаться в вебе, инфраструктуре, системных утилитах, базах данных, сетевом ПО или tooling. В Ruby для огромного количества людей путь долгое время выглядел примерно так:

хочу заниматься веб-разработкой → изучаю Rails → вместе с Rails изучаю Ruby.

То есть Rails был не просто одним из популярных Ruby-фреймворков, для многих он был причиной вообще начать изучать язык. Даже в вакансиях, которые называются просто «Ruby-разработчик», довольно часто появляется Ruby on Rails.

Ruby — это не только Rails

Есть Grape, Hanami, Roda и другие проекты. Roda, например, продолжает развиваться и предлагает совсем другую философию: маленькое ядро, routing tree, плагины и минимум скрытой магии, новые версии продолжают выходить. Hanami тоже никуда не исчез. Проект предлагает более явный подход к архитектуре и зависимостям, чем классический Rails. Нельзя сказать, что «в Ruby есть только Rails», но есть другое наблюдение: за Rails всё ещё огромный разрыв.

На RubyGems у Rails примерно 800 млн загрузок. Сюда попадают обновления, CI, переустановки и куча другой активности. Но Rails настолько хорошо закрыл огромный класс задач, что у разработчика часто не возникает вопроса «Какой Ruby-фреймворк мне выбрать?». Возникает другой: «А почему здесь вообще не Rails?»

Это одновременно сила Ruby-экосистемы и одна из её особенностей. Альтернативы есть, некоторые из них вполне интересные и живые, но сопоставимых с Rails так и не появились. Они показывают, что Ruby как язык не сводится к Rails, но с точки зрения рынка и выращивания коммерческих Ruby-разработчиков Rails по-прежнему играет ключевую роль.

Rails и монолиты

Многие известные Rails-проекты построены как большие монолиты. И здесь слово «монолит» не нужно воспринимать как ругательство. Rails сам довольно открыто продвигает эту модель. В Rails Doctrine используется термин Majestic Monolith: идея в том, чтобы держать систему интегрированной и не распределять её по сервисам раньше, чем в этом действительно возникнет необходимость.

На Rails вполне можно строить большие системы. Есть известные примеры: Shopify, продукты 37signals и другие компании, которые годами развивают Rails-монолиты и не считают сам факт существования монолита проблемой. У такого подхода есть очевидные плюсы. Не нужно поддерживать десятки сетевых контрактов, отдельные pipelines для каждой небольшой части системы, distributed tracing и согласование изменений между кучей сервисов. Большой Rails-монолит вполне может жить очень долго.

Но здесь я бы не стал делать вывод, что таких проектов обязательно очень много или что они гарантированно никуда не денутся. Реальную установленную базу Rails-приложений оценить довольно сложно. Более того, я знаю людей, которых сократили после того, как компания переписала продукт с Ruby на другой стек. И самое интересное, что речь там не шла о каком-то уникальном Rails-монолите с невероятно сложной предметной областью. По описанию это был довольно обычный CRUD.

Если приложение относительно простое, а компания по каким-то причинам хочет унифицировать стек, упростить найм, объединить команды или перейти на технологию, которой уже пользуется в других сервисах, миграция может оказаться вполне реальным вариантом. И для конкретных Ruby-разработчиков последствия такого решения могут быть очень практичными: проект остаётся, а команда больше не нужна.

Получается сразу две силы

И вот здесь ситуация с Ruby становится ещё интереснее. Одновременно работают два процесса. С одной стороны, существуют зрелые Rails-системы, которые слишком дорого и бессмысленно переписывать просто ради смены языка. С другой стороны, часть более простых систем со временем вполне может мигрировать на другие стеки.

То есть нельзя просто сказать: «Старого Rails-кода много, поэтому работа будет всегда. Вон проекты на PHP до сих пор поддерживают». Но нельзя сказать и обратное: «Все сейчас перепишут Rails на Go».

Реальность где-то между этими крайностями. И именно поэтому мне интереснее смотреть не на абсолютное количество Rails-проектов, а на способность экосистемы постоянно воспроизводить специалистов.

Rails при этом сложно назвать заброшенным

Rails точно не выглядит проектом, который поддерживают три человека по выходным. В Rails 8.1.0 было 2870 коммитов. Даже Rails 8.1.4, обычный maintenance-релиз, включил больше 300 коммитов.

Поэтому проблема, если она действительно есть, находится где-то в другом месте. Не в способности Rails продолжать существовать, а в способности экосистемы выращивать следующее поколение разработчиков.

Возможно, это проблема не только Ruby

Тут можно справедливо возразить, что junior-вакансий сейчас вообще стало меньше независимо от языка. Компании хотят нанимать человека, который уже умеет работать самостоятельно. AI ещё сильнее толкает рынок в эту сторону: если опытный инженер с агентом может делать больше, появляется соблазн взять меньше людей, но более высокого уровня.

И здесь возникает довольно удобный ответ на проблему, которую я описываю выше: а зачем вообще выращивать столько новых Ruby-разработчиков, если через несколько лет большую часть кода будут писать агенты?

Делать такую ставку довольно рискованно. Я вполне допускаю, что агенты будут писать всё больше кода и делать это лучше. Возможно, через несколько лет они будут генерировать вполне хороший код. Но между «агент умеет написать рабочий код» и «агент может самостоятельно развивать сложную систему годами» есть довольно большая разница.

У каждого зрелого проекта со временем появляется собственная культура: свои архитектурные договорённости, принятые способы решения задач, места, которых стараются не касаться без необходимости, исторические компромиссы и решения, которые со стороны могут выглядеть странно. Часть этого можно записать в документацию или правила для агента, но даже подробное описание не гарантирует, что агент каждый раз правильно поймёт контекст и не ошибётся.

Идиоматичный Ruby-код и правильный код для конкретного десятилетнего Rails-монолита — далеко не всегда одно и то же.

Причём есть ещё одна сторона AI, которая для Ruby может оказаться не такой приятной. Обычно мы рассуждаем так: агенты позволят меньшей Ruby-команде дешевле поддерживать существующий Rails-проект, а значит, продлят ему жизнь. Но тот же самый инструмент способен удешевить и обратный процесс. Если раньше переписывание обычного CRUD с Rails на Go, Java или другой стек могло быть слишком дорогим просто из-за количества работы, то с развитием агентов цена такого решения может снижаться.

Получается довольно интересный парадокс: AI может одновременно продлевать жизнь сложным Rails-системам и делать дешевле миграцию с Rails для более простых приложений. Поэтому ставка на то, что агенты автоматически сохранят существующий спрос на Ruby-разработчиков не сказать что сыграет.

А если применять SDD ?

Здесь появляется ещё один логичный аргумент — spec-driven development. Вместо того чтобы просто сказать агенту «сделай фичу», мы сначала описываем требования, сценарии, ограничения и ожидаемое поведение, а уже потом отдаём спецификацию агенту. Мне этот подход нравится: чем меньше агенту приходится угадывать, тем лучше.

Но SDD не решает проблему до конца. Спецификацию тоже написал человек. В ней можно забыть важный сценарий или неправильно сформулировать требование. Можно подробно описать happy path и ничего не написать про частичный отказ, обратную совместимость, нагрузку, существующие данные или особенности интеграции. Более того, чем увереннее агент реализует такую спецификацию, тем быстрее неправильное предположение может превратиться сразу в код, тесты и документацию.

В работе The Specification Paradox: Rethinking Requirements Engineering in the Age of AI авторы описывают похожую проблему. По их мысли, AI уменьшает часть стоимости написания кода, но не уничтожает сложность разработки: она смещается в понимание предметной области, сбор требований, создание спецификаций, проверку результата и дальнейшую эволюцию системы. Авторы отдельно говорят об ambiguity propagation и specification debt: неоднозначность или пробел в требованиях теперь можно не просто случайно реализовать, а быстро размножить по создаваемой AI системе.

Мне близка сама идея: AI не уничтожает сложность — он переносит её из реализации в требования и проверку. Раньше значительная часть усилий уходила на то, чтобы правильно написать реализацию, а теперь всё критичнее становится правильно понять, что именно вообще нужно реализовать. В результате мы можем просто очень быстро и очень качественно сгенерировать неправильный код по неправильной спецификации. И здесь мы снова упираемся в опыт: кто-то должен понять, что именно нужно положить в эту спецификацию.

Разработка начинается не с кода

Есть ещё человеческий фактор, который легко потерять в разговорах про агентов. Разработка далеко не всегда начинается с хорошего, полного технического задания. Очень часто задача приходит в виде пары абзацев, после чего разработчик начинает задавать вопросы, идти к бизнесу, аналитику или другой команде и выяснять, что именно должно произойти в разных сценариях.

Рассмотрим пример с платежами. Допустим, в задаче написано: «добавить оплату услуги». Кажется, что всё понятно, но дальше начинаются детали. Что делать, если деньги списались, а подтверждение от провайдера не пришло? Можно ли безопасно повторить запрос? Как мы защищаемся от двойного списания? Что происходит при таймауте? Когда возвращаем деньги? Что увидит пользователь, если платёж прошёл, а сама услуга не была оказана? Кто является источником истины, если наш сервис считает операцию успешной, а внешний провайдер говорит обратное?

Эти вопросы должны появиться до того, как кто-то приступит к реализации. Опытный разработчик задаёт их не потому, что в спецификации написано «проверьте идемпотентность», а потому, что уже видел, как такие системы ломаются. ИИ здесь тоже помогает: найдёт edge cases, прочитает документацию платёжного провайдера, отревьюит спецификацию. Агент не пойдёт к бизнесу, не соберёт в одном месте продуктолога, аналитика и владельца интеграции и не выяснит, какое именно поведение компания считает правильным при каждом спорном сценарии.

Даже если когда-нибудь он технически сможет это делать, остаётся вопрос ответственности за решение. Людям не нравится, когда с них дважды списывают деньги или когда услуга не оказана, а деньги ушли. Именно поэтому кадровая проблема не решается тем, что AI научится хорошо писать Ruby. Компании нужен не человек, способный набрать Payment.create!, а инженер, который поймёт, можно ли вообще создавать этот Payment в текущем состоянии системы.

Цена ошибки тоже разная

Я бы не стал утверждать, что ошибка в B2C всегда менее страшная, чем в B2B. В платежах, банках или медицине B2C-баг вполне может быть критичным. Но в обычной некритичной пользовательской функции ошибка часто заканчивается тикетом в поддержку, плохим отзывом или потерей части пользователей. В B2B последствия нередко намного формальнее: у компании есть контракт, SLA и бизнес-процессы клиента, которые зависят от системы. Если из-за нашей ошибки клиент несколько часов не может проводить свои операции, проблема уже не ограничивается сообщением «что-то пошло не так». Компания может нарушить SLA, выплатить компенсацию, потерять клиента или понести прямые финансовые убытки. Особенно это важно в интеграциях. Одна неправильная операция может проехать дальше по нескольким системам, попасть в отчётность или заблокировать процесс на стороне клиента. Поэтому подход «агент написал, тесты прошли, значит, можно выпускать» для таких частей системы довольно опасен.

Кто-то должен понимать не только код, но и бизнес-инварианты: почему одну и ту же операцию нельзя провести дважды, почему деньги нельзя возвращать до подтверждения от провайдера, чьё состояние считать истинным, если наш сервис и провайдер расходятся. И именно на подобных задачах постепенно появляется опыт, который потом позволяет человеку принимать решения уже на уровне senior.

Здесь возникает ещё один неприятный вопрос: если junior-задачи теперь дешевле отдавать агенту, то на каких задачах будущий senior должен научиться проверять этого агента?

Мы можем потерять не только новых разработчиков, но и передачу знаний

Senior появляется не только потому, что пять лет писал код. Часть его опыта — это знания, которые он получил от других людей: почему определённое решение однажды приняли, почему от очевидного рефакторинга отказались, почему конкретная интеграция работает именно так, хотя документация провайдера говорит иначе.

Если команда из десяти человек со временем превращается в трёх опытных инженеров и десяток параллельно работающих агентов, с точки зрения текущего delivery это может оказаться очень выгодно. Но одновременно становится меньше людей, которым передаётся история системы. И через несколько лет проблема может оказаться не в том, что некому написать очередной endpoint, а в том, что некому объяснить, почему существующий endpoint вообще работает именно так.

Для больших Rails-монолитов это особенно важно. Такие системы часто живут годами, постепенно обрастают интеграциями и бизнес-правилами. Можно записывать ADR, вести хорошую документацию, добавлять инструкции для агентов, но полностью вынести в текст десятилетнюю историю продукта практически невозможно. Часть контекста всё равно остаётся распределена между людьми.

Если мы резко сокращаем количество людей, которые проходят через эту систему и постепенно получают этот контекст, мы оптимизируем сегодняшнюю скорость разработки за счёт того, что через несколько лет может оказаться некому принимать сложные решения.

Почему это проблема не только новичков

На первый взгляд всё просто: не можешь найти первую работу на Ruby — учи Go, Python. Но через несколько лет это превращается уже в проблему работодателя. Если технология используется в критичной части бизнеса, компании нужны люди, которые её хорошо знают.

Можно нанимать готовых senior, но senior — это не природный ресурс. Он когда-то был junior, потом несколько лет делал ошибки, читал чужой код, участвовал в ревью, разбирался с продакшеном, обновлял Rails, ловил race condition в Sidekiq и пытался понять, почему PostgreSQL внезапно решил сделать Seq Scan. Он также ходил к бизнесу, спорил о требованиях, выпускал неудачные решения и постепенно учился задавать нужные вопросы ещё до начала реализации.

Если убрать начало этой цепочки, конец какое-то время продолжит существовать по инерции. AI даже может продлить этот период, потому что существующие senior смогут обслуживать больше кода меньшим количеством людей. Но от этого сама проблема воспроизводства специалистов никуда не исчезает.

Компаниям с большими Ruby-командами, скорее всего, придётся активнее выращивать специалистов самостоятельно: брать backend-разработчиков с других языков и переучивать, запускать стажировки или сознательно нанимать людей без нескольких лет коммерческого Rails. Но тут появляется другой вопрос: как убедить человека, который только начинает карьеру, инвестировать своё время именно в Ruby?

Я сам не очень верю в идею «учить язык ради языка»: для меня язык — это инструмент. Поэтому убеждать новичков красивым синтаксисом или тем, что на Rails можно написать меньше кода, недостаточно. Разработчику нужно видеть, какие задачи он сможет решать, в каких проектах работать и куда расти дальше. Если компаниям нужны только люди с пятью годами Rails, экосистема начинает жить за счёт специалистов, которых кто-то вырастил раньше. Чтобы это не превратилось в замкнутый круг, компаниям придётся не рассказывать, что Ruby прекрасен, а показывать на практике, что человек без многолетнего Ruby-бэкграунда может прийти, получить реальный опыт и через несколько лет стать сильным backend-инженером.

Вывод

Мне по-прежнему не нравится тезис «Ruby умер». Он слишком примитивный. Rails активно развивается, у него большая экосистема, на нём работают большие системы, существуют Hanami, Roda и другие проекты. Но и противоположная крайность в духе «Rails-проектов полно, поэтому всё хорошо» слишком простая.

Часть больших систем действительно может жить ещё десять лет. Часть небольших CRUD-приложений вполне могут переписать на другой стек, особенно если компания хочет унифицировать технологии. Причём AI способен влиять сразу в обе стороны: сделать дешевле поддержку старого Rails-монолита и одновременно снизить стоимость его переписывания, если система достаточно простая.

Ставка на то, что кадровый разрыв закроют сами агенты, тоже слишком оптимистична. Даже если через несколько лет AI будет писать почти безошибочный и вполне идиоматичный Ruby, останутся требования, культура конкретного проекта, бизнес-инварианты, ответственность за решения и передача знаний между поколениями разработчиков. SDD помогает сделать требования явнее, но не гарантирует, что кто-то задал правильные вопросы и что спецификация вообще описывает правильную систему.

AI не уничтожает сложность разработки, а переносит её. Меньше времени уходит на механическое написание реализации, но большее значение получают постановка задачи, проверка результата, понимание предметной области и способность увидеть проблему, которой вообще не было в исходной спецификации.

И тогда главный риск для Ruby выглядит совсем не так:

однажды все проснутся и перепишут свои Rails-приложения на Go.

Я не очень боюсь даже сценария, в котором через десять лет мало людей будут помнить наизусть все тонкости Ruby. Язык и Rails при необходимости можно изучить.

Гораздо неприятнее другой сценарий: часть сложных Rails-систем всё ещё работает, агенты прекрасно умеют генерировать для них код, но становится мало людей, которые понимают историю этих систем, бизнес за ними и способны сказать агенту:

«Технически всё выглядит правильно. Но выпускать это нельзя».

И вопрос тогда уже не только в том, кто будет писать Ruby через десять лет.

Вопрос в том, где возьмутся люди, способные отвечать за то, что на нём написано.