Комментарии 5
Ну я бы так сказала, после работы AI, именно человеку прийдется разгребать ошибки. Так что синтаксис и легкость языка здесь будут плюсом )
как по мне агенту наоборот сложнее разобраться, т.к. кода хоть и мало, за то в реилс много подкапотной магии, в более императивных языках ИИ все наглядно и понятно
Сразу скажу, что Rust вообще не трогал и в целом давно со строгой типизацией не работал, так что могу заблуждаться.
Во-первых, по-хорошему, всё равно придётся ревьюить код, а в Ruby/Rails это делать проще и приятнее.
Типизированный код зачастую больше по объёму, что влияет на стоимость и время генерации, особенно учитывая, что output-токены сильно дороже входных. Конечно, типизация помогает находить ошибки раньше, но в плане объёма генерируемого кода у Ruby есть преимущество.
Экосистема Rails даёт возможность быстро стартануть (да, возможно, потом вы многое перепишете, но на первом этапе точно ок): Devise, админки, policy и т. д. В целом архитектурно, не представляю условно быстрый старт на том же Go, а вот любимый монолитик на рельсе, да ещё на Hotwire — мёд.
Сравнивая с Python или JS: Django тоже хорош, но, на мой взгляд, Rails всё же выигрывает по целостности экосистемы и количеству готовых решений. На JS/TS распространённая связка — NestJS + React/Next.js. Да, можно собрать всё в одном монорепозитории, но это всё равно два приложения со своей интеграцией. А в Rails + Hotwire всё из коробки в рамках одного монолита. И разработчику проще, и агенту меньше контекста нужно держать, и деплоить проще.
В общем, AI упрощает написание кода, но не отменяет его ревью, архитектуру и поддержку. А Rails как раз позволяет писать меньше кода и принимать меньше архитектурных решений.
Спасибо за коммент, есть несколько возражений:
всё равно придётся ревьюить код, а в Ruby/Rails это делать проще и приятнее.
субъективно, в статически типизированных языках часть ревью за тебя делает компилятор: несоответствие типов, неверные сигнатуры, часть ошибок с nil и т. д. Поэтому кода может быть больше, но ручной проверки некоторых вещей меньше.
Типизированный код зачастую больше по объёму, что влияет на стоимость и время генерации
я бы считал не одну генерацию, а весь цикл. Если типы и компилятор позволяют агенту быстрее обнаружить ошибку и исправить её, итоговых токенов может уйти меньше для решения задачи
В целом архитектурно, не представляю условно быстрый старт на том же Go...
рельса сильна в CRUD/web-приложений. На Go можно также быстро стартовать, просто там меньше решений из коробки и больше явной композиции, но это и плюс, открываешь composition root и понимаешь что куда инжектится. Но да, собирать приложение из gin + orm + другие зависимости первый раз трудно, но это решается готовым шаблоном которые есть в компании.
DHH в очередной раз выступил как мудак. Количество мата в его презентации зашкаливает. В конце обозвал всех кто руками пишет код f... looser. Ему ответил Аарон на заключительной презентации - "я люблю ковыряться в stacktrace, и это не делает меня лузером". Беда в том, что эти презентации смотрят руководители С-уровня и делают весьма поверхностные выводы.
А по делу - Rails отлично подходит для AI агентов. Нужно добавить общих (для команды) инструкций о локальных соглашениях и паттернах, сделать доступным для агента данные мониторинга, ошибок и логов, дать доступ к системе тикетов, добавить перекрёстных проверок от разных вендоров на этапе ревью кода (самое полезное - на соответствие кода и поставленной в тикете задаче). Приправить локальными предпочтениями (вкусовщина) и всё отлично генерируется. Если честно качество кода на выходе неплохое, дальше вобщем-то нет нужды улучшать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мысли про DHH, Rails и AI в Ruby Посмотрел выступление DHH с Rails World 2026. Ниже просто мои мысли по поводу того,...