Постановка проблемы
Заголовок статьи — игра на русской пунктуационной загадке «казнить нельзя помиловать»: «Контекст: сбрасывать нельзя компактизировать». В зависимости от того, где поставить запятую, смысл меняется на противоположный. Именно эта двусмысленность и составляет суть проблемы: у практиков нет единого консенсуса, когда стоит очищать контекстное окно, а когда — сжимать его содержимое средствами самой модели.
Автор вводит понятие «гигиены контекста» как системного подхода к тому, что именно попадает в окно модели, в каком формате, и как это влияет на качество генерации и расход токенов. Тема особенно актуальна для разработчиков, которые используют AI-ассистентов в длинных сессиях — будь то Claude Code, Cursor или собственные интеграции через API.
Практики работы с промптами
Первый блок статьи посвящён формату инструкций. Раздел «Держи команды машиночитаемыми» указывает на проблему, хорошо знакомую по production-опыту: модель лучше следует структурированным, однозначным командам, чем размытым инструкциям в свободной форме. Машиночитаемость здесь — не про JSON как таковой, а про предсказуемость и отсутствие двусмысленности.
«Краткость — сестра таланта» и «Одна задача — один done-критерий» — два связанных принципа. Первый отвечает за объём промпта: чем меньше шума в контексте, тем ниже вероятность drift'а (смещения модели от исходной задачи). Второй вводит понятие чёткого критерия завершённости для каждого запроса — без него модель не знает, когда остановиться, что ведёт к избыточным итерациям и раздуванию контекста.
Архитектура контекста
Три раздела образуют архитектурный блок: «Кто мы, откуда, куда мы идём», «Разделяй и властвуй» и «С глаз долой, из сердца вон». Первый, судя по названию, касается системного промпта и «памяти» о проекте — как модели объяснить контекст задачи без перегрузки окна. Второй — про декомпозицию длинных задач на изолированные подзадачи с собственными контекстами. Третий — про механизмы вывода отработанной информации из окна: архивирование, суммаризацию или явный сброс.
Раздел «Мастер на все руки» предположительно рассматривает вопрос специализации: стоит ли держать один большой универсальный контекст или запускать несколько узкоспециализированных агентов с меньшим окном. Это перекликается с архитектурными решениями в мультиагентных системах, где каждый агент отвечает за строго ограниченный домен.
Методология и результаты
«Просто делай — просто будет» и «Eval-Driven Development» — финальный методологический блок. Eval-Driven Development (EDD) — подход, при котором качество работы с LLM измеряется через систему автоматических оценок (evals): тесты, бенчмарки, проверки выходных данных. EDD позволяет объективно сравнивать стратегии управления контекстом, а не полагаться на субъективное ощущение «модель стала лучше/хуже».
Статья завершается разделами «Реальные примеры» и «Ограничения и открытые вопросы» — стандартная структура инженерного разбора: от теории к практике и честному признанию границ предложенного подхода. По заявлению автора, материал основан на опыте iOS-разработки в Doubletapp, что придаёт примерам прикладную специфику мобильного стека.
