Почему идеи из сессий с coding-агентом теряются
Пять мест, куда можно сложить идеи из долгой сессии с coding-агентом: прокрутка чата назад, файл заметок в репозитории (NOTES.md, CLAUDE.md или память агента), встроенный список задач агента, Jira в корпоративной среде и GitHub Issues с доской Projects. Готового победителя в этом списке нет: у каждого варианта своя цена, и автор разбора на Хабре перебрала все пять на своих проектах, не найдя способа, который закрывает всё сразу. Шестым пунктом идёт ai-tree, дерево идей сессии со статусами веток, у него отдельное ограничение.
Механика потери одинаковая. Вы заметили баг, но сейчас нет времени им заниматься. Пришла идея фичи. Сказали «надо бы ещё», агент согласился. Через сорок минут сессия уехала вверх, контекст сжался или терминал закрылся, и формулировка исчезла вместе с деталями, которые её объясняли. Такой же хвост из «потом» остаётся в работе с текстом, аналитикой и разбором чужого проекта.
Дальше текст устроен как обмен опытом, а не инструкция. Это стоит держать в голове при чтении: универсального рецепта ниже не будет, будут границы применимости каждого способа и вопросы, которые стоит задать своей ситуации.
Два вида «потом»: задачи и отчёты о брейншторме
Разделение, без которого сравнение инструментов превращается в спор о вкусах. Один вид «потом» - задача. Второй - отчёт о брейншторме. Требования к ним разные, и большая часть инструментов закрывает только первый вид.
Задача: «кнопка не работает на мобильном Safari, воспроизводится на iOS 17». Ей нужны статус, владелец и дата. Кто-то должен взять её в работу, кто-то закрыть, а срок напоминает, что она ещё висит. Ровно этим занимаются трекеры любого масштаба.
Отчёт о брейншторме выглядит иначе: «а что если переписать слой кеширования через X, потом сравнить с Y, а если не взлетит, вернуться к Z и проверить, не решается ли всё на уровне HTTP-заголовков». У такой записи нет владельца и срока, зато есть структура связей: одна ветка тянет за собой другую, часть вариантов взаимоисключающая, часть дополняет. Положить это в тикет с полем «Приоритет» можно, но смысл потеряется.
Практический вывод для всего дальнейшего: инструмент может быть удобным и при этом покрывать половину потребности. При выборе способа сначала определите, чего в вашем хвосте больше, задач или карт идей.
Способ 1: прокрутка чата назад
Вариант по умолчанию, к которому прибегают чаще всего: пролистать диалог вверх и найти ту самую реплику. Работает ровно до момента, когда контекст сжали, а терминал или чат закрыли. С coding-агентом это несколько часов максимум, то есть обычно один рабочий подход.
Сжатие контекста переписывает разговор: часть реплик исчезает, часть заменяется сводкой. Формулировка «надо будет переделать инвалидацию кеша после релиза» превращается в «обсуждали кеш», и что именно обсуждали, по остаткам уже не восстановить. Терминал закрывается ещё проще: вкладка живёт до перезагрузки или до случайного exit.
Где годится: сессия на час-два с одной задачей, где ничего не откладывается на будущее. Где не годится: длинная сессия с параллельными ветками и любая работа, к которой придётся вернуться завтра.
Способ 2: файл заметок в репозитории (NOTES.md, CLAUDE.md)
Файл в репозитории (NOTES.md, CLAUDE.md или собственная память агента) хорошо держит факты о проекте: описания флагов, с которыми собирается билд, особенности скрипта деплоя, договорённости о стиле, грабли, на которые уже наступали. Всё это меняется редко, читается перед работой и не требует статуса.
Для задач файл не годится. У строки в списке нет статуса, нет срока, и никто её не закрывает. Через пару недель NOTES.md легко превращается в список из нескольких десятков строк, где половина пунктов уже сделана, но это никак не отмечено, а какие именно - никто не помнит. Дальше файл перестают читать: он остаётся архивом, но перестаёт быть источником правды.
С CLAUDE.md своя тонкость. Файл служит памятью агента: туда пишут инструкции, как собирать проект, какие команды запускать, чего не делать. Бэклог в этом файле смешивается с правилами и начинает влиять на поведение агента: он читает старые «надо бы» как руководство к действию и тащит их в текущую задачу. Разделять эти роли стоит с самого начала, пока файл короткий.
Способ 3: встроенный список задач coding-агента
У Claude Code такой список есть. Включается переменной окружения CLAUDE_CODE_ENABLE_TODO_TOOLS=1, задачи лежат в ~/.claude/tasks/<session>/ по одному JSON на задачу, и новая сессия видит старый список. Настраивать нечего, синхронизировать нечего, список находится рядом с работой и заполняется по ходу дела.
Минус один и он весомый: список живёт внутри агента. Свои планы вы не ищете внутри агента, а заглянуть туда со стороны не может никто: ни коллега, ни второй агент, ни система трекинга. Для соло-работы в одной сессии этого хватает. Для команды и для бэклога на месяц - нет. Добавьте сюда зависимость состава пунктов от того, как агент понял задачу: список отражает его трактовку разговора, а не вашу.
Как выглядят агентные сессии в более сложной схеме, с оркестратором задач, worktree и внешним дашбордом, разобрано в отдельном материале про пет-проект на Java и Claude Code.
Способ 4: Jira в корпоративной среде
В компании вопрос обычно уже решён. Процесс описан, поля согласованы, и агенту достаточно доступа к правилам ведения тикетов или нескольких примеров, чтобы скопировать формат. После этого он заводит тикеты, которые выглядят как у всех: с типом, приоритетом, компонентом и исполнителем.
Условия, без которых схема не работает: Jira действительно есть, процесс живой, поля заполняются не через силу. В соло-проекте или в команде из трёх человек без процесса Jira добавляет слой работы, который никто не поддерживает, и через месяц там появляются три тикета и тишина.
Jira закрывает вид «задачи»: статус, владелец, дата. Отчёт о брейншторме в неё не помещается. В описании тикета можно сохранить ветку рассуждений, но связей между идеями система не покажет, а следующая итерация обсуждения начнётся с чистого листа. Как выглядит назначение задачи виртуальному исполнителю на практике, включая подготовку доступов и узкое место в ревью, разобрано в кейсе про AI-агентов в Jira.
Способ 5: GitHub Issues и доска Projects
Issues хранят задачи, Projects даёт доску со статусами. Плюс в том, что всё лежит рядом с кодом, а агент может заводить issues через CLI или API, не переключаясь в браузер. Для личного проекта этого достаточно, чтобы задачи не терялись в переписке.
Дальше начинается часть, ради которой стоит читать этот раздел: доска сама себя не поддерживает.
Как доска превращается в свалку за шесть недель
Автор разбора наблюдала это на своём GitHub-проекте: без регулярной рутины доска за шесть недель обросла просроченными и нетронутыми карточками. Описание опыта опубликовано на Хабре.
Механика простая и воспроизводимая. Карточки создаются быстрее, чем закрываются. Статусы не обновляются: в колонке «в работе» висит то, что перестало быть в работе две недели назад. Новые идеи падают поверх старых, приоритеты выставляются один раз и больше не пересматриваются. Через полтора месяца доска не отвечает на главный вопрос «что сейчас реально делается», а значит, перестаёт быть источником правды.
Инструмент тут не виноват. Тот же эффект даёт любой трекер без ритуала: Kanban-доска в Jira, Notion, таблица в Google Sheets. Разница только в скорости зарастания.
Правило: агенту нужна ежедневная задача по наведению порядка
Из этого опыта следует правило: агенту нужна ежедневная задача по наведению порядка на доске. Пройтись по карточкам, обновить статусы, закрыть сделанное, поднять зависшее, снять ярлык с того, что потеряло актуальность.
Это рутина, а не разовое действие. Задача, поставленная один раз, даёт ровно один проход: через неделю доска снова зарастает, потому что создание карточки занимает секунды, а её закрытие требует решения. Ежедневный проход переносит это решение в момент, когда контекст ещё свежий.
Частота зависит от контекста. В соло-проекте хватает еженедельного прохода. В команде с несколькими людьми и агентами, которые заводят карточки параллельно, нужен ежедневный. Без ритуала любая доска деградирует одинаково, отличается только скорость.
ai-tree: дерево идей сессии и его ограничение
ai-tree - дерево идей на каждую сессию, которое рисуется на локальной странице. У каждой ветки есть статус: не тронута, в работе, сделана. По типу это ближе к отчётам о брейншторме, чем к задачам: важна структура связей, а статус отдельного узла служит подсказкой, где вы остановились.
Ограничение вылезло на практике. Попросив агента держать дерево в актуальном состоянии через CLAUDE.md, автор обнаружила, что в длинных сессиях агент об этом забывал. Версия, которая более-менее работает, читает лог сессии наблюдателем снаружи агента. Детали проверки и выводы автор приводит в том же разборе.
Вывод жёсткий: просить агента «помни сам» в длинной сессии бесполезно. Инструкция в файле памяти конкурирует с текущей задачей за внимание модели, и при длинном контексте задача выигрывает почти всегда.
Внешний наблюдатель надёжнее по одной причине: лог сессии пишется независимо от того, помнит агент о своей обязанности или нет. Наблюдатель читает факты, а не обещания.
Как выбрать способ под свою ситуацию
Сравнение в одной таблице. Колонка «где ломается» важнее колонки «что закрывает»: именно она определяет, сколько ручной работы вы получите через месяц.
| Способ | Что закрывает | Где ломается |
|---|---|---|
| Прокрутка чата назад | Найти реплику в текущей сессии | Контекст сжали или чат закрыли |
| NOTES.md / CLAUDE.md | Факты о проекте, команды сборки, договорённости | У задачи нет статуса, срока и владельца |
| Встроенный список задач | Задачи внутри одной сессии | Живёт внутри агента, снаружи недоступен |
| Jira | Задачи в компании с описанным процессом | Нет процесса или самой Jira; брейншторм не помещается |
| GitHub Issues + Projects | Задачи рядом с кодом, доска со статусами | Доска без регулярной рутины деградирует |
| ai-tree | Карта идей сессии со статусами веток | Агент забывает обновлять, нужен внешний наблюдатель |
Ориентиры по ситуациям. Короткая соло-сессия с одной задачей: хватит прокрутки, заводить систему под неё бессмысленно. Нужно помнить факты о проекте: NOTES.md или CLAUDE.md, но без бэклога внутри. Соло с длинными сессиями: встроенный список задач плюс внешний наблюдатель за логом. Команда в корпоративной среде: Jira, если процесс живой, иначе она станет ещё одной свалкой. GitHub-проект: Issues и Projects с ежедневной или еженедельной рутиной.
Комбинация - нормальный вариант, а не признак бардака. Факты о проекте в файле, задачи в трекере, карта идей в отдельном инструменте: это три разные потребности, и одна система редко закрывает их хорошо. Отдельный вопрос, насколько точно сформулирована сама задача агенту: если границы размыты, любое хранилище наполнится пунктами, которые потом нечем закрыть. Об этом есть кейс про список того, чего в системе не будет, и постановку задачи для ИИ-агента.
Идеального способа автор разбора не нашла, и это честный итог, а не фигура речи. Чем пользуетесь вы? Если у вас есть рабочая схема, которая держится дольше двух месяцев, расскажите о ней в комментариях: сравнение из пяти пунктов станет полезнее.