Память дала AI-агенту прошлое. Solo Kanban даёт ему настоящее

В какой-то момент я заметил неприятную вещь: AI помогает писать код быстрее, чем я успеваю удерживать контекст работы.

Задача начиналась как «поправить маленький баг», через час превращалась в несколько файлов, пару идей на потом и вопрос: «А мы вообще это уже проверили?» Код вроде написан. Diff вроде разумный. Но почему именно так? Какие варианты мы отбросили? Что обещали не трогать? Какие проверки обязательны? Где теперь лежат follow-ups?

Проблема была не в том, что AI плохо пишет код. Проблема была в том, что delivery жил в чате. Scope, решения, проверки и хвосты оставались в диалоге, а репозиторий видел только финальный diff.

Для маленьких задач это терпимо. Для проекта с несколькими сервисами, фронтендами, релизами, долгом и ML-интеграциями это быстро становится лотереей.

Так у меня постепенно появился Solo Kanban — небольшой git-native процесс, где состояние задачи лежит рядом с кодом: очередь, требования, исследование, спецификация, план, проверки и итог.

Это не попытка придумать «новый Scrum для одного человека». Скорее наоборот: это минимальный рабочий контракт между solo-разработчиком и AI-агентом.

Контекст серии

Эта статья продолжает две предыдущие заметки про память AI-агентов.

В первой я разбирал, как устроен Memory MCP Server: зачем агенту постоянная память, почему я выбрал SQLite, как сделал semantic search и какие грабли нашлись по дороге: «Как я спроектировал Memory MCP Server для AI-агентов: архитектура, SQLite, semantic search и грабли».

Во второй показывал, как этот слой вырос из локального semantic search в memory backbone для инженерных агентов: «Memory MCP Server, часть 2: как проект вырос из semantic search в memory backbone для инженерных агентов».

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

Эта статья как раз про следующий слой — процесс.

Сначала сломался не код, а контекст

Мой путь был довольно обычным.

Сначала ChatGPT был собеседником: объяснить подход, разобрать ошибку, накидать кусок решения. Это было похоже на очень быстрого rubber duck (резиновую утку), который ещё и умеет писать код.

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

Потом появились IDE-агенты и Codex-подобные инструменты: правки стали происходить ближе к репозиторию, быстрее и шире.

Скорость выросла. Цена потерянного контекста тоже.

Первые проблемы выглядели не как катастрофы, а как мелкое трение. Агент снова спрашивает правило, которое уже обсуждали. Я снова объясняю, почему этот endpoint нельзя трогать. Через два дня сам не помню, почему отложил один вариант и выбрал другой. В финальном сообщении есть аккуратное «готово», но follow-up, ради которого стоило завести отдельную задачу, растворился где-то в середине диалога.

Именно из этой боли сначала вырос Memory MCP Server. Хотелось, чтобы агент не начинал каждый день с чистого листа: помнил решения, архитектурные правила, прошлые грабли, важные документы. Это сильно помогло. Но довольно быстро выяснилось, что «помнить» и «вести задачу до конца» — разные навыки.

До AI я чаще страдал от медленного написания кода. С AI я начал чаще страдать от того, что код уже написан, но непонятно:

• почему задача решена именно так;

• где был исходный scope;

• какие non-goals мы зафиксировали;

• что агент проверил, а что только предположил;

• какие новые задачи родились по дороге.

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

Мне нужен был способ сделать работу видимой не в чате, а в репозитории.

Память помогает, но не закрывает задачу

На этом этапе память казалась главным недостающим слоем.

Память полезна. Она позволяет агенту помнить архитектурные решения, прошлые баги, проектные правила, типовые ошибки. Она отвечает на вопрос: «Что мы уже знаем?»

Но память не отвечает на другие вопросы:

• какую задачу брать сейчас;

• где начинается и заканчивается scope;

• какой уровень исследования нужен;

• когда можно писать код;

• какие проверки обязательны;

• куда класть follow-ups;

• когда задача считается закрытой.

Память дала агенту прошлое. Но рабочий день ему дал только процесс.

Без процесса память превращалась в склад заметок. Агент мог помнить много полезного и всё равно расползаться: начать с бага, зацепить refactor, по дороге «улучшить» соседний модуль, а в конце оставить человеку красивое summary без проверяемого состояния.

Мне нужен был не более умный prompt. Мне нужен был внешний контракт работы.

Почему обычный таск-трекер не подошел

Я не против Jira, Linear или другого нормального трекера. Для команды они решают реальные задачи: синхронизация людей, приоритеты, статусы, планирование, отчётность.

Но в solo-проекте часть этой механики превращается в лишнюю церемонию.

При этом простой список TODO тоже не подходит. Он слишком слабый. В нём обычно есть «что сделать», но нет:

• почему это нужно;

• что не входит в задачу;

• какие факты проверены;

• какие варианты рассматривались;

• какой design target;

• какие проверки надо запустить;

• что делать с найденными хвостами.

Нужен был middle ground: не тяжёлый внешний процесс, но и не «список задач в голове».

Параллельно я смотрел на готовые решения для AI-агентов: BMad-Method, GitHub Spec-Kit, taskmaster-ai, claude-flow, AutoGen workflows. Они интересные, но почти все оптимизированы под одну из крайностей — либо тяжёлый multi-agent orchestration с ролями и handoff’ами, либо линейный spec-driven flow под greenfield-проекты. Для solo-режима на живом продукте с legacy и tech debt мне нужно было что-то проще: не оркестратор, а контракт. Без новых runtime-зависимостей, без особого формата задач, без отдельного UI. Только файлы в репозитории и набор команд, которые умеют их читать и обновлять.

Так процесс переехал в Git.

Что такое Solo Kanban

Solo Kanban — это git-native delivery loop для одного разработчика и AI-агентов.

Его главная идея простая: состояние работы должно жить рядом с кодом.

Не в чате. Не в памяти человека. Не только в issue tracker. А в репозитории, в виде файлов, которые агент обязан читать и обновлять.

Базовые принципы:

• Git — источник правды для процесса.

• WIP max 1-2 — человек и агент не расползаются по задачам.

• Каждая активная задача имеет отдельный workspace.

• Research, spec и plan масштабируются по риску.

• Done означает verified outcome, а не «diff выглядит нормально».

• Закрытая задача оставляет архив доказательств.

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

Сразу оговорка про название. От канонического Kanban здесь остались только pull-flow и жёсткий WIP-лимит — ни доски с колонками, ни классических swimlane’ов нет. Я называю это Kanban потому, что для меня именно эти два свойства определяют рабочий ритм: задача вытягивается, когда есть мощность, и параллельных задач не больше двух. Если для вас Kanban — это в первую очередь про доску, читайте «Solo Kanban» как «git-native delivery loop с WIP-лимитом» — суть от названия не меняется.

Минимальная модель файлов

В корне планирования есть несколько файлов.

Для каждой активной задачи создаётся workspace:

tasks/<slug>/  requirements.md  research.md  Spec.md  tasks.md

Роли файлов такие:

Важно: эти файлы не обязаны быть большими. Это не бюрократия ради бюрократии.

Для маленькой docs-задачи research может быть мини-секцией на пять строк. Для рискованной задачи с API, миграциями или security — отдельным артефактом. Если research начинает раздуваться, это уже сигнал: задача не такая маленькая, как казалось.

И ещё одна оговорка: для совсем тривиальных правок — опечаток, форматирования, очевидных комментариев — workspace вообще не нужен. Достаточно одной строки в DONE.md и коммита. Иначе процесс становится тяжелее самой работы и тихо саботируется обходными путями.

Pipeline

Каждый шаг pipeline у меня реализован как Claude Code custom slash-command — это markdown-файлы в .claude/commands/, которые описывают агенту, что именно делать на конкретной стадии: какие файлы читать, что обновлять, какие проверки запускать перед переходом дальше. По сути это исполняемые playbook’и, привязанные к git-репозиторию. В Cursor или другом агентном IDE то же самое решается через rules/prompts; конкретный механизм не важен, важно, что у каждого gate есть формальное определение, а не «помни, что после кода надо запустить тесты».

Текущий pipeline выглядит так:

QUEUE  → /start-task  → /research  → /spec  → /plan  → /implement  → /write-tests  → /testing  → /finalize  → /merge-to-main  → DONE

Каждый шаг имеет понятную роль.

/start-task создаёт workspace и фиксирует проблему. На этом этапе важно записать не только «что делаем», но и «что не делаем».

/research проверяет неизвестные места. Это предохранитель от фразы «кажется, тут всё понятно».

/spec описывает target design. Особенно нужен, если есть API-контракты, миграции, security, cross-service integration или высокий blast radius.

/plan превращает spec в проверяемые шаги.

/implement делает diff.

/write-tests добавляет или обновляет проверки там, где меняется поведение.

/testing сверяет написанное с реальностью.

/finalize закрывает документацию, переносит follow-ups в planning files и архивирует workspace.

/merge-to-main завершает loop.

Этот pipeline — baseline. В работе каждая задача идёт по нему не полностью, а по тому набору шагов, который соответствует её риску. У меня обязательность шагов выбирается по Risk Profile из пяти сигналов: contract change, security, migration, cross-domain, runtime impact. Если ни одного сигнала нет — это Lightweight, и реально проходит implement → testing → finalize. Если есть сигналы среднего риска — Standard, с research и spec. Если есть security или migration — Full, с обязательным deep-review. Это даёт способ масштабировать процесс по риску, а не по моему ощущению «эта задача кажется большой».

Это не значит, что каждый шаг должен занимать полдня. Иногда весь research — это пять строк и одна ссылка на файл. Но сам факт gate помогает не превращать «маленькую правку» в скрытый refactor.

Пример checklist из tasks.md

В tasks.md я стараюсь писать не абстрактные пункты, а проверяемые шаги.

Например:

- [ ] **1.1** Добавить тест на ownership filter  <!-- mode: tdd | verify: go test -run TestOwnership ./backend/internal/... -->- [ ] **1.2** Обновить repository query с `WHERE owner_id = $N`  <!-- depends: 1.1 | verify: go test -run TestOwnership ./backend/internal/... -->- [ ] **1.3** Запустить локальную проверку handler path  <!-- depends: 1.2 | verify: go test ./backend/internal/handlers/... -->

Этот формат удобен не из-за красоты. Он ограничивает агента.

Если шаг не имеет проверки, агент слишком легко превращает его в «сделал по смыслу». Если шаг имеет verify, человек потом видит не только намерение, но и способ проверить результат.

Комментарии вида <!-- mode: tdd | verify: ... | depends: 1.1 --> — это не машинный DSL с отдельным парсером, а структурированные подсказки агенту. Markdown их игнорирует, человек видит обычный чек-лист, а агент при чтении файла извлекает mode, verify и depends как контракт шага. Никакого отдельного runtime — достаточно того, что агент инструктирован их соблюдать, и что verify действительно запускается перед галочкой.

Research/spec нужны не ради бюрократии

AI особенно уверенно ошибается в «очевидных» местах.

В большом codebase маленькое изменение часто цепляет скрытые зависимости: старый endpoint, feature flag, миграцию, generated types, тестовую изоляцию, чужой workaround.

Поэтому research в Solo Kanban ограничен по уровню:

• mini — несколько строк прямо в requirements;

• light — короткий отдельный файл;

• full — полноценный research с questions, findings, options, decision.

Если research не помещается в разумный лимит, это не «плохо исследовали». Это сигнал, что задачу надо дробить или переводить в design/spec.

То же со spec. Он нужен не всегда одинаково. Но когда задача затрагивает API, DB, auth, права доступа, внешние интеграции или несколько сервисов, «сразу писать код» слишком дорого.

Bug vs tech debt

Отдельно пришлось формализовать разницу между bug и tech debt.

Моя рабочая граница такая:

• bug — код нарушает обещанный контракт;

• tech debt — код работает по контракту, но форма реализации ухудшает поддержку.

Примеры:

Это снижает шум. И человеку, и агенту проще понять, что чинить срочно, а что планировать как maintenance.

Как это помогает AI-агенту

Самое полезное оказалось не в том, что агент стал «умнее».

Он стал ограниченнее.

У него появились рельсы:

• вот задача;

• вот non-goals;

• вот факты;

• вот target design;

• вот план;

• вот проверки;

• вот место для хвостов.

Агент читает task workspace, а не угадывает историю из чата. Человек проверяет не поток рассуждений, а артефакты и diff. Follow-ups не теряются в финальном сообщении. Архив задачи становится материалом для будущей памяти.

Это особенно важно, когда агент работает несколько часов или когда задача переживает несколько сессий. Чат может оборваться. Контекст может ужаться. Модель может забыть детали. Но requirements.md, Spec.md и tasks.md остаются в репозитории.

И здесь же замыкается связь с Memory MCP, про который были две предыдущие статьи. /research начинает работу с recall_canonical_knowledge и semantic_search — агент сначала проверяет, что про эту область уже известно из прошлых задач, и только потом формирует findings. /finalize пишет обратно: решения уезжают в store_decision, постмортемы — в store_postmortem, неочевидные паттерны — в store_memory с тегами. Память даёт прошлое, процесс — настоящее, и каждый закрытый workspace становится материалом для следующего research-шага. Без процесса память превращалась в склад заметок; без памяти процесс начинался каждый раз с чистого листа.

Что ломается, когда gate’ов нет

Самый показательный случай — это agent reviewer, который одобрил задачу с нулевой реализацией.

Был внутренний инструмент, где один LLM-агент делал работу, а другой LLM-агент её ревьюил. На одной задаче reviewer прислал approve, хотя по факту был добавлен один декоративный LOC и никакой реальной логики. Surface-level совпадение declaration с requirements его убедило. Если бы дело шло через Solo Kanban с обязательным /testing, эта задача упёрлась бы в шаг verify: тестов на новое поведение нет, существующие проверки ничего не подтверждают, gate не пройден.

После этого /testing перестал быть «опциональным шагом для серьёзных задач». Это стало обязательным gate’ом для всего, что доходит до /finalize. Reviewer-LLM может ошибаться на approve. Запуск тестов — не может.

Похожая история с planning-hygiene. В какой-то момент NEXT.md распух до >250 строк закрытых записей, и я перестал в нём ориентироваться. После этого появилось правило: при /finalize, если файл планирования перевалил порог, закрытые записи переезжают в DONE.md тем же шагом. Маленькое правило, но без него планирование медленно перестаёт работать как навигация и превращается в архив.

Где это обкатывалось

Я обкатывал этот процесс не на игрушечном репозитории.

В моем случае это Croqui — продукт для людей, которые хотят учиться рисовать. Пользователь рисует сам, а AI помогает разобрать работу: что получилось, где слабое место, на что обратить внимание в следующей попытке. Важно, что это не генератор картинок и не история «AI нарисует вместо тебя». Идея ближе к учебному циклу: задание → попытка → разбор → следующий шаг.

Снаружи это выглядит как понятный consumer-продукт про рисунок и обучение. Внутри быстро появляется обычная инженерная реальность: загрузка изображений, хранение работ, AI-разборы, прогресс ученика, планы занятий, авторизация, платежи, несколько фронтендов, маркетинговый контур, релизы и постоянный технический долг.

Поэтому для Solo Kanban Croqui оказался хорошей проверкой. Это не «hello world» и не один скрипт вокруг LLM, а живой продукт, где маленькая правка легко цепляет ML-сервис, API-контракт, UI, биллинг или маркетинговую аналитику.

В цифрах это выглядит так. За последние месяцы через Solo Kanban прошли десятки задач в неделю — на пиковой неделе апреля 2026 закрылось 59 задач, что было бы немыслимо без AI-агентов и контракта, который не даёт им расползаться. WIP стабильно держится на 1-2 активных задачах. /research несколько раз ловил несовпадение моих предположений с кодом ещё до того, как был написан первый diff — и это, пожалуй, главное, ради чего вообще стоит заводить gate перед /implement.

Без процесса агентная память помогала вспоминать решения, но не гарантировала, что задачи закрываются аккуратно. Solo Kanban оказался тем слоем, который превращает память и генерацию кода в delivery loop.

Что оказалось лишним

Со временем стало понятно, что не всё должно быть core.

Deploy, Kubernetes, release flow, маркетинг, индексация документации, интеграции с конкретными агентами — это adapters. Они полезны в конкретном проекте, но не должны быть частью минимального метода.

Например, у меня изначально /deploy был обязательным шагом сразу после /testing. Это быстро сломалось на docs-only задачах: писал статью, заполнял spec, доходил до /finalize — и pipeline требовал деплоя сервиса, которого правка вообще не касалась. Шаг переехал в опциональный adapter «для задач с изменениями сервисов». Аналогично с /research: сначала он был жёстко обязательным с full-форматом, потом разделился на mini / light / full по уровню риска — обязательность осталась, а формат стал масштабироваться. И ещё один кейс: /write-doc был отдельным шагом pipeline, потом стал частью /finalize, потому что отдельной ценности он не давал, а лишний gate замедлял маленькие задачи.

В core я бы оставил только:

• state machine;

• planning files;

• task workspace;

• templates;

• rules for research/spec/plan;

• completion rules.

Хороший знак для такого процесса — его можно выкинуть наполовину, и он всё ещё полезен.

Solo Kanban как отдельный фреймворк

Метод теперь живёт отдельным репозиторием: github.com/ipiton/solo-kanban-framework (MIT, v1.0.0). Идея простая — отделить метод от конкретного проекта. В одном проекте будут Go, PostgreSQL и Kubernetes. В другом — Python и notebooks. В третьем — frontend-only. Но базовый контракт «задача должна иметь scope, план, проверки и closure» остаётся тем же.

Что внутри:

• docs/method.md — операционная модель и принципы.

• docs/workflow.md — pipeline, gates и Step Matrix для трёх tier’ов задач (Lightweight / Standard / Full). Какой шаг можно пропустить, а какой обязателен, выбирается по Risk Profile из пяти сигналов: contract change, security, migration, cross-domain, runtime impact. Это та часть, которая в статье намеренно описана упрощённо — в репозитории матрица развёрнута до уровня, по которому уже можно работать.

• docs/artifact-contract.md — форматы requirements.md, research.md, Spec.md, tasks.md.

• docs/ai-agent-playbook.md — как агент должен читать и обновлять артефакты.

• templates/planning/ — заготовки NEXT, DONE, BUGS, TECH-DEBT, BACKLOG, DECISIONS, ROADMAP.

• templates/task/ — заготовки workspace задачи.

• agents/claude/ и agents/codex/ — готовые адаптеры команд и скиллов под Claude Code и Codex.

• examples/minimal/ — минимальный пример проекта.

Quick start короткий: копируете templates/planning/* в docs/planning/, templates/task/* в tasks/templates/, опционально подключаете команды или скиллы из agents/. Дальше для каждой задачи определяете Risk Profile, выбираете tier и идёте по pipeline. README сейчас на английском — если на запуске нужен русский перевод, открывайте issue, это станет приоритетом.

Итог

Главный урок простой: если AI пишет код быстрее, чем человек успевает помнить контекст, процесс должен жить не в голове и не в чате, а рядом с кодом.

Solo Kanban не делает агента безошибочным. Он делает ошибки видимыми раньше: в requirements, research, spec, plan, tests или closure.

Для solo-разработчика это оказалось важнее, чем ещё один «умный» prompt.

Prompt помогает начать работу. Процесс помогает её закончить.