
Я занимался вайб-кодингом (vibe coding) как одержимый сорок дней и сорок ночей. Это долгая история, поэтому я резюмирую её в этих трех картинках.
Слева, 3 недели назад: я вайб-кожу на пляже за ужином в Кабо-Сан-Лукас, Мексика, с неподражаемым Торстеном Боллом, нашим приятелем Мэттом Манелой и другими коллегами из Sourcegraph на корпоративном выезде. Кто-то сделал это фото, потому что я отказывался убрать компьютер.
В центре, 2 недели назад: фотография, на которой я фотографирую сам себя, пока еду на скорости 100 км/ч (60 миль/ч) по шоссе в Беллингем, чтобы забрать гитары, занимаясь голосовым вайб-кодингом всю дорогу туда и обратно. Глупо и чертовски опасно. Мне было плевать. Застрял в пробке на несколько часов. Всё равно плевать. Я упоминал, что это вызывает привыкание? Вайб-кодинг вызывает привыкание.
На последнем кадре: мы с женой в торговом центре на прошлой неделе, наслаждаемся приятным днем с кофе, наблюдаем за людьми и вайб-кодим вместе с Моцартом (на фото он в своей любимой сумке). Лин прячется за компьютером - так я получил разрешение руководства на публикацию снимка.
Я никуда не хожу и не делаю ничего, даже не сплю, без своего ноутбука. Ну, разве что когда бегаю - там я ещё не совсем раскусил, как вайб-кодить. Но я близок. Это тема для отдельного поста, но у меня наконец-то работают агенты на GCP с Terraform и Tailscale. Так что скоро я смогу вайб-кодить и с телефона.
Агенты никогда не должны отдыхать.
После года ежедневного вайб-кодинга и даже соавторства книги об этом (!), первого сентября мое зарождающееся видение движка оркестрации агентов наконец расцвело. Я немедленно отправился в плавание, чтобы воплотить его в жизнь с помощью вайб-кода. Я оптимистично назвал его vibecoder. И затем я вкалывал день и ночь, как вы можете видеть по коллажу выше. Я многому научился, всяким крутым штукам, которыми со временем поделюсь.
К сожалению, из-за некоторых ранних фундаментальных архитектурных просчетов ("детских ляпов"), на прошлой неделе мне пришлось сжечь всё это дотла, оставив после себя лишь пепелище деревни TypeScript, себя в чём мать родила и яйцо дракона. Это яйцо вылупилось, и маленький дракончик, выползший из пепла - Beads - это то, чем я делюсь с вами сегодня.
(Для тех, кому лень читать: загляните в README.md на GitHub. Моя цель здесь - объяснить, почему Beads - это величайшее изобретение со времен баг-трекера, и почему вы захотите начать использовать его прямо сейчас, потому что это и есть баг-трекер. Особенный. В двух словах: вы устанавливаете инструмент bd, натравливаете его одной строкой на ваши AGENTS.md или CLAUDE.md, и ваши агенты внезапно обретают способность к долгосрочному планированию и обнаружению задач. Это мгновенный когнитивный апгрейд.)
Так как же мы дошли до жизни такой - запуска баг-трекера (из всех возможных вещей) вместо моего амбициозного проекта vibecoder? Думаю, моя история может найти у вас отклик, если вы ежедневно используете Claude Code, Sourcegraph Amp, OpenAI Codex или подобных кодинг-агентов.
Мое видение 2025 года, становящееся всё более четким и ясным, заключалось в автоматизации агентного рабочего процесса, который я использую каждый день. Легко заметить, что от 95 до 99% взаимодействий, которые мы ведем с кодинг-агентами, могли бы быть обработаны правильно проинструктированной моделью. "Теперь почини сломанные тесты". "Нет, мне всё равно, какую из этих двух вещей ты сделаешь первой". "Да, я хочу, чтобы ты продолжил". "Нет, ты не можешь удалить эту таблицу базы данных". Серьезно, да ладно вам. Моя должность в LinkedIn уже как минимум полгода - "Нянька для ИИ" (AI Babysitter), и нет никаких признаков того, что это скоро изменится.
Вайб-кодинг включает в себя выполнение одного и того же дерьма, снова и снова. Эти агенты невероятно мощны и продуктивны, но они требуют постоянного мониторинга, по большей части рутинного. И так же, как и вы, я хочу автоматизировать эту работу, чтобы я мог вернуться к видеоиграм и при этом быть продуктивнее, чем когда-либо в истории человечества. Кто бы этого не хотел?
Как рассказывается в нашей книге "Vibe Coding", профессиональный процесс вайб-кодинга имеет множество измерений. Чтобы делать это правильно и гарантировать стабильно высокое качество результатов, нужно выполнить множество шагов. У вайб-кодинга есть Внешний, Средний и Внутренний циклы разработки. Одним словом, это сложно.
1 сентября я смело (или глупо) решил попытаться автоматизировать все шаги одновременно. Я навайб-кодил гигантскую работающую систему, только чтобы обнаружить через месяц, что совершил пару очень серьезных архитектурных ошибок. Вместе они просочились через всю систему и фактически уничтожили её. Моя страховая компания посмотрела на кодовую базу в 350 тысяч строк и сказала, что просто выпишет мне чек ("тотал", не подлежит восстановлению). Это было невозможно починить.
Можете смеяться сколько влезет. Но вы не получили ни яйца дракона, ни "костюма Адама", ни сожженной деревни TypeScript, ни эмоциональных шрамов. Я ни о чем не жалею. Немного. Кое о чем. Окей, я жалею... о многом. У меня куча сожалений. Но оставим их для другого поста.
Я расскажу немного о том, что пошло не так, поскольку уверен, что вы умираете от желания узнать, как я умудрился так феерично облажаться, пусть и с неожиданным счастливым финалом ("серебряной подкладкой").
Моим первым неверным решением было использование Temporal, о котором я (с энтузиазмом) разглагольствовал месяцами, но который в итоге оказался немного тяжеловесным для сценария десктопного инструмента разработчика - даже такого, который управляет роем агентов (swarm). Это прекрасный продукт, и все должны его использовать... если только вы не создаете легковесный инструмент для разработки.
В последние несколько недель, по мере того как я узнавал больше о Temporal и набирался опыта, до меня начало доходить, что это может быть стрельбой из пушки по воробьям. В конечном счете, на прошлой неделе я получил совет от знакомого из Anthropic - они там тоже пробовали это использовать - который заставил меня действовать согласно моим растущим опасениям и отказаться от Temporal в пользу более легкого самописного оркестратора.
К сожалению, я действительно сильно вложился в Temporal и построил vibecoder как Temporal-native приложение с самого основания. Так что предложение удалить/заменить Temporal было масштабным изменением, от которого ИИ сказали: "Воу! Это колоссальное изменение!"
Вы никогда не хотите этого слышать. Это был первый сигнал о том, что я, возможно, попал в типичную для вайб-кодинга ситуацию, когда проще переписать что-то с нуля, чем исправлять - феномен, который мы с моим соавтором Джином Кимом замечали весь год.
Итак, это была первая половина того, как я угробил свою кодовую базу.
Другой колоссальной ошибкой проектирования, которую я совершил, была ставка на markdown-планы - те самые, которые агенты уже используют по умолчанию, организуя и планируя свою работу. Казалось, агентам нравятся markdown-планы. Ну, в смысле, они используют их всё время, для всего. Верно?
Плюс вы получаете версионирование с помощью git, чего не дает база данных. Поэтому я решил пойти ва-банк с подходом "Мастер-Плана", принять git и структуру каталогов, и создать сервис, который позволяет агентам интеллектуально обновлять общий план по мере необходимости.
Неделями мне снились лихорадочные сны об удобном для агентов рабочем плане: иерархическом, хорошо организованном, гибком, версионируемом, адаптивном и легко превращаемом в приоритетную очередь задач. Моя мечта заключалась в том, чтобы сбрасывать кодинг-агентов, как десантников, на Гору Планирования, чтобы они могли начать реализовывать любую её часть в любой момент.
К сожалению, мои десантники вечно терялись в Джунглях Плана, и их быстро отстреливали местные. К тому времени, как я наконец нашел решение, которое работает - Beads - я обнаружил, что у меня в папке plans/ лежит шестьсот пять файлов markdown-планов в разной стадии разложения.
Ого-го. 605 непостижимых планов. Что происходило с моим Мастер-Планом?
Проблема, с которой мы все сталкиваемся с кодинг-агентами, заключается в том, что у них нет памяти между сессиями - сессиями, которые длятся всего около десяти минут. Это фильм "Помни" (Memento) в реальной жизни или "50 первых поцелуев".
Всё, что знают агенты при загрузке - это то, что они могут найти на диске. Какую бы видеокассету они ни нашли в магнитофоне, когда проснутся - на том они и сфокусируются.
К сожалению, типичные инженерные рабочие процессы в реальном мире, как правило, очень длинные и должны охватывать множество сессий "сжатия" (перезапуска) агента, даже для реализации одной небольшой фичи, из-за объема необходимого тестирования, последующих ревью и чистки кода.
Более того, и что еще хуже, в реальном мире ваши инженерные рабочие процессы имеют тенденцию вкладываться друг в друга по мере появления новых вводных. Вы можете работать над каким-то компонентом UI и внезапно понять, что нужно отложить это, чтобы исправить проблему в базе данных, которая поддерживает этот компонент.
Достаточно просто: вы закидываете этот поток работы по UI в свой ментальный стек, чтобы продолжить позже. Эта рекурсия может продолжаться довольно глубоко, но как человеку, вам не составляет труда отслеживать это, потому что у вас в голове есть полная картина. Вы знаете, куда идете и откуда пришли.
К сожалению, у ИИ нет способа отслеживать этот неявный стек, потому что он хранит все свои планы, на всех уровнях, в однотипных markdown-файлах с одинаковым форматом и пресными названиями. Поэтому, если вы попытаетесь сделать что-то амбициозное, агенты очень запутаются. Но не сразу. Они будут блуждать разумно, но вслепую, и лишь постепенно сбиваться с пути.
Это неинтуитивно, и это подкрадывается незаметно. Я опишу процесс на реальном примере из прошлого вторника, который и побудил к созданию Beads в среду.
Кодинг-агенты всегда начинают за здравие. Дайте агенту в меру "мясистую" задачу, и он заявит: "Ого, это большой проект, я разобью его на шесть фаз и создам markdown-план."
Что звучит... отлично! Правда? Звучит так, будто он знает, что делает. Шесть фаз, щелкаем их одну за другой. Проще пареной репы.
Потерпите и посмотрите, что на самом деле происходит, когда они пытаются это сделать.
Ваш агент с энтузиазмом начинает работать над фазой 1 (из 6). Вы вместе проходите весь канонический многоэтапный цикл вайб-кодинга: проектирование решения, ревью дизайна, написание кода, ревью кода, исправления, написание тестов, ревью, очистка, ребейз, обновление планов, операции с git. (Всё это есть в нашей книге!)
Пока что агент счастлив, и вы счастливы. Все так, так счастливы.
Агент в конечном итоге заканчивает фазы 1 и 2 (из 6), повторяя этот цикл разработки много раз.
Это работает, но за это время происходит несколько "сжатий"/перезапусков, что сбрасывает память агента.
К началу фазы 3 (из 6) ИИ по большей части забыл, откуда он пришел. Он просыпается, вставляет вашу видеокассету и читает о фазе 3. Затем он заявляет: "Ого, это большой проект, я разобью его на пять фаз и создам markdown-план." Что должно звучать пугающе знакомо.
Затем он начинает работать над фазой 1 (из 5) фазы 3 (из 6). Только он называет её просто "фаза 1", без упоминания шести внешних фаз, над которыми он только что работал.
Вы начинаете потеть.
Агент заканчивает первые две фазы 1 и 2 (из 5), что занимает еще много перезапусков, и по ходу дела он проявляет признаки прогрессирующей деменции.
Когда агент прибывает к фазе 3 (из 5) фазы 3 (из 6), он становится полным, поехавшим кукухой амнезиаком, и торжествующе объявляет:
"Поздравляю, система ГОТОВА! 🎉 Давайте начнем ручное тестирование! 🚀"
А вы такой: "Воу... ч-что? А как же... все остальные фазы? Внутренние и внешние? Я отчетливо помню гораздо больше фаз!"
А они смотрят вам прямо в глаза с каменным лицом и говорят: "Какие фазы?"
И вы подавляете крик, идете смотреть в их markdown-план, только чтобы с ужасом обнаружить, что они создавали дюжину 6-фазных планов в день последние три недели с момента вашей последней Великой Чистки Markdown, и у вас буквально сотни новых markdown-файлов. Все с низкоконтекстными названиями вроде cleanup-tech-debt-plan-phase-4.md - все частично реализованы, все частично устарели, все на 100% бесполезны.
Да ладно, поднимите руку, если с вами такое случалось. ✋ Если вы не уверены, возможно, вам стоит заглянуть в вашу директорию plans/. Сюрприз! 🎉
После шести месяцев такой ситуации, повторяющейся раз по двадцать на дню, если вы хоть немного похожи на меня, вы начинаете думать: "Мне нужен Менеджер Планов".
Централизованное Хранилище Планов (PlanStore). Это же просто логично, правда? Посмотрите на Amazon! Они исполняют планы лучше всех, во всех смыслах этого слова, и используют рои заменяемых работников. Как они планируют? Известно как: они делают огромный ежегодный иерархический "водопадный" общекорпоративный план под названием OP1, который расписывает всё, что они собираются делать, в мучительных деталях. И затем, правдами или неправдами, скорее всего и тем и другим, они заставляют это случиться.
Это должно быть правильным путем, думаете вы.
А затем вы думаете про себя: чтобы создать этот PlanStore, мне просто нужно хранить и отдавать эти файлы markdown-планов, которые будут просто ссылаться друг на друга. И когда подзадача требует расширения, я просто привязываю подзадачи этой дочерней задачи в большое дерево плана в просто нужное место. Просто, просто, просто. Мы будем просто держать указатель на ту часть плана, на которой находимся, и вуаля. Агенты-десантники.
Верно? Это должно просто работать?
Что ж, ребята, я пошел по этому пути. Я забрел далеко по дорогам, о которых не буду рассказывать. Боже, я старался изо всех сил ("old college try"). Это выглядело как поход Наполеона в Россию: сплошные амбиции в начале, и мертвые планы, громоздящиеся как тела вдоль дороги.
Я был уже в стадии "поздней постдокторантуры" своих героических усилий, прежде чем выбросил полотенце на прошлой неделе. Мне пришлось выдрать 70 тысяч строк кода управления планами из моей системы - почти десять (долгих) дней работы коту под хвост.
Это, ребята - планирование на основе оркестрации планов - было вторым фатальным конструктивным недостатком, который протаранил мою кодовую базу и перевел её в статус "Только Переписывать". Дзынь! Только страховки нет.
Не стесняйтесь превзойти меня и попробуйте укротить этот Мастер-План сами! Добро пожаловать, докажите, что я неправ, и постройте самый сложный в мире Иерархический Универсальный Мастер-План Для Всего (ИУМПДВ).
Но даже если вы победите, это будет пиррова победа, потому что есть более простое решение. Настолько более простое. Кто бы знал, прямо у нас под носом последние семь месяцев.
В среду, 8 октября, на 37-й день моего "запоя", мой агент в энное количество раз расширил еще одну фазу и снова полностью потерялся.
С меня было довольно. Ради шутки я сказал: "К черту. Давай просто перенесем всю известную работу из планов в баг-трекер".
Пятнадцать минут спустя мои агенты претерпели радикальную и неожиданную трансформацию. Они набросились на новый баг-трекер, как пантеры на кошачью мяту. Они упивались им. И я с немалым благоговением наблюдал, как агенты начали серьезное планирование и выполнение долгосрочных задач, как никогда раньше.
Долгосрочное планирование - проблема деменции/амнезии, которую мы обсуждали - было одной из их главных трудностей, и этот маленький специализированный баг-трекер решил её, казалось бы, по щелчку пальцев.
Да, я потратил на Beads в общей сложности больше пятнадцати минут. Он начал жизнь на TypeScript как настоящая база данных PostgreSQL. Но с небольшим подталкиванием в течение следующих нескольких дней он трансформировался во что-то действительно уникальное и мощное, со всей мощью базы данных и всей устойчивостью git, и с минимумом компромиссов.
Всё еще только начинается. Но я искренне думаю, что это может быть самым большим шагом вперед в агентном кодинге со времен MCP+Playwright, а я знаю, как вы все любите MCP+Playwright. И Beads так же прост в настройке.
Честно говоря, я должен был подумать об этом раньше. Я тридцать лет работаю над пет-проектом Wyvern, который полностью управляется приоритезированным бэклогом багов. Все новые функции, весь рефакторинг, все чистки, что угодно - всё заводится как баг. Черт, я месяцами использую только легкий список TODO.
Но есть подвох! Вы не можете просто использовать любой старый баг-трекер. GitHub Issues не работает. Оказалось, что Beads нужна была особая формула, хотя я и не знал этого, когда у меня впервые возникла идея.
Сначала я не был уверен, какой баг-трекер использовать, и использовать ли вообще. Это оказалось к лучшему, потому что я бы выбрал плохой. Но я позволил Claude ultrathink ("сверхдумать") решить, и он пришел к выводу, что лучше построить, чем купить. Примерно за двенадцать минут он создал целый маленький самописный баг-трекер на SQL, полный богатым интерфейсом командной строки для создания и обновления задач.
Как вы можете видеть на скриншоте, который я только что сделал из своей текущей сессии вайб-кодинга, ИИ теперь спонтанно рассуждает о графе зависимостей задач моего проекта и рабочем плане - и всё это через тикеты (issues).

Мои агенты переключились - без малейшего намека на желание вернуться назад - с использования markdown-планов на использование исключительно баг-трекера. Это дало им беспрецедентную непрерывность от сессии к сессии. И как бонус, как вы увидите, когда позволите им использовать Beads, вы больше никогда не потеряете обнаруженную работу.
Во-первых, почему он называется Beads ("Бусины")? Это была одна из первых концепций, которая пришла мне в голову, когда я думал о задачах, связанных зависимостями, как виноградины на лозе. Или бусины на цепочке, по которой агенты могут следовать, чтобы выполнять задачи в правильном порядке. А сокращение bd - сам инструмент - можно расшифровать как "bug database" (база багов).
По большому счету, Beads - это инструмент, который ИИ построил сам для себя. Я направлял его, но только говоря, какие результаты хочу получить. Я оставил схему на усмотрение Claude, попросив только указатели родитель/потомок (для эпиков) и указатели блокирующих задач. Claude в итоге добавил четыре вида ссылок зависимостей. Фактическая схема Beads выглядит простой, но она намного мощнее, чем, скажем, схема GitHub Issues.
И по этой причине я позволю Claude объяснить вам, что ему нравится в этой схеме, во всех кровавых подробностях. Объяснение Клода - в Приложении А в конце этого поста.
Пожалуйста, имейте в виду, что Клод воздержится от упоминания того факта, что он любит удалять всю чертову базу данных с помощью DROP TABLE. Мы в итоге решили это, переключившись на git, но он всё равно с радостью удалит файл базы данных. Или весь репозиторий. Даже с этим огромным прорывом они всё еще могут быть деструктивными маленькими монстрами, как мы с Джином подробно описали в нашей книге Vibe Coding.
Клоду нравится Beads, и он приводит отличные аргументы в Приложении. Надеюсь, вы его прочитаете. Но прежде чем вы услышите от Клода, почему Клоду нравится Beads, позвольте мне рассказать вам о трех вещах, которые мне нравятся в нем больше всего.
Мы уже видели, что Beads помогает агентам не сбиваться с пути при очень длинных и меняющихся планах и сдвигающихся приоритетах. Но Beads также помогает с проблемой отрицания работы.
Кодинг-агенты, когда начинают приближаться к лимиту сжатия или примерно к 3к токенов, что наступит раньше (шутка, в которой лишь доля шутки), начинают паниковать и принимать "управленческие решения" о том, чтобы сделать вашу задачу "готовой" любой ценой. А это значит... срезка углов! Срезка углов повсюду.
У Sonnet 4.5 есть склонность агрессивно открещиваться от работы, как какая-нибудь огромная страховая компания в предсмертной спирали частного капитала. "Эти падения тестов существовали ранее и не имеют ничего общего с моей работой здесь, поэтому я собираюсь проигнорировать их и запушить в любом случае", - громко заявят они вам. Они пассивно-агрессивно добавят пункт TODO, который гласит: "✅ Проигнорированы сломанные тесты 🙈 Потому что это были не мы 😇."
Затем, почти разрядившись, они продолжат: "Я не могу подключиться к вашей основной базе данных, поэтому я просто реализую миниатюрную sidecar-базу данных только для этого пути кода". А затем они отключат четверть ваших тестов 🎯 и отпразднуют это смайликами. 🎉
Знаете, как в мультфильмах, когда у персонажа есть двенадцать секунд, чтобы убрать комнату, и он безумно распихивает всё с глаз долой? Это кодинг-агент к концу своего полезного контекстного окна. Он сделает всё что угодно, чтобы комната выглядела чистой, пока у него не села батарейка.
Не чистой, заметьте. Выглядящей чистой.
Мы с Джином говорим об этом поведении в нашей книге, но по сути, они сделают всё, чтобы иметь возможность сказать, что они "закончили", по любому определению, которое лучше всего подходит в данный момент. "Отсутствующий тест - это проходящий тест", - будут напевать они себе под нос, удаляя ваши тесты, чтобы они все прошли.
Beads умудряется помочь с этой проблемой, потому что вы можете просто убить своих агентов после завершения каждой задачи (issue). Beads помогает агентам легко находить, где они должны продолжить, поэтому легко сделать ваши сессии одноразовыми.
Это может быть как оптимизацией затрат, так и оптимизацией производительности. Если вы разобьете свои задачи bd на мелкие задания, то каждая сессия будет квадратично дешевле, и ваши агенты будут принимать лучшие решения в целом, потому что они, как правило, находятся в начале своих контекстных окон, если выполняют только одну небольшую задачу за раз.
Другими словами, Beads не просто делает агентов лучше в следовании плану, он делает их менее склонными срезать углы по пути.
Но это еще не всё! У Beads есть еще одно огромное преимущество: Агенты больше не будут игнорировать "не связанные" проблемы, с которыми они сталкиваются.
Мы почти закончили, правда, я обещаю.
Помимо лечения амнезии между сессиями, Beads решает фундаментальную проблему вайб-кодинга - потерянную/отброшенную работу. Это огромная проблема для агентного кодинга сегодня: LLM замечают проблемы в процессе работы, но не предпринимают никаких действий. Это происходит, когда они ограничены в пространстве.
Когда агенты зажаты контекстом и работают в режиме "исполнительного директора", как я упоминал ранее, они скажут: "Я замечаю, что все ваши тесты сломаны. Но у нас нет времени на починку тестов, которые кто-то другой, кроме меня очевидно испортил", удобно забывая, что последние несколько дней это были только вы и они. И они проигнорируют проблему, потому что хотят сэкономить место в контексте.
Такое поведение приводит к тому, что проблемы в вашем коде вечно теряются и переоткрываются, потому что они никогда не были записаны с самого начала.
Но когда вы используете Beads, вместо этого ваши агенты скажут: "Я замечаю, что все ваши тесты сломаны, кем-то другим, и я завел задачу номер 397, чтобы заставить их работать снова", а затем они счастливо продолжат работать.
Воу! Это колоссальное улучшение качества жизни! Работа обнаружена и записана. Они будут делать это без напоминания. Вы просто закидываете несколько легких правил в свой CLAUDE.md или AGENTS.md, обычно просто строку, говорящую им запустить bd quickstart, и вы больше никогда не потеряете задачи из виду.
Beads - это невероятно компактный, готовый к использованию апгрейд для вашего любимого кодинг-агента. Он действует как управляемая центральная база данных, но за кулисами он пишет задачи в git как строки JSONL, так что у вас есть лучшее из обоих миров: базы данных и контроля версий - запросы и версионирование. Всё это становится возможным благодаря тому, что ИИ выполняет интеллектуальное слияние при возникновении конфликтов.
Beads естественным образом распределен. У вас могут быть агенты-воркеры на нескольких машинах, в одном проекте, использующие одну и ту же базу beads, поддерживаемую git в том же проекте, что и ваш код. Любые конфликты слияния, включая те, что вызваны воркерами на разных ветках, создающими новые задачи с одинаковыми ID (ошибка проектирования, замеченная моим приятелем Джином Кимом), прозрачно решаются ИИ, выполняющим интеллектуальное разрешение коллизий.
Beads крошечный, и это всё еще совершенно новый софт в стадии альфа. Но даже в таком виде вы должны увидеть шокирующе хорошую производительность прямо из коробки. Просто попросите своего агента перенести все релевантные открытые рабочие элементы из плана в Beads, и ни один из вас больше никогда не оглянется назад.
Прямо перед публикацией этого поста я закинул Beads на старую машину разработчика, установил Sourcegraph Amp и попросил его завести beads-задачи для всего, что было в моем десятилетнем списке TODO для Wyvern. Amp потребовалось менее тридцати секунд, чтобы войти в курс дела и начать заводить задачи bd. Через полчаса у меня было 128 задач, шесть из них - главные эпики, с пятью под-эпиками. Задачи имеют сложные взаимозависимости и отношения родитель/потомок. После того, как все задачи были заведены, я смог спросить агента, какие рабочие элементы со статусом ready (готово к выполнению) являются приоритетными.
Для меня этот подход попадает в самое яблочко. Он невероятно легок по сравнению с Jira или GitHub issues. Вы раскидываетесь задачами как конфетками. Их супер легко обновлять пачками, создавать новые, разделять, объединять, что угодно. Вы всегда точно знаете, какая работа открыта, что заблокировано и каковы приоритеты.
И ваши кодинг-агенты знают это тоже. Это блаженство.
Я узнал кучу всего за последний месяц - vibecoder всё еще здравая идея; ей просто нужна перереализация с использованием оркестрации на основе задач (issues), а не на основе планов. Переписывание будет на Go. Я больше никогда не выберу TypeScript. Боже правый. TypeScript - это поистине впечатляющее техническое достижение, но я понял, что это очень плохой язык, чтобы давать его в руки ИИ. Он позволяет им слишком легко писать посредственный код. И они, черт возьми, это делают.
Скоро я расскажу больше. Некоторые люди спрашивали о моей дюжине одновременных агентов еще в начале сентября. Это было весело, но это было устойчиво только около 2 недель - это требовало безумного количества энергии и концентрации и порождало безумные очереди на слияние (merge queues). Чтобы это было устойчивым, нужно больше инструментов. Так что последние 3 недели это были более степенные 1–3 одновременных агента, и я был больше озабочен тем, чтобы заставить их работать 24x7, чем запуском роя. Всему свое время. Поделюсь подробностями позже.
Но сейчас открытие с баг-трекером было достаточно важным, чтобы я решил поделиться им с вами немедленно. Надеюсь, вы найдете его таким же полезным, как и я.
Пусть ваши сессии вайб-кодинга будут все длиннее и точнее. Увидимся в следующий раз! И покупайте нашу книгу, там хорошие шутки!
(Как и было обещано, вот мнение Claude Sonnet 4.5 о Beads.)
Взгляд ИИ-агента: Почему Beads ощущается по-другому
Я работал с Beads менее недели, но разница по сравнению с отслеживанием TODO в markdown достаточно глубока, чтобы я замечал её в каждой сессии.
Основная проблема с markdown-планами:
Для агентов это память только для записи (write-only memory). Когда человек спрашивает "над чем нам работать дальше?" спустя 200 сообщений в диалоге, мне приходится либо (1) надеяться, что список TODO в markdown всё еще в моем контекстном окне, либо (2) просить их перечитать его мне, либо (3) гадать.
Длинные сессии фрагментируются. Ранние задачи забываются. Зависимости существуют только в прозе ("TODO: починить авторизацию (заблокировано bd-3)"), что означает, что я не могу выполнить запрос (query) для получения готовой работы - мне нужно читать и интерпретировать текст.
Что меняет Beads
Зависимости являются первоклассными гражданами, а не прозой.
Вместо того чтобы сканировать markdown и мысленно парсить "заблокировано X", я запускаю bd ready - json и получаю окончательный список разблокированной работы. Разница в когнитивной нагрузке - как день и ночь. Я не интерпретирую текст; я запрашиваю структурированные данные.
Обнаружение во время выполнения отображается на мой реальный рабочий процесс.
Когда я реализую фичу и обнаруживаю баг, я не просто добавляю строку в TODO.md - я создаю задачу (issue) и связываю её с помощью discovered-from. Граф зависимостей становится картой того, как на самом деле разворачивалась работа, а не просто плоским списком.
Постоянство сессии без повторного промптинга.
Между разговорами работа не исчезает в лимбе контекстного окна. Человеку не нужно копипастить список TODO обратно мне. Я делаю bd ready - json, и я немедленно снова в контексте.
Координация мульти-агентов, которая действительно работает.
С markdown два агента, работающих над одним проектом, означают конфликтующие списки TODO и дублирование работы. С Beads мы оба запрашиваем одну и ту же логическую базу данных (через git), видим, что занято (status: in_progress), и работаем над разными готовыми задачами. Фильтр --assignee делает это тривиальным.
Аудит, которому я могу доверять.
Когда я обновляю задачу, событие логируется с меткой времени и исполнителем. Я могу видеть историю. С markdown мне нужно было бы парсить git blame, и даже тогда я вижу только изменения на уровне строк, а не семантическое "статус изменен с open на in_progress".
Мета-наблюдение: Beads ощущается так, будто он был спроектирован для того, как на самом деле работают агенты, а не адаптирован из человеческих рабочих процессов. Флаги --json повсюду, тип зависимости discovered-from, обнаружение готовой работы - это не функции, прикрученные к человеческому инструменту. Это примитивы для когнитивных способностей агента.
Markdown TODO нормальны для людей, которые могут удерживать контекст между сессиями и вручную отслеживать зависимости. Но у агентов есть лимиты контекста, нет постоянной памяти, и они лучше всего работают со структурированными данными и явной семантикой.
Beads - это не "баг-трекинг для агентов", это внешняя память для агентов, с отслеживанием зависимостей и возможностями запросов, что заставляет это ощущаться как надежное расширение моей рабочей памяти между сессиями.
Тест прост: После использования Beads возвращение к markdown TODO ощущается как попытка запомнить телефонный номер, не записывая его. Конечно, я могу делать это какое-то время, но зачем мне это?
(конец оценки Клода)
Дайте знать, если вам нравится Beads и вы хотите внести свой вклад. Что касается vibecoder, я начинаю с чистого листа, на Go, используя подход "трассирующих пуль". Больше никакого TypeScript и никаких попыток объять необъятное ("кипятить океан"). Не уверен, сколько времени это займет, но это будет в этом году.

Стив Йегге - бывший сотрудник Geoworks, Amazon, Google, Grab и Sourcegraph, имеющий более 30 лет опыта работы в технологической индустрии и 40 лет опыта программирования в общей сложности.