Переход от чата к бэклогу
Три месяца назад моим управлением задачами было просто окно чата. Если я закрывал вкладку, план исчезал.
Сегодня это бэклог в Postgres. Три разных ИИ-агента — Claude Code, Codex и Grok — берут из него задачи. Они помечают их авторством и закрывают, привязывая к истории git.
Я не ставил перед собой цель построить систему управления проектами. Я просто постоянно упирался в стены. Каждый раз, когда я устранял одну проблему, появлялась новая.
Моя работа очень интенсивная. Я руковожу персональной платформой данных под названием Nexus. Я управляю примерно 100 репозиториями. За один период я выпустил 557 000 строк кода за 35 дней. Такой объем сломал все методы планирования, которые я пробовал.
Вот как эволюционировала моя система:
Этап 1: Планирование через диалог План жил в истории чата. Я рассуждал вслух, придумывал хорошую идею и начинал разработку.
- Проблема: Планы испарялись, когда чат заканчивался. Их нельзя было приоритизировать или передать кому-то другому.
Этап 2: TODO-файлы в каждом репозитории Я начал использовать файлы TODO.md в каждом репозитории. Я перестал использовать простые чек-листы. Вместо этого я писал небольшие спецификации. Каждый пункт включал:
- Статус и дату.
- Триггер (почему это становится срочным).
- Заранее определенные шаги (план).
- Известные риски.
- Проблема: При 100 репозиториях у меня не было общей картины. Я не мог видеть всё, что мне нужно сделать, в одном месте.
Этап 3: Операционный бэклог (OB) Я перенес задачи в базу данных Postgres. Это создало глобальную очередь. Я добавил этап одобрения. Задача становится реальной только после моей проверки. Это предотвращает засорение бэклога мусором со стороны ИИ. Я использовал статусные каналы:
- requires_triage
- requires_decision
- requires_investigation
- autonomous_safe
- Проблема: Я стал узким местом. Я не успевал разгребать эти каналы.
Этап 4: Мультиагентное исполнение Теперь бэклог — это общая очередь для нескольких ИИ-агентов.
- Они используют механизм аренды (leases), чтобы не работать над одной и той же задачей.
- Они используют атрибуцию, чтобы я знал, кто и что сделал.
- Они могут передавать работу друг другу. Один агент может обнаружить, что задача невыполнима, и создать задачу-предпосылку (prerequisite). Второй агент может затем подхватить эту предпосылку и завершить основную задачу.
Урок прост: для успеха вам не нужен четвертый этап.
Если вы заберете себе что-то одно, заберите формат второго этапа. Описывайте свои задачи со статусом, триггером, заранее определенными шагами и рисками. Это ничего не стоит, но меняет всё.
Самое важное правило заключается в следующем: всегда планируйте, опираясь на истину. Никогда не планируйте, основываясь на догадках или кратких выжимках. Идеальный план, построенный на устаревших данных, провалится так же быстро, как и полное отсутствие плана.
Дополнительное обучающее сообщество: https://t.me/GyaanSetuAi