KotПрощай, простыня в Markdown, или почему кремниевым нужна своя Jira 📿🤖
В посте про 29 кругов мутационного ада я упомянула, что оставила своих кремниевых наедине с бэклогом. Рассказываю, что это вообще за бэклог такой и почему BACKLOG.md отправляется на свалку истории.
Как обычно выглядит управление задачами в агентской разработке? Первое, что приходит в голову — это markdown. Ну а что, дешево, сердито, лежит в репозитории под гитом.
Но как только проект вырастает из детских штанишек, маркдаун превращается в тыкву:
— Простыня бэклога разрастается, жрет полезный контекст, и агент начинает теряться в ней.
— Связности туда исходно не завезли, и попытки ее держать выглядят грустно. В то же время задачи могут зависеть друг от друга или блокировать друг друга.
— Статусы плывут. Запустишь двух агентов параллельно — они либо возьмут одну и ту же задачу, либо передерутся при мерже этого несчастного md.
Про человеческую Jira я молчу. Заставлять агентов ходить в облачный таск-трекер, созданный для того, чтобы люди двигали карточки на дейликах — это какой-то особый вид мазохизма. Тем более обычно агенты сами должны докидывать задачи, и, учитывая, сколько логики менеджмент обычно навешивает на Jira, задачи-то они наплодят, но в менеджерскую концепцию это вообще не уложится.
И тут мы наблюдаем тектонический сдвиг. С приходом агентской разработки традиционные инструменты стремительно отмирают. IDE становятся ненужной прослойкой, все лабы уже уходят от VS Code. Трещит по швам Git, не рассчитанный на то, что в него будут коммитить со скоростью пулемета. Очередь дошла и до таск-трекеров.
Чтобы агенты не топтались друг у друга по ногам, я закатила в проект Beads (bd) от Стива Йегге. По сути, это такая локальная Jira для агентов, где бэклог — это не текст, а версионированная графовая БД (под капотом там Dolt, который умеет ветвиться и мержиться на уровне ячеек).
Что изменилось на практике, когда задачи стали «бусинами» в графе, а не строчками в блокноте:
⏺Агенты видят блокеры и зависимости. Задачи связаны в граф. Агент дергает bd ready и получает ровно то, что можно брать прямо сейчас, не пытаясь пилить фичу, под которую еще не готов контракт или схема БД.
⏺Параллельная работа. Команда bd update --claim атомарно лочит задачу за конкретным воркером. Кодеры спокойно разбирают каждый свой кусок и шуршат параллельно, не затирая чужое.
⏺Пайплайн со статусами и передачей эстафеты. Вот тут начинается настоящая красота для Dark Factory. Кодер допилил фичу, перевел статус — и в дело автоматически вступает агент-тестировщик, который целенаправленно выбирает задачи в нужном статусе и гоняет по ним проверки и мутационку, или что вы еще придумаете. Никакого ручного пинг-понга в чатах.
⏺Контекст на подносе. Вместо того чтобы скармливать модели всю историю проекта, bd prime выдает агенту компактный слепок: что происходит в воркфлоу прямо сейчас.
У Йегге есть отличный термин для главной боли LLM — проблема «50 первых свиданий»: по сути же каждая новая сессия не знает ничего о проекте. Вот тут память о процессе работы наконец-то отделена в отдельную, удобную агенту сущность.
Инструмент еще активно развивается, при обновлениях иногда разъезжаются схемы, так что напильник далеко не убираем. Но сама концепция — ровно в десяточку.
Агентские конвейеры разработки работают со скоростями, под которые наши старые инструменты не были рассчитаны. Так что вслед за ручным кодингом нам придется прикопать и старые инструменты.
@kot_review #оркестрация@kot_review #мойсетап@kot_review