Раньше работа строилась так: RFC, разбивка на подзадачи, выполнение по очереди. Так ревью оставалось посильным, но важнейшие решения по структуре принимались до того, как код вообще существовал. Шаг 3 часто ломал шаг 1. Это была плата за то, чтобы ревью было возможным. Теперь её нет.
AI-ассистент пишет рабочий код за часы, план перекраивается в разговоре, а декомпозиция спутанной недельной работы на маленькие PR стала одним промптом. Дорогими остались судейская часть ревью и валидация продукта.
Новый процесс: сначала прогнать план через grill-me, навык Cursor, который заваливает идею встречными вопросами. Если дизайн новый — коммитится спека до кода. Потом строим широко: одна ветка, коммиты как save points, без PR. Затем демо в Slack или предпросмотр. И только потом сплит на PR по границам, которые выявил код. Один промпт создаёт ветки от main и показывает сплит. Стек — только при настоящей зависимости, удаление старого кода — финальным PR.
Пример рефакторинга: пять PR — два бэкенд-эндпоинта от main, два фронтенд-вью поверх API, последний — чистое удаление старого пути. Удалённых строк больше, чем добавленных. Маленькие PR читаются быстро, тяжёлые несут архитектурный риск. Ревью от Adapt отрабатывает за минуты, но только на маленьких PR. Инкрементальный мердж упрощает деплой и откат: сломалось — ревертишь один фокусный кусок.
Цена: ребейз стеков, когда нижний PR получил замечания, и то, что сплит не гарантирует шип — пять PR могут висеть открытыми. Метод подходит для фич с бэкендом и фронтендом, для рефакторингов с неизвестной заранее формой. Миграции и изменения схемы, где порядок важен в продакшене, лучше планировать по-старому.
Вывод: если ты пишешь RFC и гадаешь о границах будущих задач до написания кода, время лучше потратить на прототип. Ответы появятся в конце. Структурное решение никуда не девается — просто с готовым кодом перед глазами его принимать куда дешевле.