Меня зацепила статья «Жизнь после Claude Code: как я переехал на Codex и сохранил историю проектов». Автор предлагает архивировать переписку с ИИ-ассистентом, чтобы не потерять контекст при смене инструмента. Идея кажется логичной: чат — это же история работы. Но на практике архив переписки хранит разговор о проекте, а не итоговые решения. В результате через месяц вы не найдёте, почему выбрали именно эту архитектуру, а не альтернативу. Я предлагаю другой подход: контекст должен жить в репозитории, рядом с кодом.

Почему архив чата не работает

Переписка с ИИ — это поток сознания. В ней есть удачные формулировки, тупиковые ветки, повторные объяснения и случайные мысли. Когда вы возвращаетесь к такому архиву, вы тратите время на реконструкцию: что было решено, что отвергнуто и почему. Более того, чат привязан к инструменту. Перешли с Claude Code на Codex — и старый архив остаётся в другом интерфейсе, часто без возможности быстро найти нужный фрагмент.

Я полгода экспериментировал с хранением контекста в репозитории. Сначала вручную, потом довёл методику GRACE до утилиты doubled-graph. Суть проста: все значимые решения, договорённости и артефакты проекта фиксируются в структурированных файлах внутри репозитория. Чат остаётся вспомогательным инструментом, но не источником истины.

Что именно хранить в репозитории

Контекст — это не весь диалог, а выжимка. В репозитории должны появиться несколько типов документов. Во-первых, файл с описанием архитектуры и ключевых решений (ADR — Architecture Decision Records, но можно и просто markdown-файл). Во-первых, журнал изменений контекста: что поменялось, когда и почему. В-третьих, глоссарий терминов и сокращений, если проект сложный. В-четвёртых, примеры использования и тестовые сценарии, которые ИИ может брать как образец.

Важно, чтобы эти файлы были краткими и обновлялись по мере необходимости. Не нужно копировать туда каждую реплику. Достаточно фиксировать итог: «Выбрали PostgreSQL, потому что нужна поддержка JSONB и транзакций. Отказались от MongoDB из-за сложности с миграциями». Такая запись занимает две строки, но экономит часы обсуждений в будущем.

Как организовать процесс

Начните с малого. Создайте в корне репозитория папку context (или docs/context). Внутри — файл decisions.md для архитектурных решений и glossary.md для терминов. Договоритесь с командой (или с собой), что любое значимое обсуждение с ИИ заканчивается короткой записью в этих файлах. Не обязательно делать это вручную: можно попросить ассистента сформулировать итог и вставить его в файл.

Утилита doubled-graph, которую я использую, автоматизирует часть работы. Она анализирует историю чата и предлагает сжатые формулировки для добавления в контекст. Но даже без утилиты подход работает: главное — привычка фиксировать результат, а не процесс. Через две недели вы заметите, что новые задачи решаются быстрее, потому что ИИ получает на вход актуальный контекст из репозитория, а не пытается угадать его по обрывкам переписки.

Типичные ошибки и как их избежать

  • Хранить всё подряд. Контекст — это не лог. Если вы копируете в репозиторий каждое сообщение, файлы разрастаются и становятся бесполезными. Ограничьтесь решениями и их обоснованиями.
  • Забывать обновлять. Контекст устаревает быстрее кода. При каждом значимом изменении (новый сервис, смена библиотеки, пересмотр архитектуры) добавляйте запись. Иначе ИИ будет опираться на устаревшие данные.
  • Игнорировать структуру. Если файлы контекста лежат вперемешку с кодом без оглавления, их никто не найдёт. Используйте понятные имена и поддерживайте индекс (например, context/README.md со ссылками).
  • Полагаться только на ИИ. Контекст в репозитории — это ваш актив. Проверяйте, что записанные решения действительно отражают текущее состояние проекта, а не являются галлюцинацией ассистента.

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

Пример из практики

В одном из проектов мы долго выбирали между двумя подходами к кешированию. В чате с ИИ было около двадцати сообщений с аргументами за и против. Когда через месяц возникла похожая задача, я не стал перечитывать переписку — открыл decisions.md и увидел запись: «Выбрали Redis с TTL 5 минут, потому что данные редко меняются, а нагрузка на БД высокая. Отказались от in-memory кеша из-за ограничений по памяти на инстансе». Этого хватило, чтобы принять решение по новой задаче за пять минут.

Кроме того, я заметил, что ИИ-ассистент, получая на вход актуальный контекст из репозитория, реже предлагает нерелевантные варианты. Он видит ограничения и предыдущий опыт, а не начинает с нуля.

С чего начать сегодня

Не пытайтесь сразу перестроить весь процесс. Сделайте три шага. Первый: создайте в репозитории папку context и файл decisions.md с двумя-тремя последними важными решениями. Второй: добавьте в README.md ссылку на этот файл, чтобы он не потерялся. Третий: в следующем обсуждении с ИИ, прежде чем закрыть чат, попросите его сформулировать итог и вставьте в decisions.md. Через неделю вы почувствуете разницу.

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