Context Anchoring

📖 Источник: martinfowler.com

Context Anchoring: как сохранить контекст при работе с AI-ассистентами

Введение

При работе с AI-инструментами для программирования (Claude, Cursor, Copilot) контекст разговора постепенно разрушается. Исследование Stanford и Berkeley 2023 года под названием «Lost in the Middle» демонстрирует, что языковые модели значительно хуже обрабатывают информацию, размещённую в середине длинного контекста, по сравнению с началом или концом. Автор предлагает решение: фиксировать решения во внешних документах — практику, которую называет context anchoring (заякоривание контекста).

Проблема: разрушение контекста

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

Ключевая проблема, которую выявил автор на практике: рассуждения за решениями разрушаются быстрее, чем сами решения. AI может помнить «мы используем PostgreSQL», но забыть, почему PostgreSQL был выбран вместо MongoDB: потребность в JSONB, экспертиза команды в операционной работе, мультитенантные требования. В результате AI предлагает схему, подходящую для документной базы, но не для реляционной — технически соответствующую выбору, но архитектурно ошибочную.

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

Решение: внешняя память

Автор предлагает концепцию feature-документа — живого документа, который существует вне разговора, фиксирует решения по мере их принятия и служит авторитетным источником для человека и AI между сессиями.

Важно различать два уровня документов:

• Priming document (проектный уровень): стек технологий, архитектурные паттерны, соглашения об именовании. Обновляется раз в квартал или при значительных изменениях. Применяется ко всем фичам.
• Feature document (уровень фичи): конкретные решения, сделанные при разработке, ограничения, что было рассмотрено и отклонено, открытые вопросы, текущее состояние прогресса. Обновляется каждую сессию.

Код показывает результат, но не рассуждения. Код с использованием BullMQ не покажет, что абстракция RetryQueue была предложена, обсуждена и намеренно отклонена. Feature-документ фиксирует это.

Практический бонус: документ на 50 строк несёт тот же контекст решений, что тысячи строк кода, и требует меньше токенов — модель работает стабильнее.

Исторический контекст: ADRs

Автор проводит параллель с Architecture Decision Records (ADRs), предложенными Michael Nygard в 2011 году. ADRs существуют потому, что опытные инженеры признали: рассуждения за кодом не менее ценны, чем сам код, и значительно более хрупкие.

Feature-документ — это, по сути, живой ADR в процессе работы, эволюционирующий в реальном времени, а не написанный постфактум. Для команд, уже использующих ADRs, значимые решения из feature-документа «переходят» в формальные ADRs после запуска фичи.

Практический пример: Notification Service v1

Автор приводит конкретный пример из своей практики. После дизайн-сессии (подтверждение возможностей, обсуждение компонентов, согласование контрактов) он зафиксировал решения в feature-документе:

📊 Таблица: Решение | Причина | Отклонённая альтернатива

• BullMQ напрямую, без обёртки - Причина: Нативные повторные попытки с backoff достаточны, Отклонённая альтернатива: RetryQueue (лишняя абстракция)
• Функциональные сервисы - Причина: Соответствует конвенции кодовой базы, Отклонённая альтернатива: Классовая архитектура
• SendGrid для доставки - Причина: Надёжность + опыт команды, Отклонённая альтернатива: SES (дешевле, но менее надёжно), Mailgun (нет опыта)

Ограничения: только email для v1, все запросы включают tenantId (мультитенантность), использование существующего auth middleware.

Открытый вопрос: стратегия rate limiting (ожидает решения от product-команды).

На третей сессии автор поделился документом, и AI вышел на полное выравнивание за 30 секунд вместо 45 минут реконструкции предыдущих обсуждений.

Калибровка: когда применять

Context anchoring — не универсальное решение. Автор предлагает матрицу:

📊 Таблица: Сценарий | Нужен anchoring?

• Быстрый вопрос, одна утилита - Нужен anchoring?: Нет — разговор достаточно короткий
• Фича в рамках одной сессии (до часа) - Нужен anchoring?: Лёгкий — зафиксировать ключевые решения
• Фича на несколько дней - Нужен anchoring?: Да — полный feature-документ
• Фича с несколькими разработчиками - Нужен anchoring?: Да — общий документ координирует решения

Тест: могу ли я закрыть текущую сессию и начать новую без тревоги? Если нет — контекст захвачен в неправильном носителе.

Заключение

Context anchoring — это сдвиг от chat-driven development к document-driven development. Разговор остаётся средством принятия решений, но документ становится записью. Разговоры по дизайну должны быть одноразовыми (где происходит мышление), а не местом хранения выводов.

Практика дополняет предыдущие техники автора: Knowledge Priming (передача проектного контекста до сессии) и Design-First collaboration (структурирование дизайн-бесед в последовательные уровни). Вместе они формируют прогрессию: статический контекст → динамическое выравнивание → устойчивые решения.

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

📢 Информация предоставлена телеграм-каналом: Data&AI Insights

🤖 Data&AI Insights - Ваш источник инсайтов о данных и ИИ