Инженер Adapt показал: с ИИ выгоднее строить фичу целиком, а резать на PR, потом

Автор поста в блоге компании Adapt (проверенное имя не указано в самом тексте, только ник отправителя на Hacker News) описывает, как изменился его рабочий процесс разработки после появления ИИ-помощников для кода. Раньше инженеры сперва писали RFC, дробили фичу на issue и строили их по очереди, каждый следующий шаг блокировался предыдущим: границы работы фиксировались до того, как написана хоть одна строка кода. Причина была не в том, что так удобнее строить, а в том, что вручную распутывать неделю переплетённой работы дороже, чем распланировать её заранее, и деление на issue было единственным доступным способом сделать код-ревью посильным.

По словам автора, три вещи резко подешевели с приходом ИИ-агентов: само написание кода (ИИ-помощник превращает чётко описанную задачу в рабочий код за часы, иногда за минуты); проработка дизайна (план можно обсуждать и переделывать со скоростью разговора); и, главное для этого поста, разбор уже готовой ветки на PR, раньше самая нудная часть работы, теперь это один промпт агенту.

Две вещи при этом не подешевели. Первая, смысловая часть код-ревью: агенты почти бесплатно закрывают механическую часть (единообразие, мелкие придирки, очевидные баги), но не решают за человека вопросы вроде «уместно ли это изменение здесь» или «не аукнется ли такая форма эндпоинта через полгода», по словам автора, одобрение бота не равно тому, что человек понял код, а понимание приходит через чтение, которое доступнее в небольших PR. Вторая, продуктовая проверка: запустить фичу и решить, что это вообще правильная вещь для сборки, по-прежнему медленно; изменилось только то, что рабочую версию всей фичи теперь можно показать людям раньше, чем кто-то прочитает хоть строку кода.

Новый рабочий процесс автора выглядит так: проговорить план до реальных решений; для нестандартного дизайна, зафиксировать спецификацию до кода отдельным PR; строить фичу целиком на одной ветке, сохраняя контрольные точки коммитами; показать демо и собрать обратную связь до того, как кто-то начнёт читать код; и только после этого разрезать готовую ветку на PR по границам, которые проявились в процессе. Для проработки плана автор использует внутренний инструмент «grill-me», он опрашивает автора идеи в несколько раундов, пока в плане не появятся настоящие решения (например: что делать, если вызов API упадёт?). История коммитов на рабочей ветке при этом не становится итоговой записью изменений: один законченный недавно рефакторинг занял больше десятка коммитов за один день по десяткам файлов с чисто техническими сообщениями, это путевые точки для самого автора, а не рассказ для ревьюера. Финальные PR нарезаются заново от main.

Для разбиения на пул-реквесты автор даёт агенту один и тот же промпт: разбить текущую работу на минимальный набор независимо ревьюируемых PR, каждый из которых безопасно смержить отдельно и который приносит пользу пользователю там, где это возможно; создать git worktree и ветку от main под каждый PR; собирать PR в цепочку только там, где зависимость реальна, иначе, ветвить от main; удаление заменяемого кода выносить в отдельный финальный PR; и показать предложенный план разбиения до того, как что-либо будет создано. Один из рефакторингов, описанных автором, в итоге превратился в пять PR: два backend-эндпоинта как параллельные ветки от main, два frontend-PR, каждый поверх своего backend-PR, данные которого он использует, и финальный PR, целиком состоящий из удаления старого пути, он убрал на несколько сотен строк больше, чем добавила вся фича.

Два правила, которые вывел автор: собирать PR в цепочку только при реальной зависимости (иначе выстраивается цепочка перебазирований, о которой пожалеешь при первом же замечании ревьюера к нижнему PR), и удаление старого кода отправлять последним отдельным PR, смешение удаления и создания путает ревьюеров, усложняет откат и прячет чистку в шуме основной фичи.

В самой компании Adapt в качестве ревьюера используют своего же ИИ-агента с контекстом по предыдущей работе: он комментирует PR в течение нескольких минут после открытия, а обмен уточняющими вопросами и мелкими правками закрывается меньше чем за десять минут, но это работает только пока PR достаточно мал, чтобы его можно было быстро прочитать; PR на две тысячи строк, смешивающий несколько задач, такого отношения от человека не получает. У подхода есть и цена: когда ревьюер просит изменить нижний PR в цепочке, приходится перебазировать всё, что стоит выше (автор советует держать открытой ту же сессию чата, которая делала разбиение, и переспрашивать её, а не переносить правки вручную); и разбиение на PR, ещё не то же самое, что доставка: на момент написания поста все пять PR того рефакторинга ещё оставались открытыми, то есть выгода от ревью и точечного отката сохраняется, а выгода от постепенной поставки, нет, если все PR мержатся одним пакетом.

Автор считает подход хорошим выбором для фич, затрагивающих и backend, и frontend одновременно, и для рефакторингов, где итоговая форма кода не ясна заранее, и плохим выбором для миграций и изменений схемы БД, которые нужно строго упорядочить в проде (там планирование заранее по-прежнему оправдано), для задач с одним очевидным местом разреза, и для фич, где первый шаг физически не может быть выпущен отдельно. Правило, которое он предлагает: если вы пишете RFC и гадаете, как разбить его на issue, ещё не построив ничего, это время, скорее всего, лучше потратить на саму сборку.

Ключевые факты

Раньше границы будущих PR фиксировали заранее (RFC → issue → последовательная сборка), потому что вручную распутывать готовую неделю работы было дороже, чем спланировать её вперёд; теперь разбор готовой ветки на PR делает агент по одному промпту.
Подешевели написание кода, обсуждение дизайна и разбиение готовой ветки на PR; не подешевели смысловая часть код-ревью (понимание кода человеком) и продуктовая проверка, решить, что фича вообще нужная.
Пример рефакторинга: пять PR, два backend-эндпоинта как параллельные ветки от main, два frontend-PR каждый поверх своего backend-PR, и один финальный PR только на удаление старого кода, убравший на несколько сотен строк больше, чем добавила вся фича.
Собственный ИИ-ревьюер Adapt комментирует PR в течение минут после открытия, а обмен уточнениями закрывается меньше чем за десять минут, но только пока PR достаточно мал для быстрого чтения.
У подхода есть цена: изменение в нижнем PR цепочки требует перебазировать всё, что построено сверху, а разбиение на PR ещё не значит поставку, все пять PR из примера на момент публикации оставались открытыми.

Почему это важно

Раньше границы будущих PR продумывали до начала работы не потому, что так проще строить, а потому что вручную распутывать неделю переплетённого кода дороже, чем спланировать заранее, деление на issue было единственным доступным способом сделать код-ревью посильным. С приходом ИИ-агентов резко подешевели три вещи: написание кода, обсуждение дизайна и, что здесь главное, разбор уже готовой ветки на отдельные PR: раньше самая нудная часть работы, теперь один промпт. При этом смысловая часть код-ревью (понимает ли человек код, а не просто одобрил его бот) и продуктовая проверка (та ли вещь вообще строится) дешевле не стали, просто рабочую версию всей фичи теперь можно показать людям раньше, чем кто-то откроет код.

Кому это важно

Инженерам и командам, которые уже используют ИИ-помощников для написания кода и хотят применить их дальше, не только к сборке, но и к организации ревью. В первую очередь это касается фич, затрагивающих одновременно backend и frontend, и рефакторингов, где итоговая форма кода заранее не ясна: именно там раньше приходилось гадать с границами issue вслепую.

Как это применить

Автор описывает конкретную последовательность: проговорить план через внутренний инструмент «grill-me», который опрашивает автора идеи в несколько состязательных раундов, пока в плане не появятся реальные решения; для нестандартного дизайна, зафиксировать спецификацию отдельным PR до кода; затем строить фичу целиком на одной ветке, отмечая коммитами контрольные точки, а не этапы для ревьюера; показать демо (короткое видео в Slack или preview-развёртывание) до начала код-ревью; и только потом одним промптом попросить агента разбить готовую ветку на минимальный набор независимо ревьюируемых PR, создавая для каждого отдельную git-ветку от main и собирая PR в цепочку только там, где зависимость реальна. Удаление старого кода выносится в отдельный финальный PR. В примере автора так получилось пять PR из одного рефакторинга: два backend-эндпоинта, два зависимых от них frontend-PR и один PR-удаление.

Можно ли доверять

Это личный опыт одного практикующего инженера, опубликованный в блоге его же компании Adapt; имя автора в тексте не указано (ник на Hacker News, это метаданные площадки, а не подпись в статье), должность и стаж тоже не названы. Автор пишет, что «тестировал этот подход на нескольких проектах», не указывая ни срок, ни число проектов, ни размер команды. Конкретные цифры по одному описанному рефакторингу (пять PR, скорость реакции внутреннего ревьюер-агента) даны предметно и правдоподобно, но это единичный кейс, а не независимо измеренный результат.

Риски и подводные камни

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

«Разбиение на PR, это ещё не доставка.»

— автор поста в блоге Adapt