Разработчик полгода без pull requests: где агентная автоматизация провалилась

Гусев опубликовал разбор на Хабре, в котором описал путь от классического процесса с pull requests до полной передачи кода ИИ-агентам. Статья ценна не тем, что pull requests объявлены устаревшими, а тем, что автор честно показал, где автоматизация провалилась и сколько это стоило. Для авторов и предпринимателей, работающих с ИИ-инструментами, это редкий случай: не теория, а задокументированный личный эксперимент длиной в полгода.

Что понадобится

• VPS (виртуальный выделенный сервер) с доступом к Docker (технология изоляции приложений в контейнерах)
• Аккаунт GitHub с настроенными webhooks (автоматические уведомления о событиях в репозитории)
• ИИ-агент с доступом к коду, например Codex от OpenAI
• Модульная архитектура проекта: отдельные пакеты с чётко описанными зависимостями
• Когнитивный контекст для агентов: спецификации, описания задач, ожидаемые результаты
• Время на настройку: по опыту Гусева, переход занял несколько месяцев итераций

Как Гусев пришёл к отказу от pull requests: пошаговая логика

1. Передал существующий код агенту. В феврале 2025 года Гусев отдал Codex-агенту на переписывание библиотеку @teqfw/di, которую сам разрабатывал с 2019 года. После этого перестал писать код вручную.

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

3. Усложнил цепочку с помощью GitHub Flows. Построил ветвления, повторные проходы, анализ комментариев и pull requests. Фактически воспроизвёл человеческий рабочий процесс, но без людей на промежуточных этапах.

4. Столкнулся с неприемлемой стоимостью. На один простой тикет уходило около 15 минут и примерно 20% пятичасового лимита модели. Webhooks генерировали массу событий, большинство из которых оказывались бесполезными. Гусев отмечает, что точных замеров не проводил, это его субъективное наблюдение.

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

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

7. Дал агентам возможность самопроверки. Агент может создать базу данных (SQLite, PostgreSQL или MariaDB), поднять веб-приложение, обратиться к нему по HTTP, выполнить интеграционные тесты и переделать то, что не работает. Именно это убрало потребность в pull requests как месте встречи автора и проверяющего.

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

Проект, на котором это работает

Текущий проект Гусева называется Personal Digital Embassy. Это два веб-приложения на 11 и 5 пакетов, 4 общих модуля и шесть плагинов. Всего 26 npm-пакетов, не считая платформенных.

Базу платформы Tequila Framework составляют семь npm-пакетов: @teqfw/di, cfg, log, cli, db, web и email. Их код написан агентами. Сверху два пакета для CMS.

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

Что делать с этим прямо сейчас, по ролям

Разработчику. Если у вас модульный проект и VPS, можно попробовать схему Гусева: вынести когнитивный контекст в отдельные репозитории, дать агенту доступ к тестовой среде, перейти от pull requests к формату «спецификация на входе, проверка результата на выходе». Начните с одного изолированного пакета, не с монолита.

Автору Дзена, пишущему о технологиях. Кейс Гусева показывает, как структурировать рассказ об ИИ-автоматизации: не «я подключил ИИ и всё стало классно», а «вот что сработало, вот что нет, вот сколько стоило». Такой формат вызывает доверие и собирает сохранения.

Предпринимателю. Прежде чем убирать pull requests из процесса своей команды, посчитайте стоимость инфраструктуры. Опыт Гусева показывает, что агентная разработка через GitHub webhooks может оказаться дороже ручной. Выгода появляется при прямом запуске на своём сервере, а не при попытке встроить агентов в существующие платформенные процессы.

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