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

Почему история диалогов важнее кода

Исходный код и Git-репозитории никуда не исчезают. Но они не содержат обоснований: почему выбрана такая архитектура, какие альтернативы отвергнуты, что тестировали на прошлой неделе и какие компромиссы приняли. Без этого контекста новый агент будет предлагать решения, которые вы уже пробовали и забраковали. В результате — потеря времени и риск сломать работающую логику. Поэтому перенос истории — не роскошь, а необходимость для продуктивной работы.

Шаг 1. Инвентаризация и подготовка данных

Прежде чем что-то переносить, соберите все источники контекста. Обычно это экспортированные диалоги из старого инструмента, комментарии в коде, заметки в таск-трекере и README. Разложите их по проектам. Если диалоги хранятся в облаке, запросите экспорт или выгрузите вручную. На этом этапе важно не потерять метаданные: даты, участников, привязку к репозиториям. Создайте структуру папок: для каждого проекта — отдельный каталог с подпапками «диалоги», «решения», «планы». Это упростит дальнейший импорт.

  • Выгрузите все доступные диалоги и обсуждения из старого инструмента.
  • Соберите комментарии из кода и задачи из трекера, если они содержат важные решения.
  • Приведите всё к единому формату (например, Markdown или JSON) для удобства обработки.

Шаг 2. Выбор инструмента для миграции

Можно пойти тремя путями: написать собственный конвертер, использовать встроенный импорт нового агента или взять специализированный инструмент. Встроенный импорт Codex часто не устраивает: он теряет связи между сообщениями, не сохраняет вложения и плохо работает с большими объёмами. Самописный конвертер даёт полный контроль, но требует времени на разработку и поддержку. Специализированные инструменты вроде Hansard предлагают готовые парсеры для популярных агентов, поиск по истории и возможность повторного использования контекста. При выборе ориентируйтесь на:

  • Поддержку форматов вашего старого инструмента (Claude Code, ChatGPT и др.).
  • Сохранение структуры диалога: кто, когда и в каком проекте писал.
  • Возможность полнотекстового поиска по всем сообщениям.
  • Экспорт в форматы, понятные новому агенту (например, в виде файлов контекста).
  • Наличие API или CLI для автоматизации.

Не гонитесь за инструментом со всеми функциями сразу. Иногда достаточно простого скрипта, если проектов немного. Но если история обширная, лучше выбрать решение с активным сообществом и документацией.

Шаг 3. Перенос и проверка контекста

После выбора инструмента запустите импорт. Не рассчитывайте, что всё пройдёт гладко: проверьте выборочно несколько проектов. Убедитесь, что диалоги не перемешаны, даты корректны, а ключевые решения легко найти. В Codex контекст можно подгружать через файлы или специальные команды. Например, создайте для каждого проекта файл context.md с кратким изложением архитектуры и ссылками на исходные диалоги. Это поможет агенту быстрее вникнуть в суть. Если инструмент миграции поддерживает теги, отметьте важные обсуждения, чтобы потом быстро к ним возвращаться.

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

Шаг 4. Адаптация к новому агенту и типичные ошибки

Codex может работать иначе, чем Claude Code: другие команды, другой стиль подсказок. Потратьте время на изучение документации и настройку профиля. Начните с одного проекта, чтобы отладить процесс, и только потом переносите остальные. Вот что часто идёт не так:

  • Игнорирование формата. Попытка скормить агенту сырые логи без структуры приводит к путанице.
  • Потеря связей. Если диалоги импортированы как отдельные сообщения без указания проекта, агент не поймёт контекст.
  • Отсутствие резервных копий. Перед миграцией сохраните исходные данные — на случай сбоя.
  • Перегрузка контекста. Не загружайте в агента всю историю сразу; используйте выборочную подгрузку по мере необходимости.

Пример из практики: при переезде один разработчик потерял обсуждение выбора фреймворка, и новый агент предложил альтернативу, которая уже была отвергнута из-за проблем с производительностью. Пришлось восстанавливать аргументы вручную. Чтобы избежать этого, составьте краткий «журнал решений» по каждому проекту и держите его в репозитории.

В итоге переезд занимает от нескольких часов до пары дней, в зависимости от объёма истории. Главное — не спешить и проверять каждый шаг. Сохранённый контекст окупится: новый агент будет предлагать решения с учётом прошлого опыта, а вы — тратить меньше времени на объяснения.