С приходом ИИ‑агентов в разработку, кода стало больше, а вместе с ним и шума. Пулреквесты растут, держать агента в рамках задачи становится сложнее, а через голову человека проходит всё больше кода. Ревью превращается в основную нагрузку и зелёные цифры добавленных строк в заголовке начинают напрягать ещё до того, как его откроешь.
Типичная картина: пулреквест на небольшую фичу, а в нём правки в десятке файлов, которые к задаче не относятся. По отдельности они могут быть полезными, но вместе они превращают пулреквест в солянку.
Проблема: агент видит больше, чем успевает сделать
Когда ИИ‑агент работает над задачей, он постоянно натыкается на побочные вещи. Устаревшая зависимость, дублирующийся код, непокрытая тестами функция, странное имя переменной в соседнем модуле. Всё это реальные замечания, но к текущей задаче они не относятся.
Дальше агент делает одно из двух. Либо отвлекается и начинает чинить всё подряд: diff раздувается, ревью превращается в мучение, а контекстное окно тратится не на то. Либо упоминает находку в одном сообщении из сотни, и она теряется навсегда.
Отдельная боль — контекстное окно. Если агент работает в водопадном режиме и делает всё подряд в одной сессии, контекст забивается побочными правками. Чем он полнее, тем хуже агент помнит, зачем он вообще сюда пришёл: забывает ранние договорённости, путается в уже сделанном, а после сжатия контекста теряет детали. Иногда сессия просто упирается в лимит посреди работы.
При этом модели разные. У одних окно больше, у других меньше, и задача, которую одна модель проходит за сессию, у другой уже не поместится. При этом токены ограничены у всех: каждый попутный рефакторинг съедает бюджет, который должен был уйти на основную задачу.
Идея: беклог, который ведёт сам агент
После эйфории первых месяцев работы с агентами, когда все кажется магией, в какой‑то момент приходит понимание, что всю систему написания кода можно выстроить ещё лучше. Сначала просишь агента не делать лишнего. Потом ищешь готовые велосипеды. Затем пишешь свой скилл, который даёт агенту указания с учётом специфики твоей области и в итоге появляется решение, которым хочется поделиться с командой.
Так появилась идея локального беклога для разработки — полноценного, с жизненным циклом задач и проверками. Он нужен, чтобы в моменте не отвлекаться ни агенту, ни человеку. При работе с задачей всё постороннее уходит в беклог:
замечания и идеи, найденные по ходу работы;
попутные рефакторинги, которые просятся в отдельную ветку;
побочные эффекты изменений, которые нужно проверить отдельно;
технический долг, который иначе остался бы TODO‑комментарием в коде;
вопросы к человеку, на которые агент не может ответить сам.
Принцип простой: раз уж автоматизируем, то автоматизируем всё. Беклог — прежде всего инструмент агента. Он сам записывает задачи, сам берёт их в работу и сам закрывает со ссылкой на коммит. А Stop‑хук после каждого хода агента проверяет, не изменился ли код открытых задач, и просит их перепроверить. Человеку не нужно вести беклог вручную.
При этом у человека остаётся окно, чтобы подсмотреть за работой: насколько эффективен агент, что уже готово и что ещё осталось. Контроль без микроменеджмента.
От идеи к реализации
Чтобы идея заработала, нужно было ответить на три вопроса: где хранить задачи, как агенту с ними работать и как человеку за этим следить. Из ответов получились четыре части:
Компонент | Что делает |
|---|---|
Ядро | Хранит задачи и эпики, логика работы с беклогом |
CLI | Добавить, посмотреть, взять в работу, закрыть задачу из терминала |
Скилл для агента | Объясняет агенту, когда и как записывать замечания и как брать задачи из беклога |
Stop‑хук | После каждого хода агента проверяет, изменился ли код открытых задач, и просит их перепроверить |
Сервер и веб‑приложение | Удобно просматривать и разбирать беклог в браузере |
Главным интерфейсом стал CLI: агенту проще всего вызвать команду в терминале, без токенов, API и сети. Но одного CLI мало — агент должен понимать, когда им пользоваться. Эту роль взял на себя скилл: он превращает «у агента есть CLI» в «агент сам записывает задачи в нужный момент и сам их берёт».
Веб‑часть закрывает вторую половину идеи — окно для человека. В браузере видно, что готово, что осталось и насколько эффективно работает агент, а читать сотню задач в терминале не приходится.
Задачи — обычные markdown‑файлы в ~/backlog, по папке на проект: без аккаунта и облака. CLI написан на TypeScript, ставится из npm и работает с Claude Code, Codex и Cursor.
Два способа работы
Через агента и CLI. Достаточно попросить агента «запиши в беклог…» или «возьми следующую задачу», и скилл сам вызовет нужные команды. Можно и вручную:
backlog list,backlog take --next,backlog close. Удобно, если вы живёте в терминале.Через веб‑интерфейс. Список задач с фильтрами, карточки, статистика и массовые действия: выделить несколько задач и закрыть их, сменить приоритет или перенести в эпик. Изменения, которые делает агент, появляются в открытой вкладке сразу, без перезагрузки.
Оба способа работают с одними и теми же файлами, так что их легко смешивать.
Как это выглядит в работе
Представим, что агент добавляет новый эндпоинт в API. По ходу он замечает две вещи: в соседнем обработчике нет валидации входных данных, а в модуле авторизации дублируется код.
Что будет с этими находками дальше, обычно зависит от настроек и харнесса. С p‑backlog сценарий всегда один: агент записывает обе находки в беклог и возвращается к эндпоинту.
backlog new --title "Обработчик /orders не валидирует входные данные" \ --category bug --priority high --source src/api/orders.ts:42 \ <<<'Пустой payload доходит до базы' backlog new --title "Модуль авторизации дублирует проверку токена" \ --category dispensables --source src/auth/session.ts:118 \ <<<'Та же проверка уже есть в middleware'
Итог сессии: чистый diff только по эндпоинту и две новые задачи в беклоге. У каждой есть источник файл:строка, описание риска и категория. Если похожая задача уже открыта, CLI не даст создать дубль.
Позже можно открыть веб‑интерфейс, выбрать задачу про валидацию и отдать её агенту отдельной сессией — он возьмёт её командой backlog take. А если код вокруг задачи за это время изменится, Stop‑хук попросит агента перепроверить её и закрыть, если проблема уже исправлена.
Так выглядит задача, которую записал агент: источник в коде, описание, чек‑лист и связи с другими задачами
На дистанции результат видно в статистике. Вкладка «Эффект» показывает по неделям, сколько строк ушло в беклог, а не в пулреквесты, и какая доля посторонних правок не попала на ревью.
Во что обходится сам беклог, показывает вкладка «Стоимость». По расшифровкам Claude Code она считает токены на ходы, запущенные Stop‑хуком, и на вывод CLI и скилла, а затем переводит их в деньги по ценам Claude API. Там же расход по моделям и по неделям, время работы команд и память сервера.
Токены хука считаются точно, а вывод CLI и скилла — оценкой по длине текста. На подписке реальная стоимость может отличаться, а расходы Codex и Cursor пока не учитываются.
Почему не TODO.md?
Казалось бы, TODO.md в корне репозитория — самый простой вариант. Но у такого файла нет структуры: из него нельзя нормально взять задачу в работу, закрыть её и затем сгруппировать в эпик (можно, но дорого). Когда в файле пять строк, это работает. Когда пятьдесят, то это превращается в свалку.
А почему не GitHub Issues, Jira, Linear??
Да, это полноценные трекеры, но они сделаны для людей. Агенту нужны токены, доступ к API, сеть. Каждое замечание превращается в тяжёлую операцию, и вдобавок трекер команды забивается мелочами, которые нашёл агент.
Решение: p‑backlog
Он сочетает в себе сильные стороны обычной тудушки (локальный и лёгкий) и возможности больших трекеров (у задач есть структура и жизненный цикл).
И главное — он изначально спроектирован под то, что основной пользователь — агент.
Что ещё видно через беклог
Беклог задумывался как способ держать пулреквесты чистыми. Но когда все находки лежат в одном месте и ссылаются на код, из них складывается картина всего проекта.
Проблемные места в коде. Вкладка «Код» ранжирует папки по открытому долгу с учётом того, как часто их меняют, и считает плотность долга на 1000 строк. Сразу видно, где болит сильнее всего и с чего начинать рефакторинг.
Блокеры. Задачи связываются через блокеры, и
backlog takeне даст взять заблокированную задачу без--force. В списке можно оставить только задачи без блокеров — то, что можно брать прямо сейчас.Зависшие задачи. Тревоги в статистике подсвечивают задачи, которые давно не двигаются, и срочные задачи, до которых никто не дошёл.
Рост долга. Если несколько недель подряд задач создаётся больше, чем закрывается, статистика предупредит.
Дубли. Если похожая задача уже открыта, беклог не даст завести её повторно, и одна проблема не расползается на несколько записей.
Шум в проверках. Вкладка «Качество» показывает, насколько точны перепроверки, а тревога сработает, если какой‑то метод проверки часто ошибается.
Вкладка «Код»: где в кодовой базе копится долг — уже сейчас видно, с каких частей начинать
Для тех, кто любит гонять аудиты
Отдельный сценарий — аудиты (безопасность, производительность, архитектура, code‑smells, количество котиков). Обычно их результат — длинный отчёт в чате с десятками находок. Пару вы успеваете разобрать, а остальное уезжает в анналы истории.
С беклогом каждая находка аудита становится задачей с пометкой, откуда она пришла, с источником файл:строка и описанием риска. Важные находки и баги заводятся отдельными задачами, а мелочи — одной задачей с чек‑листом, по пункту на находку. Всё, что относится к одному аудиту, агент собирает в эпик.
Так ни один пункт аудита не теряется. К нему можно вернуться в любое время: открыть эпик, выбрать задачу и отдать агенту. А сам эпик закроется, когда будут решены все его задачи.
Грабли и текущие ограничения
Честно о том, что пока не так. Задачи группируются в эпики и связываются через блокеры и связанные задачи. Но это связи между отдельными находками, а не план работы (разбивать крупную задачу на подзадачи беклог пока не умеет).
Для беклога, куда агент кидает разрозненные замечания, этого хватает. Но как только хочется планировать крупную работу, связей между находками становится мало. Но это уже тема для отдельной статьи.
Второе ограничение — беклог локальный. Задачи лежат в ~/backlog на вашей машине, и поделиться ими с командой из коробки пока нельзя. Но никто не мешает построить мост к корпоративной Jira. Задачи в беклоге — обычные markdown‑файлы, а CLI отдаёт их в JSON. Важные находки можно выгружать в общий трекер и решать вопросы уже там.
Теперь немного истории из разработки
Прежде, чем писать свой инструмент, я искал готовые решения, но все они оказывались либо слишком громоздкими (съедали токены как не в себя), либо сами становились обузой, за которой нужно следить.
Первая версия беклога была просто скиллом. Агент складывал задачи в файлы и это работало в виде чёрного ящика. Чтобы понять, что именно туда ушло, как задачи связаны между собой и что уже закрыто, приходилось долго общаться с агентом, чтобы выяснить реальное положение дел.
Так появилась отдельная веб‑морда для полного контроля над беклогом, с графиками и статистикой. Бонусом графики долга по неделям оказались ровно тем, что так любят руководители.
Но самое заметное изменение — в ощущениях. На количество строк в пулреквесте снова приятно смотреть. Пулреквест можно ревьюить целиком, а не разбирать по коммитам, где тут задача, а где попутные правки и после ревью задач команды голова болит заметно меньше.
Как попробовать
Проект открытый, код на GitHub: p‑backlog, лицензия Apache-2.0.
Быстрый старт:
npm i -g p-backlog # нужен Node.js 22.13 или новее
Затем в Claude Code подключите плагин — он принесёт скилл и Stop‑хук:
/plugin marketplace add expatriate/p-backlog /plugin install p-backlog-ru@p-backlog
Для Codex и Cursor то же самое делает backlog setup. Веб‑приложение ставится командой backlog service install. Дальше достаточно попросить агента «запиши в беклог…».
P. S.: Проект планирует расти и набирать функционал. В планах сделать работу агента с беклогом ещё эффективнее, а метрики точнее и полезнее.
Мне очень интересно услышать, как вы решаете ту же проблему — куда ваш агент девает побочные находки? Если попробуете p‑backlog, то напишите в комментариях или в issues, что неудобно и чего не хватает.
P.P. S.: Чтобы повысить точность перепроверок и сэкономить токены, можно подключить отдельный пакет с графом кода — code‑review‑graph. p‑backlog подхватит его сам: инструменты дедупликации задач и поиска дублей будут использовать функционал графа.
