Почему Ruby-проект 2017 года может оказаться современнее AI-SaaS 2026 года

Слово legacy обычно вызывает довольно определённую картинку: старый Ruby или PHP, давно не обновлявшиеся зависимости, странная структура проекта, jQuery, MySQL и код, который никто не хочет трогать.

А «современная платформа» выглядит наоборот: облако, красивый интерфейс, AI-ассистент, автоматический deploy, CDN и несколько кнопок вместо терминала.

За последние месяцы практическая работа с разными стеками заставляет посмотреть на эту классификацию иначе.

Для coding agent вопрос «на чём написан этот проект?» всё чаще оказывается вторичным. Гораздо важнее другое:

• можно ли получить исходный код;
• можно ли воспроизводимо запустить runtime;
• доступны ли данные;
• можно ли читать логи;
• можно ли менять систему;
• можно ли проверить результат;
• можно ли забрать всё это и запустить в другом месте.

По этой шкале старый открытый проект иногда оказывается современнее нового proprietary SaaS.

Практический тест: запустить и дать задачу AI

При работе с MODX, Laravel и Ruby повторяется удивительно похожий сценарий.

Сначала проект нужно запустить в контролируемой среде — чаще всего в Docker. После этого coding agent получает репозиторий и runtime и может начать нормальную инженерную работу: исследовать структуру, искать точки входа, читать конфигурацию, выполнять команды, менять код, смотреть ошибки и проверять результат.

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

Человеку, который впервые видит старое Rails-приложение, раньше приходилось самому вспоминать или изучать conventions конкретной версии Rails, набор gems, asset pipeline, ORM, маршрутизацию и устройство проекта. Coding agent способен проделать значительную часть этой исследовательской работы непосредственно по коду и документации.

В результате универсальный operational interface выглядит почти примитивно:

source code
+ runtime
+ shell
+ database
+ browser
+ logs
= среда, в которой агент может работать

Это неожиданно сильная унификация.

Реальный Ruby legacy: bizneshelper.ru

В начале сентября 2026 года началась миграция bizneshelper.ru со старой Ruby-реализации.

5 сентября была создана основная задача миграции. Legacy-сайт удалось локально запустить. После этого он перестал быть загадочным «старым Ruby-проектом» и превратился в обычный исследуемый объект: можно смотреть данные, маршруты, ассеты, старое поведение и принимать решения о том, что действительно стоит переносить.

По ходу исследования нашлись вполне типичные следы возраста системы.

Например, HTTPS-страница пыталась загружать jQuery 1.8.2 по обычному HTTP. Современный браузер блокировал запрос как Mixed Content. В форме обратной связи оставались варианты социальной авторизации через Google+, ВКонтакте, Twitter и Facebook — и ни один из них уже не работал. Старый поиск был завязан на Sunspot/Solr. Rails Asset Pipeline скрывал физическое расположение ассетов, поэтому для переходного периода пришлось сделать небольшой compatibility middleware.

Если перечислить это списком, проект выглядит довольно страшно.

Но главное произошло дальше.

Вместо восстановления старой системы один к одному legacy использовали как источник данных и reference implementation. Полезный контент перенесли в более простую модель, нужное поведение воспроизвели локально, ненужные исторические функции отбросили.

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

Основная техническая переделка заняла около 3–4 дней.

Для старого Ruby-приложения с большим количеством специализированных сущностей, историческим HTML, отдельными представлениями и CSS это важная цифра. Она не доказывает, что любой legacy теперь можно переписать за четыре дня. Но хорошо показывает, насколько изменилась стоимость исследования и переработки незнакомой системы.

А теперь представим современный закрытый конструктор

У него может быть гораздо более новый frontend, прекрасный UX и встроенный AI.

Но допустим, что исходный код проекта получить нельзя. Runtime контролирует только поставщик. База данных напрямую недоступна. Экспорт частичный. Серверную логику можно менять только через предусмотренный API. Некоторые функции существуют исключительно внутри платформы.

Тогда возможности coding agent ограничены не его интеллектом.

Они ограничены поверхностью, которую открыл vendor.

Можно представить это как узкое горлышко:

возможности AI: очень широкие
        ↓
API платформы: ограниченный набор операций
        ↓
доступные изменения: не шире API

А в старом Ruby-проекте агент при наличии полного доступа может изменить маршрутизацию, модель данных, SQL, frontend, фоновые задачи, инфраструктуру и процедуру deploy.

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

Legacy — это не возраст

Возможно, нам стоит разделить два понятия.

Первое — технологический возраст. Старые версии языков, библиотек и архитектур действительно могут создавать проблемы: security updates, несовместимости, отсутствие поддержки, плохая производительность.

Второе — управляемость системы.

И вот здесь возраст сам по себе говорит мало.

Проект может быть старым, но при этом:

• иметь доступный source code;
• запускаться локально;
• хранить данные в обычной базе;
• иметь понятные зависимости;
• позволять заменить любой компонент;
• не зависеть от одного поставщика runtime.

А новый SaaS может быть технически блестящим, но полностью непрозрачным снаружи.

Для AI-assisted engineering второй фактор становится всё важнее.

Docker как слой нормализации неоднородности

Docker здесь интересен не потому, что контейнеры — новая технология. Они давно стали обычным инструментом.

Новое — их сочетание с coding agents.

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

MODX ──────┐
Laravel ───┤
Ruby ──────┤
Next.js ───┼──→ воспроизводимый runtime → coding agent
Django ────┤
Go ────────┤
другое ────┘

Это не отменяет архитектурные различия. Оно снижает стоимость переключения между ними.

Для сервисной команды это особенно существенно. Раньше разнообразие стеков почти автоматически означало необходимость держать специалистов по каждому стеку или ограничивать список поддерживаемых технологий. Теперь сильный инженер с AI может работать с гораздо более широким классом систем.

Что тогда действительно делает проект трудным для обслуживания

Новый критерий выглядит примерно так:

Насколько система открыта, воспроизводима и исследуема?

Плохой сценарий — не обязательно «старый PHP».

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

И наоборот: некрасивый репозиторий с полным исходным кодом и базой данных может оказаться вполне удобным объектом для работы. Агент прочитает его, построит модель системы и поможет постепенно улучшить.

Это не делает плохой код хорошим. Это делает плохой код доступным для исправления.

Разница огромная.

Опыт специалиста не исчезает

Из всего этого легко сделать слишком сильный вывод: если AI умеет читать любой стек, специалист больше не нужен.

Практика показывает скорее обратное.

AI расширяет операционную ширину сильного инженера, но не отменяет инженерное суждение.

Нужно решить, стоит ли вообще восстанавливать старую функцию. Нужно отличить реальную инфраструктурную необходимость от исторического артефакта. Нужно понять, когда маленький compatibility layer лучше большой миграции, а когда legacy пора выбросить. Нужно оценить риск изменения данных и выбрать подходящую архитектуру новой функции.

В случае bizneshelper.ru важным решением было не «как перенести Rails правильно», а «Rails не является целевой архитектурой вообще». Старое приложение оставили источником данных и средством сверки. Полную обратную совместимость со всей маршрутизацией тоже не стали воспроизводить: в индексе было порядка 85 значимых страниц, поэтому SEO-переезд можно было сделать точечно.

Это решение не следует автоматически из знания синтаксиса Ruby.

Новый технический due diligence

При оценке проекта сегодня я бы всё меньше начинала с вопроса о модности стека.

Гораздо полезнее проверить:

1. Получаем ли мы весь source code?
2. Можем ли воспроизвести приложение локально или в контейнерах?
3. Имеем ли полный доступ к данным и их формату?
4. Можно ли наблюдать работу системы: logs, network, database, browser?
5. Можем ли изменить любой необходимый слой?
6. Можно ли протестировать изменение до production?
7. Можно ли перенести проект к другому hosting provider без переписывания продукта?

Если ответы положительные, coding agent получает пространство для работы.

Если нет, современный логотип и встроенный AI мало что меняют.

Возможно, понятие «современный стек» устарело раньше, чем мы заметили

Долгое время современность веб-проекта определяли набором технологий: какой framework, какой bundler, какой cloud, какой frontend.

Coding agents предлагают более фундаментальную шкалу:

open / inspectable / reproducible / modifiable
                    ↕
closed / opaque / vendor-controlled

Возраст технологий всё ещё важен. Но способность системы быть исследованной и изменённой становится самостоятельным инженерным свойством.

И поэтому Ruby-проект 2017 года действительно иногда может оказаться современнее AI-SaaS 2026 года.

Не потому, что в нём лучше технологии.

А потому, что он целиком у нас в руках.