Паттерны передачи модели для долгих инженерных проектов

Почему долгие задачи сбиваются с курса

Длительные инженерные задачи часто съезжают по простой причине: один чат пытается вместить всю работу.

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

В одном плотном разговоре модель должна жонглировать запросом, текущим кодом, логами, отзывами ревьюеров и временными предположениями. Когда контекст заполняется, новые детали начинают вытеснять старые ограничения. Новый стек трейс может стать важнее правила, заданного 50 сообщений назад. Если команда сказала "не менять схему базы данных", это правило тихо исчезает за заплатками, ретраями и объяснениями.

Здесь и начинаются плохие передачи. Кто‑то думает, что планирование завершено, но этап кодирования начинается, имея в фокусе только часть плана. Затем та же ветка переходит в режим ревью, всё ещё неся допущения из этапа кодирования. Ревью теряет дистанцию. Оно перестаёт быть настоящей проверкой.

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

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

Решение — не в лучшем монологе. Решение — в лучшем разделении.

Разделите работу на три задачи

Длительные задачи становятся проще, когда планирование, кодирование и проверка перестают делить одно и то же перегруженное пространство.

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

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

Когда один поток пытается делать все три, мелкие допущения остаются слишком надолго. Догадка, сделанная на этапе планирования, прокрадывается в реализацию. Латание, сделанное на этапе кодирования, защищается на ревью. Модель тогда судит работу, в которую она уже сама себя убедила.

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

Звучит почти слишком очевидно, но это экономит реальное время. Команды тратят меньше усилий на распутывание смешанных инструкций и больше — на исправление реальных проблем.

Составьте бриф планирования, которым можно пользоваться

Хороший бриф не даст одному человеку подробно спланировать изменение, а другому закодировать не то.

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

Затем нарисуйте жёсткую границу объёма. Скажите, что можно менять, а что обязательно должно остаться нетронутым. Кодеру должно быть известно, можно ли переименовывать API, менять форму данных, трогать тесты или обновлять UI‑копирайт до открытия редактора.

Большинство полезных брифов отвечают на пять вещей:

1. Какова цель?
2. Какие файлы, сервисы или документы задействованы?
3. Какие ограничения важны?
4. Как выглядит «сделано»?
5. Что под запретом?

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

Входные данные тоже важны. Назовите файлы для первичной проверки, укажите существующие тесты и обозначьте любые границы объёма. Если изменение должно остаться внутри одного сервиса или одного PR, скажите об этом. Если кодеру нужны примерные данные или тестовый падающий кейс — приложите его.

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

Это совпадает с практическим паттерном, который используют в AI‑поддержке разработки на oleg.is: один раз рассортировать проблему, написать короткий бриф и передать только то, что действительно нужно следующему этапу. Большие дампы контекста кажутся тщательными, но обычно создают больше дрейфа, чем ясности.

Выполняйте передачу шаг за шагом

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

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

Простая последовательность работает хорошо:

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

План по файлам важнее, чем многие команды ожидают. "Обновить auth" — слишком широко. "Изменить валидацию формы логина в app/login, скорректировать проверки сессии в обработчике API и добавить один регрессионный тест" даёт кодеру путь и ускоряет ревью.

Предположения заслуживают отдельной строки перед началом кода. Если кодер предполагает, что feature flag уже существует, или что валидацией владеет один сервис, запишите это сначала. Поймать неверное предположение займёт секунды. Исправлять код, построенный на нём, — часы.

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

Например, если команда меняет фронтенд на Next.js и Go API, следующему запуску не нужны все утренние подсказки. Ему нужен текущий план, последняя сводка и жёсткие ограничения. Этого достаточно, чтобы продолжать работу, не давая ограничению контекста увести задачу с курса.

Проверяйте в чистом контексте

Ревью работает лучше, когда ревьюер начинает с чистого контекста.

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

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

Ревьюер должен сначала сверять код с брифом, а не с объяснением кодера. Объяснения могут звучать опрятно, даже если патч промахнулся по сути. Начните с прямых вопросов: решает ли изменение запрошенную проблему, остаётся ли в рамках объёма и нарушает ли какие‑то заявленные правила?

Потом проверьте углы. Длинные задачи часто проваливаются там. Функция может работать в «счастливом пути», но падать на пустом вводе, повторных запросах, старых данных или частичных ошибках. Этап проверки не для восхищения кодом. Он для сомнения.

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

После этого примите простое решение. Принять, если изменение соответствует брифу и доказательства достаточны. Исправить в ревью, если проблема мала и очевидна. Отправить обратно, если код ушёл в сторону, скрывает риск или лишён доказательств.

Малой стартап‑команде это может сэкономить часы. Одна модель пишет патч, другая проверяет его в свежем контексте, и человек принимает окончательное решение по рискам.

Простой сценарий в пример

Допустим, команда стартапа хочет небольшую фичу: дать администраторам аккаунта экспортировать за последние 30 дней записи аудита в CSV.

Это удобно как задача для передачи, потому что затрагивает поведение продукта, бэкенд‑логику и тесты, но остаётся достаточно маленькой, чтобы закончиться за пару проходов.

Планировщик не пишет код. Он превращает тикет в короткий бриф, который кто‑то другой может использовать, не читая недельной истории чата. Бриф говорит: цель — экспорт логов аудита для одной рабочей области. Лимиты: только 30 дней, только админы, только CSV. Указывает вероятные файлы: аудит API, задача экспорта, страница настроек администратора и тест‑сьют. Также отмечает риски: большие выгрузки, проверки прав и форматирование дат по часовым поясам. «Готово» означает: CSV скачивается корректно, пустые выгрузки работают, а обычные пользователи блокированы.

Кодер берёт бриф в свежем контексте и работает порциями. Сначала бэкенд‑эндпоинт и проверка прав. Потом генерация CSV и ограничение запроса на 30 дней. Затем кнопка на странице администратора и тесты для админов и обычных пользователей.

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

Потом проверяющий открывает другой свежий контекст. Он читает бриф, сканирует дифф и тестирует фичу как скептический пользователь. Экспорт работает. Права работают. Кнопка появляется в нужном месте. Одна проблема всё же пролезла: записи, созданные около полуночи по UTC, показывают неверную дату для администратора в другом часовом поясе.

Это возвращается как маленькая передача: хранить метки времени в UTC, форматировать даты под часовой пояс пользователя при выводе в CSV и добавить тест, пересекающий полночь. Кодер исправляет этот случай, не открывая заново всю задачу.

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

Ошибки, которые ломают процесс

Длинные задачи обычно проваливаются по банальным причинам.

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

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

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

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

Следите за несколькими ранними предупреждениями:

• Подсказка для кодирования включает отклонённые идеи, устаревшие дебаты и несвязанные логи.
• Дифф затрагивает больше файлов, чем было в брифе.
• Никто не может показать короткую сводку передачи.
• Ревьюер начинает править вместо ревью.
• Тесты зелёные, но результат не соответствует утверждённому поведению.

Когда эти признаки появляются, остановитесь и сбросьте процесс, прежде чем путаница расширится.

Быстрые проверки перед каждой передачей

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

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

Затем прочитайте бриф как незнакомец. Он должен называть файлы или модули, границы изменения и риски. Если там написано "обновить auth flow", но не указаны middleware, логика сессий или риск отката, следующий человек заполнит пробелы и, вероятно, ошибётся.

Используйте короткий чеклист:

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

Проверка диффа важна. Люди и модели лучше суммируют намерения, чем результат. Сводка может сказать "добавлена валидация", а дифф параллельно удалил fallback, сменил значение конфига или пропустил один тест‑файл. Читайте дифф и сводку рядом.

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

Завершите письменной заметкой для следующего шага. Часто одной строки достаточно: "Ограничение API ещё не тестировано" или "Порядок миграции требует ревью." Хорошие передачи кажутся почти скучными — и это обычно хороший знак.

Когда нужно сбрасывать контекст

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

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

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

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

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

Малые именованные передачи побеждают одну гигантскую сессию. "Спланировать рефакторинг auth", "Реализовать изменение token refresh" и "Проверить крайние случаи логина" дают людям и моделям чистую полосу. "Допилить auth" приглашает дрейф.

Следующие шаги для вашей команды

Начните с малого. Не пытайтесь ввести это во все репозитории сразу. Выберите одну задачу, которую команда повторяет часто: исправление одних и тех же багов, выпуск небольшой фичи или обновление API с тестами. Узкое испытание делает процесс легче для оценки, потому что работа остаётся знакомой.

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

Затем отслеживайте то, что команда уже ощущает на практике: переделки, время на ревью и баги, которые проскочили. Если это сокращает один раунд ревью и экономит 20 минут на задаче — люди быстро это заметят.

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

Если ваша команда сильно полагается на AI‑кодирование и результаты всё ещё разношерстны, внешний обзор процесса может помочь. Oleg Sotnikov через oleg.is консультирует стартапы и маленькие команды по практической AI‑поддержке разработки и работе Fractional CTO. Полезная часть — не больше церемоний, а настройка передачи, которая подходит вашей команде, стеку и типичным ошибкам.

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