Later, Bender: как сохранить рабочий контекст проекта между чатами с нейросетями

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

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

С чего всё начиналось и почему свой велосипед оказался надежнее

Первой мыслью было не изобретать велосипед, а приспособить готовые таск-трекеры вроде Linear, Asana, Trello или Notion, у которых уже есть поддержка MCP или удобные API. Однако тащить за собой громоздкий мир корпоративного управления проектами ради нескольких элементарных операций мне не захотелось. Спринты, story points и сложные workflow-конструкторы решают совершенно другие задачи. Мне нужен был минималистичный слой состояния: записать идею, легко найти её спустя время, изменить и при этом не превращаться в секретаря при нейросети.

Первый прототип я собрал на привычном стеке: Rails, PostgreSQL, тонкий MCP-слой и минималистичный Vue-интерфейс. Выбор Ruby on Rails обусловлен не слепой ностальгией, а прагматикой. Агентам на Rails гораздо сложнее изобрести собственный изощренный фреймворк внутри репозитория. Жесткие конвенции фреймворка сужают количество степеней свободы в скучных местах, снижая вероятность того, что модель начнет плодить архитектурные излишества.

Эволюция памяти: от простого поиска к гибридному ретривалу

На старте проекта для поиска записей использовался стандартный SQL-оператор ILIKE. Этого хватало для проверки базовой гипотезы: может ли модель самостоятельно зафиксировать информацию, а затем в совершенно другом разговоре отыскать её без моих подсказок. Современным моделям не нужна постоянная нянька, если дать им понятный инструментарий и не ставить лишних диспетчеров.

По мере роста базы данных примитивный поиск по подстроке ожидаемо уперся в потолок. Люди ищут коротко, а модель формирует запросы сложно и развернуто. Тогда в архитектуре появился Elasticsearch, а следом — семантический поиск с использованием эмбеддингов, объединенный через reciprocal rank fusion. Такой подход позволил объединить лексический и векторный поиск, возвращая наружу нормальные текстовые фрагменты вместе с исходными объектами.

Задачи, заметки и артефакты

Очень быстро выяснилось, что не всё, что заслуживает сохранения, является задачей. Архитектурные решения, ограничения, гипотезы и причины отказаться от какого-то подхода плохо уживаются в одном списке с привычными тасками. Так в системе появились Notes для контекста и рассуждений, а затем Files — неизменяемые исходные артефакты вроде логов или документов. Связка «артефакт как неизменяемая база» и «заметка как вывод по нему» закрыла проблему упорядочивания информации.

Интеграция моделей и проверка интерфейса через dogfooding

Later Bender с самого момента создания задумывался как мультимодельный инструмент. Сегодня я общаюсь с ChatGPT, код пишет один агент, исследования провожу с Claude, а рутинные задачи делегирую другим провайдерам. Рабочее состояние проекта принадлежит мне и системе, а не конкретному вендору. Модели здесь выступают расходуемыми исполнителями.

Интерфейс системы проектировался с расчетом на то, что модель — такой же пользователь, как и человек. Тестирование с помощью разных моделей позволило обнаружить неочевидные баги. Например, Claude ожидал найти связь с файлом внутри задачи по одному пути, а Mistral пытался интерпретировать его иначе. Разные провайдеры отлично подсвечивают слабые места в самодокументируемости интерфейса.

Среда исполнения, секреты и Remote Agent

Одной памяти моделям оказалось недостаточно — им потребовалось место для реальной работы. Так появился Workspace, изолированная Linux-среда, где можно клонировать репозитории, собирать проекты и запускать тесты с помощью стандартных shell-команд. Для работы с приватными репозиториями и API были добавлены Credentials с надежным шифрованием на стороне бэкенда.

Позже возникла необходимость выполнять задачи прямо на моей машине с Mac, имея доступ к локальному железу и сервисам. Так родился Remote Agent, который работает на машине пользователя от его имени, сохраняя привычное окружение без попыток построить избыточный Kubernetes-кластер или изолированную песочницу.

Организация работы: ручной MoE, таски и ранбуки

В процессе использования выстроился рабочий процесс, который можно назвать «ручным MoE» (Mixture of Experts), где роль роутера выполняет разработчик. Разные модели хороши для разных ролей: одна идеальна для архитектуры и декомпозиции, другая — для рутинной ковырялки в тестах и логах.

Я строго разделил три сущности:

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

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

Вместо заключения

Later Bender неожиданно для меня самого начал активно участвовать в собственной разработке. Модели исследуют его кодовую базу через Workspace, фиксируют архитектурные решения в заметках и сохраняют результаты экспериментов в файлах. Искусственный интеллект в этой схеме выступает мощным мультипликатором усилий, но финальная ответственность за понимание системы, архитектуру и остановку бесконечного пердолинга по-прежнему остается за человеком.