В июле 2025 года создатель Ruby on Rails Дэвид Хайнемайер Ханссон, более известный как DHH, говорил, что при работе с AI буквально чувствует, как навык программирования «утекает из пальцев». Через год он почти перестал писать код руками, начал запускать несколько агентов одновременно и объявил со сцены Rails World:
“Writing code by hand is no longer an economically viable skill…”
Менять мнение нормально, особенно когда меняется технология. Но в случае DHH интересен не сам разворот. Интересно, почему личный эксперимент одного разработчика меняет то, какие инструменты другие инженеры начинают считать допустимыми. DHH создал Ruby on Rails, Hotwire и Kamal, вместе с 37signals развивает Basecamp и HEY, а недавно запустил Linux-дистрибутив Omarchy. За его решениями следят далеко за пределами сообщества Rails.
От «навык утекает» до отказа от ручного кода
В интервью Лексу Фридману в июле 2025 года DHH рассказывал, что любит работать с AI, но держит его в отдельном окне и не даёт управлять своим кодом. Причину он сформулировал эмоционально:
“I can literally feel competence draining out of my fingers.”
Он чувствовал, как теряет навык, когда код начинает писать AI. Для DHH программирование было не только способом получить работающий результат. Сам процесс имел значение. Это хорошо сочеталось с философией Ruby: код должен быть правильным, выразительным и приятным для человека, который его пишет.
При этом DHH не отрицал пользу AI. Он задавал модели вопросы, обсуждал решения и просил объяснять незнакомые конструкции. Граница проходила примерно так: AI помогает программировать, но программистом остаётся человек.
В том интервью он сравнивал программирование с игрой на гитаре. Можно смотреть уроки и разбирать чужую технику, но движения появляются только после собственной практики. По его мнению, с кодом происходит то же самое: часть навыка формируется, когда человек сам набирает конструкции, ошибается и исправляет результат. Особенно хорошо эту позицию показывает Bash. DHH заметил, что просит AI снова и снова генерировать одни и те же конструкции, но ничего не запоминает. Поэтому он решил изучить язык и писать команды самостоятельно.
К концу 2025 года изменился не только его взгляд, но и сами инструменты. Агенты получили терминал, научились запускать тесты, искать документацию, работать с внешними сервисами и проверять собственный результат.
В январе 2026 года DHH написал Promoting AI agents. Модель взаимодействия с AI в редакторе по-прежнему ему не нравилась: автодополнение постоянно перехватывало мысль и пыталось дописать код за человека. Автономный агент оказался другим инструментом. Разработчик описывает задачу, агент работает с репозиторием, запускает тесты и возвращается с результатом.
DHH сравнивал такой процесс уже не с помощником, который выхватывает клавиатуру, а с работой небольшой команды. Несколько агентов могут независимо выполнять задачи, а человек возвращается к ним, когда нужен выбор или проверка. Для него это оказалось принципиально другим способом взаимодействия, хотя код в обоих случаях генерирует модель.
Теперь DHH уже называл агентов способными вносить изменения в production-код:
“They’re fully capable of producing production-grade contributions…”
При этом январская позиция ещё была осторожной. DHH отдельно писал, что не получает от агентов больше 90% кода и не готов отказаться от контроля качества и целостности системы. За следующие месяцы эта граница сдвинулась заметно дальше.
В августе вышел пост Endless execution. В нём прежняя осторожность почти исчезла. DHH сравнил агента с маленьким джинном в компьютере, который позволяет проверить любую идею, и назвал работу с ним самым увлекательным опытом за компьютером в своей жизни.
В новом разговоре с Лексом Фридманом он вернулся и к примеру с Bash. Язык он всё-таки изучил, а потом перестал им пользоваться, потому что агенты стали достаточно хороши, чтобы снова забрать эту работу себе:
“I have not written any Bash myself for probably a couple months…”
То есть в течения года:
2025: AI полезен, но код я хочу писать сам → чувствую, как навык утекает из пальцев → поэтому специально изучаю Bash.
2026: агенты стали настолько хороши, что я уже несколько месяцев не пишу Bash сам.
Технология изменилась достаточно сильно, чтобы DHH пересмотрел не только способ работы, но и критерии выбора инструментов.
Rust, который человеку больше не нужно писать
В июне 2024 года DHH опубликовал Why I retired from the tech crusades. Он писал, что универсально лучшего языка не существует: кому-то подходит функциональное программирование, кому-то Go или JavaScript, а сам он нашёл свой язык в Ruby.
Отдельно он заметил:
“I wouldn’t be a happy camper if I had to spend my days programming Rust…”
DHH не отрицал достоинства Rust и хвалил созданные на нём инструменты. Он просто не хотел проводить рабочие дни, программируя на этом языке. Такая позиция соответствовала его многолетней философии: язык служит интерфейсом между человеком и компьютером, поэтому удовольствие от работы имеет значение.
На Rails World 2026 DHH уже показывал код на Rust и объявил о начале переписывания серверной части HEY. Со сцены он сказал:
“I love Rust! Rust is amazing…”
И сразу добавил условие:
“…if you never, ever, EVER have to look at it yourself.”
К самому языку он теплее не стал. Изменилось другое: писать этот код теперь должен агент.
“Agents like Rust. Great! What a division of labor.”
Раньше при выборе языка команда учитывала не только производительность, но и то, насколько удобно людям писать, читать и поддерживать систему. DHH предлагает другую модель: человек выбирает архитектуру и проверяет критические участки, а неприятный ему синтаксис остаётся проблемой машины. В этой модели часть традиционных минусов языка начинает весить меньше. Агенту не мешают многословность, строгий компилятор или большое количество служебного кода. При этом преимущества Rust сохраняются: производительность, контроль памяти и компиляция в нативный бинарный файл.
DHH утверждает, что новая серверная часть HEY потребует значительно меньше CPU и памяти. Эти цифры нельзя воспринимать как сравнение Ruby и Rust в одинаковых условиях. Вместе с языком меняется архитектура продукта: HEY перестраивают из веб-приложения в набор нативных клиентов с отдельным почтовым сервером.
На том же выступлении DHH защищал и Rails. Строгие соглашения фреймворка помогают агенту быстрее понять устройство проекта, а отсутствие лишнего шаблонного кода сокращает контекст. В такой трактовке convention over configuration становится преимуществом уже не только для человека, но и для модели. С динамической типизацией вывод не такой очевидный. Человеку отсутствие обязательных типов позволяет быстрее двигаться от идеи к результату. Агенту типы могут дать дополнительную информацию и остановить часть ошибок ещё при компиляции. Поэтому из выступления не следует, что AI автоматически усиливает все прежние преимущества Ruby.
Изменение видно и по работе самого DHH. Со сцены он привёл цифры:
“If I look at the past 21 years, over half of my work was Ruby code. This year, about 3%.”
Больше половины работы за двадцать один год и около трёх процентов за этот. Для человека, который десятилетиями говорил о радости программирования на Ruby, это серьёзный сдвиг. Главным аргументом в пользу Ruby всегда было то, что на нём приятно писать человеку: простой синтаксис, выразительный код, короткий путь от идеи до работающего продукта. Если код всё чаще пишет агент, этот аргумент весит меньше. У Rust и Go при этом остаются статическая типизация, нормальная работа с многопоточностью и предсказуемое потребление ресурсов. В MRI по-прежнему есть GIL, и когда нужна CPU-параллельность, приходится добавлять воркеры и инстансы, а инфраструктура стоит денег.
Этот эксперимент ставит вопрос шире обычного спора о языках:
Нужно ли разработчику любить язык, если большую часть кода на нём пишет агент?
Ответ пока не очевиден. Код всё равно придётся отлаживать, развивать и читать во время инцидентов. Но сам факт, что создатель Rails публично выбирает неприятный ему язык ради результата, показывает, насколько сильно агенты меняют прежние компромиссы.
Почему мнение DHH становится событием
Если обычный разработчик сначала напишет «Cursor делает меня глупее», а через полгода назовёт Claude Code прекрасным, коллеги могут найти старое сообщение и немного пошутить. На индустрию это почти не повлияет.
С DHH происходит иначе. Его имя связано не только с веб-фреймворком, но и с целым подходом к разработке: convention over configuration, монолит как нормальная архитектура, ставка на SQL-базу и небольшие команды. Rails распространял эти идеи вместе с кодом. DHH умеет превращать техническое решение в понятную историю. Это не делает решение правильным, но помогает ему пройти первый фильтр внимания. Разработчику невозможно самостоятельно глубоко проверить каждый язык, фреймворк, AI-инструмент и способ деплоя. Приходится решать, на что вообще стоит потратить время.
Когда малоизвестный разработчик заставляет AI писать Rust, это выглядит как личный эксперимент. Когда создатель Rails демонстрирует ту же модель со сцены Rails World и применяет её в своём продукте, сочетание «Rails-разработчик, AI и Rust» перестаёт казаться странным.
Известные инженеры редко определяют чужой выбор напрямую. Зато они хорошо управляют вниманием: переносят идею из категории «непонятная игрушка» в категорию «вариант, который стоит проверить».
Linux и TypeScript: другие способы влиять
С Linux произошла похожая история. DHH много лет пользовался техникой Apple, затем собрал Omakub, готовое окружение разработчика на Ubuntu, а позже перешёл на Arch Linux и Hyprland и создал Omarchy.
В августе 2025 года 37signals объявила, что в течение трёх лет будет переводить Ruby- и Ops-разработчиков на собственный дистрибутив. В посте All-in on Omarchy at 37signals DHH объяснил решение контролем над рабочей системой и доступом к её исходному коду.
Arch Linux и Hyprland существовали задолго до Omarchy. Вклад DHH состоял в другом: он собрал знакомые технологии в законченный продукт, дал ему название, визуальный стиль и понятную философию. После этого о тех же инструментах заговорила новая аудитория.
Проект Omarchy M для Apple Silicon не означает, что DHH вернулся к macOS или снова полюбил Apple. Он и раньше критиковал закрытую операционную систему, но признавал качество и энергоэффективность железа. Новая идея продолжает ту же позицию: оставить компьютер Apple и заменить операционную систему.
Историю с TypeScript я собирался поставить в тот же ряд, но чем дольше на неё смотрел, тем хуже она подходила под рассказ о смене позиции. В 2023 году DHH объявил, что Turbo 8 отказывается от TypeScript, и сразу напомнил:
“I’ve never been a fan.”
Разворота здесь нет вообще. Зато есть влияние в чистом виде: личное предпочтение создателя проекта превратилось в большой спор о необходимости статической типизации в JavaScript. Для влияния необязательно изобретать технологию или менять позицию. Иногда достаточно принять заметное решение и убедительно объяснить его аудитории.
Где заканчивается применимость его опыта
Чужой опыт позволяет не проверять самостоятельно каждую существующую идею. Проблема начинается, когда два разных утверждения превращаются в одно:
- DHH попробовал технологию, и в его условиях она хорошо сработала;
- DHH использует технологию, значит теперь это правильный способ разработки.
37signals работает в специфических условиях. У компании небольшие команды, десятилетия опыта с Rails, собственная инфраструктурная культура и продукты, которые одни и те же люди развивают много лет. Технический руководитель может постоянно экспериментировать и сам принимать многие архитектурные решения.
Работа с AI особенно зависит от этого контекста. Когда агент пишет изменение, результат проверяет человек с десятилетиями опыта, глубоким знанием системы и сформированным вкусом к архитектуре.
Во втором интервью Лексу DHH приводит показательный пример. Агент выполняет задачу, другой агент проверяет результат, и оба считают решение хорошим. DHH замечает, что оно получилось слишком сложным, просит упростить его и получает вариант почти вдвое короче.
В Basecamp 5 проявилась более серьёзная версия той же проблемы. Дизайнеры с помощью агентов подготовили несколько десятков изменений. Каждое из них по отдельности выглядело разумно, но вместе они нарушили целостность архитектуры. Команде пришлось вручную приводить систему в порядок.
Дело здесь не в силе модели, а в отдельной ответственности: кто-то должен оценивать не только каждый pull request, но и направление, в котором движется система целиком. Локально правильные изменения могут складываться в плохую архитектуру независимо от того, написал их человек или агент.
Модель «AI пишет, человек проверяет» означает разные процессы для опытного инженера и новичка. Проверить можно только то, что умеешь оценивать. Если разработчик не понимает, как выглядит хорошее решение, большой объём автоматически написанного кода не исправит проблему.
Даже DHH не передаёт агентам всю ответственность. В Omarchy он просматривал общую структуру каждого изменения и читал критический код построчно. Часть вспомогательного кода и интерфейса он действительно не изучал подробно, но это осознанная граница, а не полное исчезновение проверки.
То, что работает в 37signals, не переносится автоматически на банк с тысячами разработчиков, стартап из трёх человек, аутсорс-команду или другой Rails-проект. Вместе с подпиской на AI команда не получает опыт DHH, знание его систем и право быстро менять архитектуру продукта.
Почему категоричные позиции так хорошо распространяются
DHH редко формулирует мысль как осторожный набор условий и исключений. Агенты у него становятся магией, Linux даёт контроль над собственной судьбой, а ручное написание кода перестаёт быть экономически оправданным. Такие формулировки запоминаются и запускают споры лучше умеренных выводов.
При этом реальные границы его позиции обычно сложнее заголовка. Переход на Linux не означал отказ от хорошего железа Apple. Работа с Rust не сделала язык приятнее лично для DHH. Отказ от ручного кода не означает, что он перестал смотреть на архитектуру. Но аудитория чаще запоминает короткую категоричную версию.
В тексте Why I retired from the tech crusades DHH сам разбирает этот эффект. В молодости он пытался доказать универсальное превосходство своего стека и долго считал, что именно споры помогли Rails победить. Позже он пришёл к другому выводу: разработчиков убедила демонстрация, в которой за несколько минут было видно, насколько быстро Rails позволяет собрать приложение.
С агентами он действует так же. Сильнее очередного поста работает сам пример: DHH перестал писать Bash, использует агентов для Omarchy и позволяет им создавать части HEY на Rust. Он не только рассказывает об инструменте, но и показывает, что с его помощью делает.
Поэтому его позиция способна менять границы обсуждения. Вопрос «можно ли доверять AI писать production-код» превращается в «как организовать проверку кода агентов». Вместо «зачем Rails-разработчику Rust» появляется «какие части системы можно поручить агенту на Rust».
Новые вопросы не доказывают, что ответы DHH правильны. Они показывают, насколько далеко его личный эксперимент способен сдвинуть профессиональный разговор.
Сам разворот тоже не обязательно считать недостатком. Если инструменты действительно изменились, честно пересмотреть позицию полезнее, чем продолжать защищать старый тезис ради последовательного публичного образа. Проблема начинается, когда очередное мнение известного инженера воспринимают как окончательный ответ для любой команды.
Смотрите на условия, а не на цитату
В IT мы постоянно ищем ориентиры у людей, которым доверяем, и это нормально. Проблемы начинаются, когда мнение авторитетного инженера превращается в самостоятельный аргумент:
DHH сказал, что монолиты лучше.
DHH переводит разработчиков на Linux.
DHH выкидывает TypeScript из Turbo.
DHH перестал писать код руками.
DHH начинает использовать Rust там, где сам писать на нём не хотел.
Авторитет сам по себе ничего из этого не доказывает. Полезнее каждый раз спрашивать:
- какую задачу человек решал;
- какие ограничения у него были;
- какие альтернативы он рассматривал;
- что изменилось по сравнению с его предыдущей позицией;
- какие риски он может себе позволить;
- насколько его ситуация похожа на нашу.
История DHH и AI хорошо показывает, зачем нужны эти вопросы. В июле 2025 года его словами можно было подкрепить статью о необходимости писать код самостоятельно. В сентябре 2026 года словами того же человека можно доказывать экономическую бессмысленность ручного программирования. Обе позиции настоящие, но они относятся к разным возможностям инструментов.
Развороты известных инженеров полезны не готовыми ответами. Они показывают, что изменилось в исходных условиях. У DHH агент получил терминал, тесты и доступ к репозиторию. Вместе с этим у самого DHH остались десятилетия опыта, знание своих систем и способность заметить неудачную архитектуру в сгенерированном коде.
Поэтому вопрос «переобулся ли DHH» мало что даёт. Полезнее спросить: что изменилось в его условиях и произошло ли то же самое у нас?