DHH перестал писать код руками. Как мнение одного инженера влияет на целую индустрию

В июле 2025 года создатель Ruby on Rails Дэвид Хайнемайер Ханссон, более известный как DHH, говорил, что при работе с AI буквально чувствует, как навык программирования «утекает из пальцев». Через год он почти перестал писать код руками, начал запускать несколько агентов одновременно и объявил со сцены Rails World:

Writing code by hand is no longer an economically viable skill for most programmers at most companies.

Менять мнение нормально, особенно когда меняется технология. Но в случае 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 снова и снова генерировать одни и те же конструкции, но ничего не запоминает. Поэтому он решил изучить язык и писать команды самостоятельно.

В январе 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: интерфейс переносится в нативные приложения, а серверная часть почтового сервиса переписывается на Rust.

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. I’ll tell you what to do. You’ll write it in Rust.

Раньше при выборе языка команда учитывала не только производительность, но и то, насколько удобно людям писать, читать и поддерживать систему. 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 всегда была высокая продуктивность разработчика: выразительный синтаксис, небольшое количество шаблонного кода и короткий путь от идеи до работающего продукта. Если код всё чаще пишет агент, это преимущество не исчезает. Компактный код и соглашения Rails помогают модели ориентироваться в проекте. У Rust и Go при этом остаются статическая типизация и сильные стороны, которые особенно заметны в нагруженных сервисах: эффективная работа с несколькими ядрами и сравнительно небольшие накладные расходы. Rust обходится без сборщика мусора и позволяет экономнее и предсказуемее работать с памятью, а Go использует конкурентный GC с короткими stop-the-world паузами. В MRI по-прежнему есть GIL, и когда нужна CPU-параллельность, приходится добавлять инстансы, а инфраструктура стоит денег.

Этот эксперимент ставит вопрос шире обычного спора о языках:

Нужно ли разработчику любить язык, если большую часть кода на нём пишет агент?

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

Почему мнение DHH становится событием

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

С DHH происходит иначе. Его имя связано не только с фреймворком, но и с целым подходом к разработке: convention over configuration, ставка на обычную реляционную базу не только для данных приложения, но и для кеша. Rails распространял эти идеи вместе с кодом. DHH умеет превращать техническое решение в понятную историю. Это не значит, что решение правильное. Но на него хотя бы начинают смотреть всерьёз. Разработчику невозможно самостоятельно глубоко проверить каждый язык, фреймворк, AI-инструмент и способ деплоя. Приходится решать, на что вообще стоит потратить время.

Когда какой-то разработчик поручает AI писать Rust, это выглядит как личный эксперимент. Когда создатель Rails демонстрирует ту же модель со сцены Rails World и применяет её в своём продукте, сочетание «Rails-разработчик, AI и Rust» идея получает другой вес. И в этот момент начинаешь задумываться: а может, в этом действительно есть смысл? Не обязательно повторять за DHH, но сама идея перестаёт выглядеть маргинальной (хотя бы на время) и превращается в вариант, который некоторые могут использовать для решения своих задач.

Linux и TypeScript: другие способы влиять

С Linux произошла похожая история. DHH много лет пользовался техникой apple, затем собрал Omakub, готовое окружение разработчика на Ubuntu, а позже перешёл на Arch Linux и Hyprland и создал Omarchy.

В августе 2025 года 37signals объявила, что будет постепенно переводить разработчиков на Omarchy. В посте All-in on Omarchy at 37signals DHH объяснил решение контролем над рабочей системой и доступом к её исходному коду.

Arch Linux и Hyprland существовали задолго до Omarchy. Вклад DHH состоял в другом: он собрал знакомые технологии в законченный продукт, дал ему название, визуальный стиль и понятную философию. После этого о тех же инструментах заговорила новая аудитория.

Проект Omarchy M для Apple Silicon не означает, что DHH вернулся к macOS или снова полюбил Apple. Он и раньше критиковал закрытую операционную систему, но признавал качество и энергоэффективность железа. Новая идея продолжает ту же позицию: оставить компьютер Apple и заменить операционную систему.

С TypeScript история немного другая. DHH и раньше говорил, что не любит статическую типизацию. Но в 2023 году он убрал TypeScript из Turbo, и это запустило заметный спор внутри сообщества о том, насколько вообще оправдан отказ от статической типизации в JavaScript-проектах. С DHH я не согласен. Если проект несколько лет развивается на TypeScript, вокруг этого уже формируются привычки команды и контрибьюторов, появляются типы, инструменты и ожидания от проекта. Поэтому мне сложно понять такой подход: сначала экосистема привыкает к TypeScript, а затем курс резко разворачивается обратно в JavaScript. Можно вспомнить CoffeeScript, который Rails когда-то тоже активно продвигал, а затем от него постепенно отошёл. Но ситуация всё же была другой: сам JavaScript за это время сильно изменился — появились классы, модули и другие возможности ES6, ради которых раньше часто и использовали CoffeeScript. TypeScript же в 2023 году не находился в подобном положении и продолжал активно развиваться. Поэтому аргумент «мы и раньше меняли JavaScript-стек» для меня здесь не полностью работает. Вопрос скорее в том, зачем несколько лет двигать проект в сторону TypeScript, если его основной автор всё это время принципиально не разделял саму идею статической типизации.

То, что сам DHH никогда не был фанатом TypeScript, объясняет его позицию, но не до конца объясняет, зачем вообще было столько лет вести проект в эту сторону, если в итоге типизацию решили просто убрать.

Где заканчивается применимость его опыта

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

• DHH попробовал технологию, и в его условиях она хорошо сработала;

• DHH использует технологию, значит теперь это правильный способ разработки.

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

Работа с AI особенно зависит от опыта человека, который проверяет результат. В интервью Лексу DHH приводит хороший пример: один агент выполняет задачу, другой проверяет её и считает решение нормальным. Но DHH видит, что код получился слишком сложным, просит упростить его и получает вариант почти вдвое короче. Похожая проблема возникла и в Basecamp 5. Дизайнеры с помощью агентов подготовили несколько десятков изменений. По отдельности они выглядели нормально, но вместе начали ломать целостность системы, и команде пришлось исправлять это вручную. То есть мало проверить каждый PR отдельно — кто-то всё равно должен следить за тем, куда в целом движется архитектура.

Модель «AI пишет, человек проверяет» означает разные процессы для опытного инженера и новичка. Проверить можно только то, что умеешь оценивать. Если разработчик не понимает, как выглядит хорошее решение, большой объём автоматически написанного кода не исправит проблему. Даже DHH не передавал агентам всю ответственность. В Omarchy он просматривал общую структуру каждого изменения и читал критический код построчно. Часть вспомогательного кода и интерфейса он действительно не изучал подробно, но это осознанная граница, а не полное исчезновение проверки.

Наверное, я сейчас пишу очевидную вещь, но то, что работает в 37signals, не начинает автоматически работать у всех остальных. У компании свои продукты, свои команды, своя инфраструктура и люди с разным опытом. При этом у меня всё чаще возникает ощущение, что отдельные практики из 37signals начинают подаваться уже не как их локальный опыт, а почти как универсальное направление для всей индустрии. И вот с этим я не согласен. Чужой успешный кейс — хороший повод присмотреться к подходу, но не причина автоматически переносить его в совершенно другие условия.

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

DHH редко формулирует мысль как осторожный набор условий и исключений. Агенты у него становятся магией, Linux даёт контроль над собственной судьбой, а ручное написание кода (люблю называть такой код “crafted code”) перестаёт быть экономически оправданным. Такие формулировки запоминаются и запускают споры лучше умеренных выводов.

При этом реальные границы его позиции обычно сложнее заголовка. Работа с 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» мало что даёт. Полезнее спросить: что изменилось в его условиях и произошло ли то же самое у нас?