Почему ваш AI-ассистент тупит (и это не его вина)
Ты сидишь за терминалом, в очередной раз объясняешь Claude 4 Opus, что вот этот кусок кода мы уже обсудили вчера, а он смотрит на тебя пустыми глазами и генерирует то же самое решение, которое ты забраковал час назад. Знакомо?
Проблема не в модели — она в твоём workflow. Большинство разработчиков используют AI-ассистентов как gpt command-line: скинул задачу — получил ответ — вставил — забыл. И так 40 раз в день. Контекст при этом размазывается тонким слоем по всему диалоговому окну. Модель не помнит, что было в соседнем чате, а ты сам уже запутался, на каком шаге остановился.
Я тоже так работал полгода. Результат — 30% кода пришлось переписывать, потому что AI «забывал» архитектурные решения. Пока не наткнулся на идею handoff-driven development.
Handoff-driven development: передача эстафеты, а не просто копипаста
Handoff-driven development (HDD) — это когда ты не просто кидаешь модели задачу, а формируешь спецификацию (spec), передаёшь её в «руки» агенту, получаешь результат, проверяешь и передаёшь дальше. Каждый handoff — это чёткая граница, за которой контекст обновляется. Никакой каши.
В июле 2026 года, когда модели вроде GPT-5 уже научились держать 2 миллиона токенов контекста, проблема не в объёме — она в релевантности. Модель может прочитать всю твою кодовую базу, но она не знает, на чём ты фокусируешься сейчас. Spec решает это: ты явно указываешь, что важно, а что — шум.
Как я писал в статье «Мастерская декомпозиция», правильная постановка задачи — 80% успеха. HDD идёт дальше: не просто задача, а полный набор инструкций, включая критерии приёмки и контекст предыдущих шагов.
Spec-driven: пишем требования как для самого себя, но лучше
В основе HDD лежит spec-driven подход. Ты пишешь не промпт, а спецификацию. Разница колоссальная. Промпт — это «сделай мне кнопку». Spec — это:
- Описание интерфейса (что делает кнопка)
- Ожидаемое поведение в edge cases
- Ссылки на существующий код, к которому нужно адаптироваться
- Критерии, по которым ты будешь принимать работу
Типичная ошибка — пытаться запихнуть всё в один spec. Не надо. Каждый handoff — один логический шаг. Если шаг большой, разбивай. Если маленький — объединяй. Золотое правило: spec должен помещаться в область внимания разработчика (и модели) без скролла.
И да, пиши specs на естественном языке. Markdown, с заголовками, списками, кусками кода для иллюстрации. Не надо псевдоформальных языков — модель их понимает хуже, чем живую речь.
Шаблон репозитория: скелет, который не развалится
Чтобы HDD не превратился в анархию, нужен шаблон репозитория. Я выложил готовый на GitHub (ссылка в профиле). Он включает:
specs/— папка для всех спецификаций с версионированиемhandoffs/— лог передач между разработчиком и AI (или между разными AI)context/— файлы с глобальным контекстом кодовой базы, которые модель читает перед началом работыagents/— конфиги для разных AI-агентов (например, один генерирует код, второй ревьюит)
Исследование «Эхо AI-кодинга» показало, что ассистенты портят собственный код, если не фиксировать контекст. Шаблон как раз фиксирует: каждый handoff записывается, и модель может вернуться к предыдущему решению.
Пошаговый план: как не скатиться в ад бесконечных правок
1 Настрой репозиторий
Склонируй шаблон. В корне будет Makefile с командами: make new-spec, make handoff, make review. Не надо всё делать руками — автоматизируй рутину.
2 Определи цель спринта
Не пиши specs под каждую мелочь. Выдели 3-5 крупных фич на спринт. Для каждой — по spec'у. Остальное — в бэклог.
3 Пиши spec сверху вниз
Начни с общей цели. Потом — архитектурные решения (база данных, API, компоненты). Потом — детали. Заверши acceptance criteria.
Не делай так: «Реализовать регистрацию пользователя». Без контекста модель выдаст решение, которое не впишется в твою архитектуру. Делай так: опиши, как выглядит база, какие поля обязательны, где хранить токены, как обрабатывать ошибки.
4 Запусти handoff агенту
Используй make handoff — скрипт берёт последний spec из папки, подгружает контекст из context/ и отправляет модели через API. Агент возвращает код и логи. Ты проверяешь, если всё ок — переходишь к следующему spec.
5 Ревью и итерация
Ни один AI не пишет код без багов. Используй второй handoff для ревью. Например, как описано в статье «Три мозга вместо одного»: одну модель просишь написать, другую — проверить. Результат конфликта разрешаешь ты.
Типичные ошибки: как угробить методологию за 5 минут
- Слишком длинные specs. Модель теряет фокус. Разбивай на куски по 500-700 слов.
- Spec без контекста. Модель не знает, что ты уже написал 10 тысяч строк. Подгружай контекст из
context/. - Игнорирование истории handoffs. Если модель переписала модуль с нуля, а потом ты вернулся к старому spec — будет конфликт. Веди лог.
- Handoff без проверки. Доверяй, но проверяй. Особенно когда AI генерирует много кода — легко проскочит небезопасная конструкция.
В статье «Как стать незаменимым программистом с AI-ассистентами» я писал про code smells — AI их не видит, пока ты явно не укажешь. Spec должен включать требования к стилю и паттернам.
Прогноз: что будет через год
Через год, к июлю 2027-го, handoff-driven development станет стандартом для команд, где AI — полноправный участник. Уже сейчас появляются фреймворки вроде JanusCoder (о котором мы писали), где модель не только пишет код, но и визуализирует его в SVG, чтобы ты мог увидеть ошибки до компиляции.
Мультимодальные handoff'ы — следующий уровень. Ты передаёшь не только текстовый spec, но и диаграмму, скриншот бага, набросок UI. Модель обрабатывает всё вместе. Это ломает последние барьеры между идеей и реализацией.
Но помни: методология — это инструмент, а не панацея. Если у тебя нет в голове чёткого плана, никакой шаблон репозитория не спасёт. HDD — это про дисциплину. Не жди, что AI сделает всю работу сам. Твоя задача — грамотно передать эстафету.
Неочевидный совет напоследок: не пытайся внедрить HDD на всех проектах сразу. Возьми один, самый мелкий, напиши 3-4 specs, проведи 10 handoffs — и ты поймёшь, где твой поток тормозит. Адаптируй шаблон под себя. И только потом масштабируй.
