Воспроизводимые сессии программирования с ИИ без опоры на историю чата

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

Журнал чата показывает разговор. Чаще всего он не отражает полной среды, которая привела к ответу.

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

Команды часто предполагают, что можно просто открыть ту же ветку и получить тот же результат. На практике вывод меняется, потому что контекст изменился. Ветка сдвинулась, файл поменялся, модель обновилась или инженер случайно включил какую‑то настройку.

Простой журнал чата также скрывает детали, которые важнее, чем думают люди:

• точный текст подсказки, включая мелкие правки
• версия модели или инструмента, использованная в тот день
• файлы, ветка и состояние локального репозитория
• команда теста и данные, использованные для проверки изменения

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

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

Новички обычно сталкиваются с этим первыми. Они приходят в команду, открывают старую ветку и пытаются воспроизвести работу. Неясно, какая подсказка имела значение, какая версия дала результат и какой тест подтвердил изменение. Вместо того чтобы опираться на прошлую работу, они тратят часы на угадывания.

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

Что должно быть в записи сессии

Полезная запись сессии позволяет другому инженеру повторить работу без догадок. Если кому‑то всё ещё нужна ваша память, приватная история терминала или полусвернутое окно чата — запись не закончена.

Начните с одного простого предложения о задаче. Держите его узким и конкретным, например: «Исправить тайм‑аут API при поиске пользователей при холодном кэше» или «Добавить повторную попытку доставки неуспешных webhook». Запись типа «работал над бэкенд‑проблемами» через неделю почти бесполезна.

Затем сохраните точную подсказку или инструкцию, которая привела к результату. Не переписывайте её задним числом. Вставьте слова так, как они были отправлены: мелкие правки часто меняют вывод. Если сессия зависела от нескольких подсказок, запишите их в порядке использования.

Далее запишите модель, инструмент и версию. «Claude Code» слишком обобщённо. «OpenAI API» тоже слишком широко. Команде нужны имя модели, версия CLI, версия расширения и любые дополнительные слои, которые меняли поведение. Если вы использовали кастомные хуки, MCP‑сервер или локальный скрипт вокруг модели, укажите это.

Это особенно важно в смешанных средах. Oleg Sotnikov часто работает с окружениями программирования с ИИ, которые комбинируют Claude, GPT и кастомные инструменты — и именно в таких случаях отсутствие заметок о версиях ломает возможность повторного запуска.

Полная запись также должна содержать след выполнения:

• какие файлы изменились
• какие команды запускались
• какие тесты проверяли результат
• что считалось успехом

Последний пункт часто пропускают. «Тесты прошли» — это мало. «Юнит‑тесты прошли, локально проверён логин‑флоу, время ответа не превысило 300 ms» даёт следующему инженеру реальную проверку.

Думайте о записи как о карточке рецепта. Задача говорит, что вы готовите. Подсказка показывает, как модель направлялась. Инструмент и версия показывают вашу среду. Файлы, команды и результат теста показывают, действительно ли всё работало.

Используйте один простой шаблон

Команды теряют повторяемость, когда каждый записывает заметки по‑своему. Один инженер сохраняет скриншот, другой вставляет половину подсказки, третий вспоминает пропущенный шаг через неделю. Простой шаблон решает эту проблему. Ему не нужно быть красивым. Он должен оставаться одинаковым каждый раз.

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

Запись сессии, которую люди действительно будут использовать

Используйте одни и те же поля для каждого запуска:

• Цель: одно предложение о том, что инженер хотел изменить
• Подсказка: точный текст, отправленный в ИИ, вставлен полностью
• Контекст: файлы, имя ветки, пример входных данных и любые ограничения, которые нужно было учесть
• Результат: что изменилось, что всё ещё было не так и что инженер редактировал вручную
• Запись тестов: какие команды запускались, что проверялось и пройдено/не пройдено

Этой структуры достаточно для большинства команд. Она даёт следующему человеку реальную отправную точку, а не дело для детектива.

Храните подсказки в виде, удобном для копирования и вставки, даже если они выглядят неряшливо. Не сжимайте их в аккуратное предложение позднее. Мелкие детали часто меняют результат: путь к файлу, ограничение вроде «не переименовывать функции» или строка, которая просит модель объяснить план перед правкой.

Оставьте место для заметок простым языком. Люди корректируют подсказки, отклоняют плохие предложения и правят части вывода вручную. Эти изменения имеют значение. Если запись хранит только чистую версию, полезная часть исчезает.

Неудачные попытки должны быть в той же заметке. Плохая подсказка, которая переписала не тот модуль, тест, который прошёл локально, но упал при других данных, или настройка, из‑за которой модель игнорировала инструкции, — всё это может сэкономить команде час в следующий раз. Держите такие заметки короткими, но сохраняйте их.

Простой текстовый блок работает хорошо, потому что любой может скопировать, вставить и запустить:

Goal:
Prompt:
Context:
Manual edits:
Tests run:
Result:
Failed attempts:
Notes for next run:

Не гонитесь за идеальным форматом. Markdown‑файл в репозитории, общий документ или комментарий в задаче подойдут, если поля остаются фиксированными. Последовательность важнее элегантности.

Фиксируйте работу по порядку

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

Затем сохраните первую подсказку именно так, как вы её отправили. Не чистите её потом. Первоначальная версия важна, потому что показывает реальную отправную точку — часто именно её другой инженер не может воспроизвести по коду в конце.

Простая последовательность работает лучше всего:

1. задача и критерий успеха
2. первая подсказка, скопированная как отправлена
3. каждое изменение подсказки в порядке появления
4. любые ручные правки кода вне ИИ‑инструмента
5. запущенные тесты в точном порядке

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

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

Порядок тестов важнее, чем многие ожидают. Успешный прогон полного набора не заменяет реальную последовательность. Если вы запускали один unit‑тест, затем линт, затем локальную сборку — запишите именно этот порядок и команды. Один пропущенный шаг может превратить повторный запуск в угадайку.

Здесь команды обычно ошибаются: сохраняют финальную подсказку и финальный код, но не путь между ними. Пропущенная часть часто и есть то, что сделало сессию рабочей.

Фиксируйте версии и контекст тестов

Два инженера могут использовать одну и ту же подсказку и получить разные результаты, если их инструменты отличаются. Чтобы сделать сессию воспроизводимой, запись нужна не только с разговором, но и с точной средой, которая формировала вывод.

Начните с самой модели. Сохраните имя модели, релиз или билд‑версию и способ доступа. «Claude Code с моделью X» и «веб‑чат» — это разные настройки, даже если семья модели звучит похоже.

Запишите все помощники вокруг модели. Это включает CLI‑утилиты, coding agents, расширения редактора, MCP‑серверы и любые скрипты, которые инжектировали подсказки или контекст. Небольшие изменения версий могут изменить, какие файлы агент читает, какие команды он выполняет и насколько агрессивно правит код.

Машина имеет такое же значение. Укажите runtime, менеджер пакетов и версии ОС, использованные в сессии. Запись вроде "Node 20.11, pnpm 9, macOS 14.5" часто объясняет, почему у одного инженера сборка прошла, а у другого возникли проблемы с зависимостями или шеллом.

Контекст тестов требует той же аккуратности. Если инженер использовал sample data, фикстуры, засеянную базу или копию production‑снимка, назовите это явно. «Customer export from March» и «clean fixture with 10 demo accounts» могут вызывать очень разные баги и подсказки от ИИ.

Короткая запись должна включать:

• имя и версию модели
• версии агента, CLI и расширений
• версии runtime, пакетов, контейнеров и ОС
• используемые фикстуры или образцы данных
• точный объём тестирования и команды, которые запускались

Последний пункт часто пропускают. «Тесты прошли» почти неинформативно. Напишите, запускался ли полный набор или только часть, и укажите команду. «Запущены только billing unit tests» — это совсем другое, чем «запущены backend, frontend и integration‑тесты».

Это занимает минуту, но экономит часы позже. Когда коллега попытается повторить работу через неделю, он сможет воссоздать окружение, а не гадать по журналу чата.

Пример для небольшой команды

Трёхчленная продуктовая команда столкнулась с багом входа во вторник днём. Один разработчик, Mia, попросила инструмент ИИ исправить тайм‑аут сессии, который проявлялся только после того, как пользователь сбрасывал пароль и заново входил.

ИИ предложил небольшой патч в auth‑флоу, изменение конфигурации для библиотеки сессий и один дополнительный тест. Mia попробовала, баг исчез, и она продолжила работу. Если бы команда остановилась на этом, её запись в чате была бы единственной памятью о пути к исправлению.

Она поступила лучше. Mia сохранила использованную подсказку, хеш коммита, версии пакетов в lockfile, точную тестовую учётную запись и случайное seed‑значение, которое использовала её локальная тестовая среда. Она также записала шаги, подтверждающие исправление: сбросить пароль, войти в Chrome, подождать 15 минут, обновить страницу и открыть настройки аккаунта.

На следующее утро другой инженер, Sam, повторил ту же сессию. Он использовал ту же подсказку и ту же ветку репозитория, но исправление не сработало. Сначала логин проходил, а при обновлении пользователь снова выкидывался.

Проблема была не в подсказке. За ночь обновился пакет, и библиотека сессий сменила минорную версию — новая версия иначе обрабатывала настройки cookie. Благодаря тому что Mia задокументировала старую версию и seed теста, Sam откатил пакет, повторил шаги и получил тот же результат, что и она.

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

После этого случая они обновили шаблон. Теперь каждая запись сессии включала подсказку и последующие подсказки, имя и версию инструмента, хеш lockfile или снимок пакетов, seed и учётную запись теста и точные шаги, подтверждающие результат.

Mia потратила около двух дополнительных минут на запись. Это сэкономило Sam гораздо больше.

Что ломает повторяемость

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

Та же проблема возникает, когда команды пишут «used Claude Code» или «ran GPT» и на этом останавливаются. Выбор модели, версия CLI, установленные расширения и даже изменённый системный промпт могут сдвинуть вывод настолько, что повторный запуск не совпадёт. «Тот же инструмент» часто не значит «та же настройка».

Слабые записи также пропускают скучные детали — и именно они обычно имеют значение. Распространённые пробелы включают:

• ручные правки после ответа ИИ
• точные команды тестов вместо «тесты прошли»
• sample data, переменные окружения, фикстуры или локальные шаги настройки
• имя ветки, хеш коммита и изменённые файлы

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

Тесты создают ту же кашу. «Прошло локально» никому не говорит, какую команду запускали, фильтровали ли тесты или был ли запущен внешний сервис. Полезная запись выглядит как pytest tests/api/test_auth.py -k refresh_token или npm test -- login form, а не расплывчатая строчка успеха.

Sample data важна не меньше. Если подсказка предполагала скопированный payload, засеянную базу или локальный .env, то этот набор — часть рецепта. Уберите его — и следующий человек будет час гоняться за багом, который на самом деле просто лишён контекста.

Когда это ломается, команда не теряет код. Она теряет путь, который привёл к коду. Именно этот путь позволяет другому повторить работу.

Быстрая проверка повторного запуска

Повторный запуск должен занимать минуты, а не расследование. Если другому инженеру нужно листать журналы чата, угадывать модель или спрашивать, что вы нажимали — запись не готова.

Выполните эту проверку перед закрытием задачи:

• Сформулируйте цель в одно‑две строки. Назовите файл, баг, фичу или тест‑результат и укажите, что считалось «готово».
• Сохраните точный текст подсказки. Если подсказка менялась, храните каждую версию в порядке и укажите, зачем вы меняли.
• Уточните настройку инструмента. Запишите имя модели, CLI или редактор, номера версий, активные хуки, MCP‑серверы и всё, что влияло на вывод.
• Запустите тесты в том же порядке. Зафиксируйте шаги настройки, команды, тестовые данные, seed‑состояние и момент, где вы проверяли результат.
• Запишите каждое ручное действие. Укажите переключения веток, скопированные файлы, изменения env, подтверждения и любые шаги вне подсказки.

Мелочи важнее, чем многие думают. Если один инженер использовал Claude Code с кастомным хуком и засеянной базой, а другой — новую модель и свежие данные, они не воспроизводят одну и ту же сессию. Это два разных эксперимента.

Если хотя бы на один пункт чек‑листа ответ «нет», исправьте заметки до мержа, передачи или продолжения работы. Такая привычка экономит время и не даёт одной истории чата стать единственной картой.

Следующие шаги для небольшой команды

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

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

Выберите задачу, которая важна, но не парализует команду, если первое применение шаблона получится корявым. Фикс бага, небольшой рефактор или правка внутреннего инструмента подойдут. Избегайте большой фичи — люди начнут винить шаблон, если сама задача слишком хаотична.

Короткий rollout обычно достаточен. Попробуйте шаблон на одной реальной задаче на этой неделе. Просмотрите две сохранённые сессии вместе. Уберите поля, которые никто не заполняет через две недели. Назначьте одного человека ответственным за порядок, чтобы шаблон не разрастался.

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

Через неделю‑две откройте две реальные записи сессий вместе. Задайте простые вопросы. Сможет ли кто‑то другой повторить это без запроса пропавшей подсказки? Говорят ли шаги теста, что запускать и какой результат ожидать? Показана ли в записи модель, редактор или версия CLI?

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

Если ваша команда уже ежедневно использует ИИ, но работа всё ещё зависит от памяти одного инженера, внешний эксперт может ускорить процесс. Oleg Sotnikov, через oleg.is, работает со стартапами и малыми командами в роли Fractional CTO и помогает настраивать бережные рабочие процессы программирования с ИИ.

Держите стандарт простым, чтобы его можно было выполнить в загруженную неделю. Если сохранённая сессия позволяет другому инженеру повторить работу за 15 минут — она работает.