Почему я больше не использую Pull Requests

В феврале этого года я, Алекс Гусев, отдал Codex-агенту на переписывание @teqfw/di — библиотеку, которую разрабатывал с 2019 года и в которой годами выверял каждую строчку. Об этом я тогда написал на Хабре. С тех пор программный код вручную я больше не пишу. Не потому, что разучился. Просто теперь эту работу делают агенты.

Заодно из моей разработки почти исчезли Pull Requests. Я не перестал пользоваться GitHub и не отменил проверку результатов. Мне перестала быть нужна процедура, в которой кто-то готовит изменение кода, а я разбираюсь, принимать его или нет.

К этому я пришёл не сразу.

Как я автоматизировал разработку, а потом передумал

Сначала мне хотелось построить полноценный конвейер на инфраструктуре GitHub. Я подключил webhooks и научил агентов публиковать страницы моего сайта по тикетам пользователей. В мае рассказал об этом эксперименте: пользователь открывает Issue, система выбирает нужный профиль агента, запускает его в Docker-контейнере, а на выходе может появиться страница сайта, опубликованная через GitHub Actions. Там было восемь профилей агентов с разными стартовыми промптами.

Затем появилось приложение GitHub Flows, которое позволяло строить такие цепочки по событиям GitHub: с ветвлениями, повторными проходами, анализом комментариев и Pull Requests. В общем, я попытался организовать агентам привычную «человеческую» разработку, только без людей на промежуточных этапах.

Работало. Но стоимость этой организации меня неприятно удивила. На обработку одного простого тикета могло уходить минут пятнадцать и примерно 20% пятичасового лимита использования модели. Webhooks присылали массу событий, из которых действительно полезными оказывались далеко не все. Даже публикация довольно примитивных страниц сайта с использованием самой лёгкой модели съедала ощутимые ресурсы.

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

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

Теперь у агентов есть сервер

Моя платформа Tequila Framework изначально рассчитана на модульный монолит. Это следствие многолетней работы с Magento и знакомства с такими системами, как Spring, Symfony, Laravel, Drupal и WordPress. Отдельные пакеты, зависимости между ними, позднее связывание через DI — мне такая архитектура привычна задолго до появления LLM-агентов.

Базу платформы составляют семь npm-пакетов: @teqfw/di, cfg, log, cli, db, web и email (все с префиксом @teqfw/). Их нынешний код написан агентами. Сверху есть ещё два пакета для CMS — @flancer32/teq-cms и .../teq-tmpl.

Мой текущий проект называется Personal Digital Embassy. В нём два веб-приложения — на 11 и 5 пакетов, 4 общих модуля (sdk) и (пока) шесть плагинов. Итого 26 npm-пакетов, не считая платформенных (teqfw). Всё это продолжает развиваться, и код по-прежнему пишут агенты.

На VPS лежат репозитории с кодом и репозитории с их когнитивными контекстами. Агенты работают в одном файловом пространстве. Могут параллельно изменять независимые пакеты, а могут монопольно работать сразу с несколькими, если задача затрагивает их совместно. При необходимости сами клонируют репозитории. У них есть доступ к GitHub, npm и инструментам развёртывания.

У них есть и возможность проверить написанное. Агент может создать настоящую базу данных — SQLite, PostgreSQL или MariaDB, поднять веб-приложение, обратиться к нему по HTTP, выполнить интеграционные тесты и переделать то, что не работает. DI позволяет подменять окружение на разных уровнях, но вовсе не обязывает ограничиваться моками. Проверять можно и на реальных компонентах.

Именно поэтому мне не требуется PR как отдельное место встречи автора кода и проверяющего. Агент может пройти весь технический цикл внутри своего рабочего контекста. Это, конечно, не гарантия отсутствия ошибок. Тесты проверяют то, что мы сумели предусмотреть, а последним испытанием программы всё равно остаётся её использование конечным потребителем.

Я стою в начале и в конце

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

Так я применяю свою методологию ADSM: сначала спецификации и когнитивный контекст, потом код. Причём исходники моих Open Source пакетов публичны, а спецификации намеренно вынесены в приватные репозитории. Можно посмотреть, как устроена программа, изменить её, сделать форк. Но контекст, определяющий направление её развития, у меня свой.

Есть у такого подхода неприятное следствие. Самым слабым звеном системы оказался я. Агенты способны производить изменения быстрее, чем я успеваю разбираться в том, что они натворили. Запустить ещё одного агента проще, чем найти время на изучение результатов работы предыдущего.

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

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

Мне нужна проблема, а не готовое исправление

В Personal Digital Embassy постоянно обнаруживается, что какому-нибудь базовому пакету TeqFW не хватает функциональности. Тогда я использую GitHub Issues. Агент, работающий над приложением, описывает проблему и ожидаемое поведение в репозитории соответствующего пакета. Другой агент, уже в контексте этого пакета, занимается решением.

Например, при развёртывании PDE Hub выяснилось, что лог подключения к PostgreSQL мог сообщать имя SQLite-файла. Тикет в teqfw/db описывает, как воспроизводится ошибка, почему возникает путаница и что нужно проверить после исправления. В другом тикете возникла потребность выделять идентификатор записи до её вставки в БД. Там уже пришлось описывать требования к транзакциям, переносимости между СУБД и совместимости с существующим поведением. И постановку задачи, и решение — всё делали агенты.

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

Раньше PR был отличным подарком сопровождающему Open Source проекта. Кто-то изучил код, нашёл ошибку и потратил своё время на исправление. Теперь стоимость производства кода резко снизилась, а стоимость его понимания — не особенно. Особенно когда чужой разработчик не располагает спецификациями и историей архитектурных решений.

Это не значит, что любой Issue полезен, а любой PR бесполезен. Сгенерировать бессмысленный тикет агенту тоже ничего не стоит. И бывают изменения, в которых внешний участник приносит незаменимую экспертизу. Но в моей повседневной разработке описание реальной проблемы стало ценнее, чем попытка заранее решить её за меня.

Мне кажется, со временем это может изменить и культуру Open Source. Мы привыкли считать готовый код главной формой участия в чужом проекте. А если код перестаёт быть дефицитом? Возможно, главным вкладом окажется способность обнаружить проблему, воспроизвести её и объяснить, чего не хватает пользователю.

Кто отвечает за результат?

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

Автор PR, конечно, отвечает за качество предложенного изменения. Но после принятия PR поддерживать его придётся сопровождающему проекта. Пользователь придёт с ошибкой к тому, кто выпустил продукт, а не к тому, кто однажды прислал патч. С агентами это разделение стало совершенно наглядным: агент написал код, а отвечать за его работу предстоит мне.

Автор программного продукта больше не обязательно должен быть автором его программного кода. Код могут писать агенты. Но ответственность за результат по-прежнему остаётся за человеком, который принимает решение его опубликовать.

Поэтому мне нужны ваши сообщения об ошибках, ваши замечания и предложения. Но не ваши Pull Requests.

Ведь каждый принятый PR — это моя ответственность за чужой код. А у меня теперь этого кода...