Beads продолжает набирать обороты. Когда мои старые друзья начинают натыкаться на него независимо друг от друга, я понимаю, что проект становится вирусным.
Beads занимает совершенно уникальную нишу. Все сосредоточены на создании инструментов планирования, в то время как Beads - это инструмент исполнения. Это всё равно что поставить вашего ИИ-агента на отлично смазанные лыжи. Возможно, лучшим названием было бы Agents on Rails («Агенты на рельсах»). Но название «Beads» (Бусины) хорошо передает идею того, что инструмент сфокусирован исключительно на отслеживании (трекинге) и ни на чем другом: маленькое имя для маленькой системы.
Сейчас, спустя почти 6 недель своего пути, Beads стал намного, намного стабильнее. Это была безумная гонка, порой менялось по 50 тысяч строк кода в день. И никто из нас, контрибьюторов, даже не просматривает этот код. Он на 100% написан ИИ («vibe coded»), сейчас в нем 130 тысяч строк на Go, и примерно половина - это тесты. Десятки тысяч людей используют его в своих повседневных рабочих процессах. Люди говорят мне, что им это так нравится, что они используют его даже для личных списков дел (TODO). А другие направо и налево встраивают его в более крупные оркестраторы. Это также потрясающий строительный блок.
Мы сохранили небольшой объем функционала. Прислушиваясь к мнению сообщества, я отвергаю всё, что не должно быть частью ядра Beads. Поэтому у Beads нет пользовательского интерфейса (UI), но есть множество примеров UI, которые люди создали как проекты «для души» (passion projects). У нас их уже как минимум четыре или пять. Мой приятель и соавтор Джин Ким даже создал свой собственный UI для Beads на Java Swing! Он был так взволнован, когда показывал мне его. И это действительно было очень круто.
Итак, никакого UI, и у Beads также нет системы планирования. Он не для этого. Но он отлично интегрируется с любой системой планирования - просто составьте план, а затем попросите агента создать в Beads эпики и задачи (issues) для этой работы. После того как эпики будут готовы, вы можете натравить на них любое количество агентов, чтобы они их «разгребли».
Последняя большая категория, которую люди постоянно пытаются втиснуть в Beads, - это оркестрация. Мы знаем, что оркестрация неизбежна. И есть соблазн сделать Beads более активным; сегодня он довольно пассивен и ожидает, что Агент будет использовать его как инструмент. Но люди хотят большего. И я их понимаю. Однако этому не место в Beads.
Beads + Agent Mail = Деревня агентов
Самым убедительным аргументом в пользу прямой интеграции с оркестратором стал MCP Agent Mail, написанный джентльменом по имени Джеффри Эмануэль. Мы не были знакомы, но он реализовал систему обмена сообщениями между агентами, вдохновленную электронной почтой, и пару недель назад он написал мне в LinkedIn, взволнованно сообщив, что она отлично работает с Beads.
Он сказал, что Beads дает агентам общую память, а MCP Agent Mail дает им обмен сообщениями... и это всё, что им нужно. Удивительно, говорит он, что это не требует масштабной настройки или координации. Вы просто даете им задачу и говорите разобраться между собой. У них нет эго, поэтому они быстро выбирают лидера и просто распределяют задачи.
Личный многоагентный рабочий процесс Джеффри очень отличается от моего, и мне он напоминает то, как я работал подрядчиком в Accenture в конце 1990-х. Их система контроля версий была настолько дрянной, что только один разработчик мог заблокировать файл за раз, и никто другой не мог над ним работать. Мы называли это «сникернет» (sneakernet) — приходилось бежать в чей-то куб, чтобы попросить разблокировать файл. Однажды пришел парень и спросил: «Как долго у тебя будет этот файл?», я ответил: «Около месяца?», и он побелел как полотно. Пришлось договариваться.
Я больше не люблю так работать, но именно так Джеффри хочет, чтобы работали его агенты: все в одной копии репозитория (папке). Поэтому MCP Agent Mail поставляется с системой резервирования файлов, очень похожей на нашу старую VCS в Accenture. И хотя работать так кажется безумием, он уверяет меня, что агенты просто сами разбираются. Они довольно устойчивы.
Забавно, но это в точности совпадает с моим отношением к Beads. Это дрянная архитектура (по стандартам до-ИИ эпохи), которая требует ИИ, чтобы обойти все крайние случаи, где она ломается. Но ИИ всегда может заставить её работать (обычно без особых усилий). Так что ИИ «оживляет» дрянную архитектуру и делает её не-дрянной. Ну, или менее дрянной.
Я работаю над настройкой своей собственной «деревни агентов» на основе git worktree, также используя Beads и MCP Agent Mail. Джеффри был так любезен, что модифицировал её для поддержки модели worktree, которой не нужна система резервирования файлов; она использует ветки git. Я сейчас тестирую это с фронтендом на Emacs (который скоро будет работать на Efrit), чтобы я мог легко переключаться между 30+ агентами-работниками в разных буфера�� vterm. Больше никаких цветных окон терминалов, расползающихся по моему экрану! А Mail даст им возможности роя (swarm capabilities). Я уверен, это увеличит мою продуктивность в 3-5 раз. Узнаю на этой неделе.
Повесть о двух блогерах
Здесь история с MCP Agent Mail становится еще интереснее. Джеффри живет в Нью-Йорке, и 2 недели назад предложил выпить кофе, если я буду в тех краях. К счастью, на этой неделе я был там на отличной конференции AIE от Swyx, так что в четверг мы встретились под дождем на Манхэттене и гуляли около 2 часов, пытаясь найти мой отель. Мы так увлеклись разговором, что агрессивно шли не в ту сторону минут 20, и так раза два или три, прежде чем наконец нашли отель и нормально пообедали.
Автор MCP Agent Mail оказался одним из самых невероятно, запредельно гениальных людей, которых я когда-либо встречал в своей жизни. Я не разбрасываюсь такими словами. В итоге он говорил большую часть времени, так как мне, честно говоря, было мало что добавить, но я был очарован, всё это время забавляясь тем, что он все еще хочет, чтобы его агенты копались в одной папке, как еноты в мусорном баке. Предпочтения разработчиков так непредсказуемы.
Короче говоря. Оказалось, что он тот самый парень, который в январе стер 2 триллиона долларов с мирового фондового рынка своим постом «Короткая позиция по акциям Nvidia». Я узнал об этом спустя 3 часа, во время обеда в отеле. Сюрприз!
Так что мое чутье меня не подвело; он действительно ЯВЛЯЕТСЯ одним из самых жестко умных людей на Земле. Он инженер топ-уровня, математик, исследователь ИИ и финансист хедж-фонда — одинаково высочайшего уровня во всем, и он кажется более целеустремленным, чем любой человек, которого я встречал. Вот список его проектов: jeffreyemanuel.com/projects
Я ушел с нашей встречи с уверенностью, что Джеффри Эмануэль вполне может опередить исследователей из передовых лабораторий в поиске архитектуры LLM следующего поколения. У него, по крайней мере, есть шанс. Время покажет.
Так что да. Beads. Ему нравится Beads. Хорошая рекомендация. И знаете, кому еще нравится Beads?
Моделям. Просто спросите их.
На этом давайте перейдем к текущим известным лучшим практикам.
Лучшие практики для одиночной разработки
У меня не так много опыта совместного использования Beads с другими людьми в команде, поэтому я был бы рад, если бы те из вас, у кого есть опыт, поделились лучшими практиками для команд. Я могу дополнить этот пост особенно сочными советами.
Для моей собственной разработки вот несколько советов, которые я нашел полезными.
Регулярно запускайте bd doctor
У Beads есть отличная команда bd doctor, которая диагностирует и автоматически исправляет широкий спектр проблем. Она также обрабатывает миграции и обновления метаданных для различных функций, включая git hooks и другую конфигурацию.
Вам стоит взять в привычку запускать bd doctor каждый день в ваших репозиториях.
Держите базу данных небольшой
Я запускаю bd cleanup каждые несколько дней в каждом проекте. Как только у меня накапливается более 200 задач (issues), я начинаю думать об очистке, и редко позволяю этому числу превысить 500.
bd cleanup удаляет любые задачи старше N дней. Я устанавливаю 2 дня, потому что я промалываю так много работы, что мне приходится быть агрессивным. После этого вы можете запустить bd sync, чтобы синхронизировать базу данных и отправить всё в git.
Это никому не вредит. Задачи всегда остаются в истории git, даже после их удаления, потому что Beads — это git-нативный трекер задач. Так что вы всегда можете легко изучить их и воскресить при необходимости.
Поддержание небольшого набора рабочих задач — это оптимизация производительности, которую вы оцените. Например, часто агенты просто используют jQuery для поиска прямо в файле issues.jsonl. Это не сработает, если ваш файл больше 25 тысяч токенов (текущий лимит для чтения файлов целиком), что составляет примерно 500 задач Beads, навскидку.
Регулярно обновляйтесь и проводите ежедневную гигиену
Beads получает много исправлений ошибок, и его качество быстро растет. Убедитесь, что вы следите за релизами и обновляетесь хотя бы раз в неделю или две.
Теперь вы можете использовать bd upgrade для обновления. Периодически запускайте bd doctor [--fix].
Beads — довольно сложная система, и при слияниях часто возникают конфликты. С каждой неделей становится намного лучше, так как мы исправляем больше пограничных случаев, но вам всё равно часто придется просить агента убрать беспорядок в Beads — сломанные rebase, конфликты, требующие ручного разрешения, и т.д.
Планируйте вне Beads, затем импортируйте
Используйте свой любимый инструмент планирования, например, что-то вроде OpenSpec, чтобы создать план. Как только он будет пересмотрен моделью несколько раз, вы готовы перевести его в Beads.
Мой совет для более крупного плана — делать следующее:
Во-первых, попросите вашего агента создать набор подробных эпиков и задач (issues) в Beads, чтобы отслеживать всю работу по плану, уделяя особое внимание зависимостям, детальному проектированию и потенциальному распараллеливанию.
Во-вторых, как только агент закончит создавать все "бусины" (beads), попросите его сделать тщательный обзор, вычитку, уточнение и полировку, чтобы обеспечить работникам максимально гладкую реализацию эпиков.
Вы можете попросить его итерировать и улучшать ваш план до 5 раз, и снова попросить итерировать и уточнять эпики Beads до 5 раз, прежде чем он скажет: «Я не думаю, что мы можем сделать намного лучше, чем это».
Часто перезапускайте агентов
Агенты должны решать по одной задаче за раз. Как только задача выполнена, убивайте процесс и запускайте нового агента. Beads действует как рабочая память между сессиями. Часто запуская новые сессии, вы экономите деньги и получаете лучшую производительность от моделей.
Просите ИИ создавать много задач
Вам следует просить ИИ создавать beads для отслеживания любой работы, выполнение которой займет у него более 2 минут.
Когда вы просите сделать код-ревью, скажите ему создавать beads по ходу дела. Это приведет к гораздо более действенным результатам ваших код-ревью.
Модели часто решают создавать задачи в Beads спонтанно, но иногда подталкивать их тоже полезно.
Используйте короткий префикс задач
Мои префиксы проектов на данный момент: bd-, vc-, wy-, ef- и gt-.
Мир становится намного более читабельным, если вы сокращаете размеры идентификаторов в вашем трекере задач, используя короткие префиксы.
Beads поддерживает изменение префикса задач, поэтому если вы установили его как my-long-project-, вы можете попросить своего агента использовать команды Beads, чтобы изменить его, например, на mlp-.
Создавайте баг-репорты и запросы функций для Beads
Заходите на GitHub и создавайте баги как GitHub Issues. Вы также можете просить о функциях в разделе Discussions или просто публиковать общие вопросы или комментарии.
Мне удавалось справляться с запросами функций до сих пор, так что не стесняйтесь.
Рассказывайте другим о Beads
Если вам нравится Beads, поделитесь любовью в социальных сетях. Это такой отличный способ использовать кодинг-агентов, что нам стоит поощрять людей пробовать его. Особенно сейчас, когда он становится немного стабильнее.
Beads на подъеме
Beads стал приятным сюрпризом. Он быстро растет и доказывает, что решает реальную боль разработчиков в мире агентного кодинга. Да, мы все еще разглаживаем множество шероховатостей. Это только начало. Но каждый релиз приближает нас к надежной, стабильной системе для совместного отслеживания задач между несколькими работниками.
Об авторе
Стив Йегге - бывший сотрудник Geoworks, Amazon, Google, Grab и Sourcegraph, имеющий более 30 лет опыта работы в технологической индустрии и 40 лет опыта программирования в общей сложности.
