Керувати фоновими воркерами

Цей посібник показує, як вести розмову в ролі директора, а не воркера: сесія читає й перевіряє, а редагуванням займаються фонові агенти.

Що змінюється, коли ви вводите /vibe

Дві речі, і лише першу примусово забезпечує механізм:

1. Власні інструменти сесії опускаються до рівня лише для читання, плюс п’ять дієслів воркера. Єдиний спосіб вплинути на репозиторій — через воркера, а єдиний спосіб дізнатися, що сталося, — прочитати файли, яких торкнувся воркер.
2. Їй наказано перевіряти читанням, а не вірою. Звіт воркера — це заява про те, що він зробив, а не доказ, що це спрацювало.

Навантаження несе перший пункт. Директор, який усе ще може виконувати grep і редагувати, під тиском зробить роботу сам — а це саме той режим відмови, якому цей підхід покликаний запобігти.

/vibe migrate the auth module to the new session API

Воркери стартують з нуля

Воркер ніколи не бачив вашої розмови й ніколи не побачить. Бриф — це весь його контекст.

Саме це робить цей підхід дешевим — двадцять воркерів, кожен із яких тримав би історію директора, коштували б у двадцять разів більше за контекст директора — і водночас це єдине, що робить брифи складними для написання. «Тепер зроби й інше» для директора читається як повна інструкція, а для свіжої сесії — як ніщо.

Добрий бриф називає файли, команди й визначення готовності:

У lib/features/auth/ замініть кожен виклик SessionStore.read(key) на SessionStore.get(key). Новий метод повертає Future<String?> там, де старий повертав String?, тож викликам потрібен await. Коли завершите, запустіть fvm flutter analyze lib/features/auth і повідомте про будь-які помилки, які не змогли виправити.

П’ять дієслів

Дієслово	Що робить
vibe_spawn	Запускає воркера з брифом. Повертає керування негайно.
vibe_list	Рівень, статус, витрачений час і останній результат для всіх
vibe_send	Наступний хід для воркера, який завершив роботу
vibe_wait	Блокує, доки один воркер не завершиться
vibe_kill	Зупиняє одного

Запуск асинхронний за задумом. Директор, який блокується на кожному запуску, виконує воркерів по одному — а це повільніший спосіб робити те, що він і так робив сам. Використовуйте vibe_wait лише тоді, коли справді не можете рухатися далі без конкретної відповіді.

Два рівні

Рівень	Для чого
fast	Механічна робота з чіткою специфікацією — правки, перейменування, чернетки, запуск команд
good	Проєктування, судження або перевірка того, що створив воркер fast

Поширений підхід — розподілити fast-воркерів між незалежними файлами, а потім запустити одного good-воркера, щоб перевірити те, що вони зробили разом.

Перевірка

Саме від цієї частини залежить, чи вартий цей підхід хоч чогось.

vibe_list
→ w1 [fast] auth-migrate — done (48s): Edited lib/features/auth/session.dart …
  w2 [fast] tests — running (12s)

Потім прочитайте файли, які він назвав. Директор має read, search, lsp і ast_grep; саме в цьому сенс того, що їх залишили. Директор, який приймає звіт на віру, — це переказувач оптимізму інших агентів.

lsp(action: "diagnostics", file: "*") після кола воркерів зазвичай є найшвидшою окремою перевіркою.

Коли воркер втрачає нить

Зупиніть його й напишіть бриф заново. Свіжий, виправлений бриф дешевший за суперечку, а vibe_send працює лише з воркером, який уже завершив свій хід.

vibe_kill(worker_id: "w2")
vibe_spawn(brief: "…corrected…", label: "tests", tier: "fast")

Обмеження

• Вісім одночасних воркерів. Стеля витрат, а не технічна межа: кожен із них — повноцінна сесія моделі, а директор, який розподілив двадцятьох, уже перестав стежити за тим, що всі вони роблять.
• Жоден воркер не переживає режим. Коли запуск завершується, їх усіх зупиняють, а транскрипт показує, скільки їх було. Фоновий агент, який досі редагує файли після того, як розмова пішла далі, — це єдина відмова, якої тут не можна допустити.
• Під капотом воркери — звичайні субагенти. Те саме обмеження глибини, та сама політика обмежень, той самий дочірній запис журналу запусків. Vibe змінює те, хто ними керує, а не те, що їм дозволено, — тож запити на схвалення, як і раніше, з’являються для викликів write і exec воркера.

Коли не варто його використовувати

Режим vibe призначений для роботи, яка розкладається на незалежні брифи. Якщо наступний крок залежить від результату попереднього, ви описуєте конвеєр або оркестрацію, і обидва належно виражають залежності, замість того щоб змушувати директора імітувати їх за допомогою vibe_wait.

Пов’язане

• Запускати агентів паралельно — інші способи розподіляти роботу між агентами
• Оркестрація — коли робота має форму
• Вбудовані інструменти агента — дієслова та їхні аргументи