Дэвид Хайнемайер Ханссон, или DHH, — создатель веб-фреймворка Ruby on Rails, совладелец и технический директор 37signals. Компания выпускает сервис управления проектами Basecamp и почтовый сервис HEY. Ещё недавно DHH защищал ручное программирование и говорил о коде как о ремесле: хороший программист решает задачу и выстраивает понятную, пластичную систему.
В новом разговоре с Лексом Фридманом DHH описывает уже другой способ работы — agentic engineering. В дистрибутиве Omarchy он отдаёт ИИ-агентам почти всю реализацию, ведёт несколько задач параллельно и всё реже пишет код сам.
DHH в разговоре с Лексом Фридманом. Кадр из выпуска № 501.
DHH оговаривается, что проценты написанного ИИ кода трудно сравнивать без контекста. Перемена в его собственной работе при этом заметна: человек, который двадцать пять лет связывал качество продукта с качеством написанного вручную кода, перенёс внимание на замысел, отбор и проверку.
В технологической части пятичасового выпуска DHH рассказывает, что изменило его отношение к ИИ, как устроена его работа с агентами и какая роль остаётся человеку.
Перелом случился не тогда, когда ИИ научился дописывать код
DHH не считает, что год назад ошибался в оценке ИИ. Автодополнение и чат помогали ему работать чуть быстрее, но не меняли сам процесс. Перелом начался, когда модели получили инструменты: доступ к репозиторию и терминалу, возможность запускать тесты, смотреть результат и исправлять собственные ошибки.
Генератор кода отвечает на запрос. Агент проходит рабочий цикл целиком:
- исследует задачу и существующую систему;
- предлагает или выбирает способ решения;
- меняет несколько связанных частей продукта;
- запускает проверки;
- разбирает ошибки и повторяет попытку;
- готовит результат к просмотру человеком.
По словам DHH, сначала агент лишь быстрее ехал по маршруту, который задавал программист. Затем стало достаточно описать проблему, а маршрут агент начал строить сам. Именно переход от исполнения инструкции к самостоятельному поиску решения изменил его отношение к технологии (05:54).
В описании DHH агент работает не изолированно: он получает доступ к коду и инструментам, запускает проверки, видит ошибки и доводит задачу до результата, который можно оценить.
Узким местом становятся идеи и решения
Когда производство кода ускоряется, большие продукты не начинают развиваться в десять раз быстрее. DHH объясняет это просто: в зрелой компании реализация редко ограничивает скорость сильнее, чем коммуникация.
Продуктовый менеджер формулирует задачу, дизайнер готовит решение, руководители согласуют приоритет, разработчики уточняют ограничения. Агент может сократить последнюю часть цепочки, но не убирает ожидание ответа и конфликт интересов между участниками.
Есть и более неприятное ограничение: компании часто не знают, что именно хотят сделать. Дополнительная мощность помогает быстрее реализовать идеи, но не делает слабую идею сильной. Большой объём кода никогда не гарантировал хороший продукт; теперь получить этот объём стало лишь дешевле (18:44).
После удешевления реализации DHH называет дефицитом другие составляющие продукта:
- идеи и понимание того, какой продукт нужен;
- видение направления и границ продукта;
- вкус — способность отличить цельное решение от формально работающего;
- человеческая скорость общения и принятия решений.
DHH разделяет vibe coding и agentic engineering
DHH называет vibe coding работу, в которой человек просит агента сделать программу и не смотрит, как она устроена. Для личного инструмента такой подход может быть разумным. Если приложение решает задачу одного пользователя, результат легко проверить через интерфейс, а цена ошибки невелика. Внутреннее устройство можно воспринимать как чёрный ящик.
В существующем продукте последствия накапливаются. DHH приводит пример Basecamp: отдельные изменения, созданные агентами для дизайнеров, выглядели приемлемо, но вместе разрушали связность архитектуры. Команде пришлось разбирать результат вручную (15:43).
Локально правильный pull request может добавить второй способ делать то же самое, нарушить границу модуля или закрепить случайное решение как новый стандарт. В рассказе DHH разница между двумя подходами проходит по контексту и цене ошибки: личный одноразовый инструмент можно оставить чёрным ящиком, а изменения в Basecamp приходится оценивать как часть большой системы.
Ценность архитектуры пока сохраняется
DHH ставит под вопрос прежнюю экономику красивого кода. Понятная архитектура была нужна в том числе потому, что людям приходится годами читать и менять систему. Если будущие изменения выполнит агент, часть этой ценности может исчезнуть.
Но сегодня эта ценность исчезла не полностью. Запутанный проект требует от агента больше контекста, порождает больше ошибочных изменений и усложняет проверку. DHH оставляет вопрос о будущей роли архитектуры открытым, но признаёт, что связная система пока экономит контекст и помогает не накапливать случайные решения (1:00:35).
Человек становится продуктовым руководителем и редактором
DHH утверждает, что опытный программист не всегда лучше управляет агентом. Знание реализации провоцирует заранее диктовать путь, хотя модель уже может найти более удачный.
Навыки, которые DHH связывает с новой ролью, ближе к продуктовой работе. Человек определяет:
- пользователь продукта;
- проблема, которую продукт решает;
- состав первой версии;
- текущий приоритет;
- признак работающего решения;
- достаточный для выпуска уровень качества.
DHH сравнивает свою роль с редактором. Ему не обязательно переписывать решение самому, чтобы заметить лишнюю сложность или неправильные пропорции. Иногда достаточно сказать: «Для этой задачи получилось слишком сложно», — и агент сокращает реализацию вдвое (2:14:32).
Эту способность оценивать пропорции, сложность и целостность решения DHH называет вкусом. Лекс Фридман добавляет к ней системное мышление: человеку по-прежнему приходится понимать, как отдельное изменение влияет на продукт целиком.
Подробная спецификация уступает коротким итерациям
По мнению DHH, подробная спецификация не всегда улучшает результат. Если человек заранее задаёт структуру решения, он ограничивает поиск тем, что уже знает сам.
DHH связывает работу с агентами с исходной идеей гибкой разработки: невозможно окончательно понять продукт до того, как начнёшь им пользоваться. В его подходе агент сначала создаёт небольшой работающий вариант, человек испытывает его на реальном сценарии, указывает конкретный недостаток и повторяет цикл (57:25).
Отдельно DHH говорит о сравнении вариантов. Из трёх решений человеку обычно легко выбрать сильнейшее, тогда как двадцать два варианта уже создают лишнюю нагрузку. Поэтому он предпочитает получать несколько различающихся реализаций и оценивать их на одном сценарии (59:18).
Работа становится параллельной — и сильнее утомляет
Ручное программирование обычно однопоточно: человек погружается в одну задачу и последовательно ведёт её к результату. Агенту требуется время на исследование и выполнение, поэтому ожидание подталкивает запустить вторую задачу, затем третью.
DHH описывает работу примерно с шестнадцатью параллельными потоками на нескольких машинах. Это его личный эксперимент. При таком режиме его основным интерфейсом становится обзор задач, их состояния и решений, которые ждут человека (1:31:57).
Чат плохо подходит для такой работы, потому что провоцирует ждать ответа. Очередь асинхронных поручений ближе к взаимодействию с командой: агент получает задачу, возвращается с результатом, а человек подключается в точке решения (2:42:34).
У этой скорости есть цена. Постоянное переключение держит человека на пределе внимания. DHH называет свой темп последних месяцев неустойчивым и ожидает, что всё больше проверки и сортировки возьмёт на себя автоматизация (2:47:57).
Сам DHH не считает число одновременных агентов показателем эффективности. Его опыт показывает и обратную сторону параллельности: когда человек не успевает принимать решения и проверять результат, растёт очередь незавершённой работы.
DHH поручает проверку другой модели
Выбор моделей занимает заметную часть разговора. В текущем процессе DHH одна модель исследует и реализует задачу, Codex с максимальным уровнем рассуждений проводит ревью, а Copilot дополнительно проверяет изменения в GitHub (2:38:14). Замечания возвращаются исполнителю, после чего решение оценивает человек.
DHH сравнивает этот контур с обычным ревью кода: отдельный проверяющий способен заметить ошибку или лишнюю сложность, которую пропустил автор. В его процессе эту роль выполняет другая модель.
Открытый код получит больше участников — и больше фильтрации
Агенты снижают порог входа в open source. Человек с хорошей идеей может подготовить реализацию, тесты, описание и релиз, даже если раньше не владел нужным языком или инструментами.
Для владельца проекта это одновременно подарок и нагрузка. DHH рассказывает, что в Omarchy агенты предварительно сортируют pull request: отсеивают дубликаты и ошибочные изменения, проверяют остальные в виртуальной машине и передают человеку только решения, готовые к выбору (33:46).
DHH ожидает, что поток изменений в открытые проекты вырастет, поэтому часть первичной проверки тоже перейдёт к агентам. За мейнтейнером остаются направление проекта и окончательное решение: принять изменение или отклонить его.
Почему агенты полюбили Linux
DHH отдельно говорит о Linux. Раньше конфигурационные файлы, командная строка и подробные сообщения об ошибках делали систему сложной для массового пользователя. Для агента те же свойства стали удобным интерфейсом.
Рабочий стол Omarchy: мониторинг ресурсов, сведения о системе и терминал. Источник — официальное руководство Omarchy.
Агент может прочитать конфигурацию, вызвать команду, изучить лог, найти исходный код упавшей программы, предложить исправление и повторить проверку. В закрытом графическом интерфейсе многие из этих действий недоступны или плохо воспроизводятся (1:40:37).
Победу Linux на персональных компьютерах DHH формулирует именно как прогноз. Он объясняет его тем, что открытая и наблюдаемая система удобна агентам: её действия можно автоматизировать, состояние — исследовать, а ошибки — воспроизвести и диагностировать.
DHH отвергает строки кода как метрику
Параллельные агенты легко создают впечатляющие объёмы изменений. DHH сам оговаривается, что число строк — плохая метрика. Для него имеет значение, что именно построено и какую проблему решает результат (1:38:55).
Пять главных инсайтов записи
- Агенты изменили сам способ программирования. Перелом для DHH произошёл, когда модель смогла исследовать репозиторий, пользоваться инструментами, запускать проверки и самостоятельно искать путь к решению. В его рассказе agentic engineering отличается от генерации отдельных фрагментов кода полным циклом работы над задачей.
- Реализация перестаёт быть главным дефицитом. Чем дешевле становится производство кода, тем заметнее другие ограничения: нехватка сильных идей, ясного видения, вкуса и быстрых человеческих решений. Большой объём автоматически созданного кода сам по себе не делает продукт лучше.
- Роль программиста смещается к направлению и отбору. DHH всё реже диктует способ реализации и всё чаще действует как продуктовый руководитель и редактор: формулирует проблему, сравнивает варианты, убирает лишнюю сложность и решает, что готово к выпуску.
- Параллельность ускоряет работу и перегружает человека. Несколько агентов могут одновременно вести разные задачи, но решения и проверка по-прежнему требуют человеческого внимания. Поэтому DHH дополняет параллельную работу асинхронной очередью и ревью с помощью других моделей, хотя собственный нынешний темп считает неустойчивым.
- Открытые и наблюдаемые системы получают преимущество. Командная строка, конфигурационные файлы, подробные ошибки и доступный исходный код дают агенту среду, которую он может исследовать и исправлять. С этим DHH связывает новый интерес к Linux и ожидаемый рост числа участников open source.
DHH оставляет открытым вопрос, насколько быстро ручное программирование будет сокращаться дальше. Этот переход он описывает на примере Omarchy: агенты выполняют реализацию, а человек задаёт направление, оценивает результат и принимает окончательное решение.
Полная расшифровка выпуска опубликована на сайте Лекса Фридмана. В статье использованы тезисы из технологических глав; оценки скорости, стоимости и качества моделей переданы как личный опыт DHH, а не как независимые тесты.