Handoff driven development: как не терять контекст ИИ-ассистента между сессиями

Подход вырос из SDD (spec-driven development, разработка через спецификации) и добавляет к нему механику передачи контекста между сессиями. Вместо того чтобы каждый раз заново объяснять модели, где что лежит и что уже сделано, разработчик выстраивает иерархию карт спецификаций. Модель сама спускается по ссылкам, находит нужное за два-три перехода и не грузит лишнего. Практика рассчитана на соло-разработчиков и небольшие команды без бюджета на полмиллиона долларов токенов.

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

• ИИ-ассистент с поддержкой длинного контекста (Claude Opus, Claude Sonnet или аналог)
• Монорепозиторий или проект с несколькими подпроектами
• Текстовый редактор с поддержкой Markdown-ссылок (VS Code, Cursor, любой IDE)
• Готовность завести папку specs/ в каждом подпроекте
• 30 минут на первичную настройку структуры, дальше поддержка занимает минуты

Пошаговая инструкция

1. Создайте корневую карту спецификаций. В корне репозитория заведите файл specs/map.md. Это входная точка: отсюда модель начинает навигацию. Карта содержит Markdown-ссылки на карты подпроектов и ничего больше.

2. Заведите локальные карты в каждом подпроекте. Внутри каждого подпроекта создайте свою specs/map.md со ссылками на конкретные спецификации этого подпроекта. Получается иерархия: корень ведёт к подпроекту, подпроект ведёт к документу.

3. Ограничьте глубину двумя-тремя уровнями. Корень, подпроект, при необходимости пакет. Каждый лишний уровень это переход, который модель должна совершить прежде, чем доберётся до содержания. Четыре уровня уже избыточны.

4. Присвойте каждому файлу спецификации жанр. Жанры взяты из фреймворка Diátaxis (система классификации технической документации по назначению), но адаптированы:

5. as-built: описание существующего кода, архитектурные обзоры

6. plan: план реализации конкретной задачи или фичи (временный, после выполнения «умирает»)
7. reference: справочники, исследования, обоснования
8. vision: видение продукта, бизнес-гипотезы

9. log: журнал архитектурных решений (ADR, architecture decision records), работает только на дополнение: каждая запись фиксирует контекст, решение и последствия

10. Поставьте каждому файлу статус и дату сверки. Прямо под заголовком, одной строкой:

Статус: as-built / current · сверено: 2025-07-03

Дата сверки означает именно сверку содержимого с кодом, а не дату последней правки текста. Исправить опечатку не значит сверить.

1. Используйте статус stale вместо устаревшей документации. Если обновить спецификацию прямо сейчас невозможно, поставьте ей статус stale (устаревшая). Модель, увидев этот статус, поймёт: документу не доверять, проверить по коду. Долг не погашен, но он явно помечен, а не замаскирован.

2. Хороните мёртвые документы, а не копите их. Выполненный план, который выглядит как актуальный, это дезинформация. Протокол: удалите файл физически (архив уже есть, это git), а в карте оставьте «надгробие» (tombstone): одну строку с именем файла, датой удаления и пометкой «git-история». Кладбище, которое притворяется библиотекой, бьёт по чистоте контекста.

3. Проверяйте инвариант достижимости. Каждый файл спецификации должен быть достижим по цепочке Markdown-ссылок хотя бы от одной карты. Голый текстовый путь без ссылки связью не считается. Недостижимый файл это «сирота», документ, которого модель не найдёт. Для отлова сирот используют аудит-скрипт.

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

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

Разработчику-одиночке. Начните с одного подпроекта: заведите specs/map.md, опишите текущее состояние кода в as-built-спеке, текущую задачу в plan-спеке. Уже на второй сессии вы почувствуете разницу: не надо пересказывать модели, «на чём мы остановились».

Автору Дзена или контент-маркетологу. Принцип иерархических карт работает не только для кода. Если вы ведёте несколько рубрик и используете ИИ-ассистент для текстов, заведите аналогичную структуру: карта проекта со ссылками на редполитику, tone of voice, текущие задачи по рубрикам. Каждый новый чат начинайте с указания на карту, а не с пересказа всего контекста.

Предпринимателю в РФ и СНГ. Метод не привязан к конкретной модели. Он работает с Claude (Anthropic), с ChatGPT (OpenAI), с GigaChat и YandexGPT, если у модели есть возможность читать файлы по ссылкам или принимать их в контекст. Из доступных в РФ вариантов GigaChat и YandexGPT поддерживают загрузку файлов, хотя длина контекста у них пока короче.

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