Как делегировать задачи AI-воркерам и не потерять контроль

Когда впервые садишься разбираться, как делегировать задачи AI, срабатывает один из двух рефлексов. Либо «сейчас накидаю пару фраз, и оно само всё сделает» — и через час разгребаешь кашу, которую проще было написать руками. Либо наоборот: расписываешь ТЗ на две страницы, а потом думаешь — да я бы за это время сам закодил. Оба перекоса лечатся одним и тем же: пониманием, что воркер — это не волшебная кнопка и не джун, которого водят за руку. Это что-то посередине, и работать с ним нужно по своим правилам.

Разберу по-честному: что такое AI-воркер, как выглядит задача, которую он тянет, а какую завалит, где проходит граница между «отдать» и «оставить себе», и главное — как не превратить делегирование в потерю контроля над собственным проектом. Без магии и без «нейросети заменят программистов». Просто рабочая механика.

Что вообще такое AI-воркер

Воркер — это не чат, в котором ты переписываешься. Это агент, которому ты выдаёшь задачу целиком, а он сам её ведёт: читает нужные файлы в репозитории, планирует шаги, пишет код, запускает проверки, правит ошибки и приносит результат — обычно в виде коммита или готовой ветки. Ты не сидишь над ним в диалоге по реплике за раз. Ты ставишь задачу и уходишь пить кофе.

Разница с обычным чат-ассистентом принципиальная. Чат отвечает на конкретный вопрос здесь и сейчас — результат из его ответов ты склеиваешь сам. Воркер держит цель в голове от начала до конца и склеивает сам. Это ближе к тому, как ты делегировал бы кусок работы живому человеку: не «подскажи синтаксис», а «сделай, чтобы работала форма логина».

Из этого растёт главная особенность. Воркер силён ровно настолько, насколько понятна и замкнута задача. Живому подрядчику можно бросить «ну там разберись по ходу» — он до-думает, спросит, догадается по контексту команды. Воркер тоже до-думывает, но его догадки опираются только на то, что он видит в репозитории и в тексте задачи. Всё, что ты держал «в голове» и не написал, для него не существует.

Хорошая задача против плохой

Ключевой навык делегирования — не «правильно попросить», а правильно нарезать. Большая расплывчатая цель разбивается на куски, каждый из которых можно проверить по факту: сделано или нет. Вот как это выглядит на практике.

Правая колонка — не «воркер тупой». Это задачи, где нужно либо принять решение, которое за тебя никто не примет, либо держать в голове контекст, которого нет в коде. Их не делегируют — их сначала доводят до состояния из левой колонки, а потом отдают.

Хорошая задача звучит так, что по ней сразу ясен критерий приёмки:

• «Свёрстай карточку тарифа по макету, данные — из существующего типа Plan.»
• «Напиши миграцию: добавь колонку archived_at в таблицу tasks, nullable.»
• «Почини баг: при пустом поиске страница падает — должна показывать «ничего не найдено».»
• «Покрой тестами функцию расчёта скидки, вот граничные случаи: …»

Плохая — та, где воркер вынужден угадывать твой замысел:

• «Сделай, чтобы приложение работало быстрее.» (Что именно медленное? Насколько быстрее — достаточно?)
• «Переделай дизайн, чтобы было современно.» (Современно — это как? Чей вкус эталон?)
• «Добавь оплату.» (Какой провайдер? Какие тарифы? Что при неудачном платеже?)

Заметь: плохие формулировки плохи не потому, что длинные или сложные. Они плохи потому, что не замкнуты — внутри сидит нерешённое продуктовое или архитектурное решение. Стоит его принять и выписать — и задача переезжает в левую колонку.

Что делегировать, а что оставить себе

Даже когда задача идеально нарезана, не всё стоит отдавать. Не потому что воркер не справится технически — а потому что цена ошибки в некоторых местах слишком высока, чтобы узнавать о ней из ревью постфактум.

Правая колонка — не «делай руками». Ты можешь и должен пользоваться воркером как усилителем: пусть напишет черновик миграции, набросает варианты. Но решение и финальную приёмку в этих зонах держишь на себе. Разница в том, кто нажимает кнопку «применить»: в левой колонке — воркер под пост-ревью, в правой — ты, глядя в каждую строку.

Отдельная тема — безопасность и всё, что касается денег и данных пользователей. Здесь даже правильно поставленную задачу стоит принимать особенно внимательно: воркер оптимизирует под «работает», а не под «не сломается злонамеренно». Про это отдельный большой разговор — что нужно знать про безопасность вайб-кодинга, не поленись прочитать до того, как отдашь воркеру что-то, где может утечь токен или пролиться чужие данные.

Канбан как пульт управления делегированием

Когда воркеров и задач становится больше одного, в голове это уже не удержать. Нужна доска. Канбан для работы с AI-воркерами — это не про красивые колонки, а про честный ответ на вопрос «что сейчас делает машина, а что жду от себя».

Смысл в том, что колонка перестаёт быть просто статусом и становится точкой контроля. Задача в «В работе» — воркер пишет код прямо сейчас. Задача в «На ревью» — он закончил, ждёт твоего взгляда. И именно эта колонка — твой рубеж: ничего не уезжает дальше, пока ты не посмотрел.

Типичный поток выглядит так:

• Бэклог — нарезанные задачи, ещё не отданные. Тут ты доводишь формулировки до «левой колонки».
• В работе — воркер взял задачу и ведёт её. Ты не трогаешь.
• На ревью — готово, лежит коммит или ветка. Твоя очередь смотреть.
• Готово — принял, смержил, поехали дальше.

Прелесть в том, что несколько независимых задач могут висеть «В работе» одновременно, а ты разбираешь «На ревью» в своём темпе. Ты не бутылочное горлышко на этапе написания кода — только на этапе приёмки. Как выстроить такую доску под соло-режим, я разбирал отдельно в канбане для одного — там про то, как не утонуть в собственных колонках, когда команда — это ты плюс несколько агентов.

Контроль через ревью, а не через микроменеджмент

Главный страх при делегировании звучит так: «отдам — и потеряю контроль над кодом». Разберём его прямо, потому что от ответа зависит, сработает у тебя эта схема или нет.

Контроль над проектом бывает двух видов. Первый — контроль над процессом: сидеть рядом, следить за каждым шагом, диктовать, какую функцию писать следующей. Второй — контроль над результатом: тебе всё равно, как именно воркер дошёл до цели, ты проверяешь, что пришло на выходе. С воркерами работает только второй. Пытаться контролировать процесс — значит выбросить всю выгоду делегирования и вернуться к ручному написанию, только медленнее.

Значит, вся власть — на этапе приёмки. И тут есть простой чек-лист, по которому смотришь каждый результат:

• Оно вообще работает? Запусти, ткни руками. Не верь на слово «готово».
• Оно делает то, что просили, а не то, что рядом? Воркер иногда решает соседнюю задачу лучше, чем поставленную.
• Что изменилось в диффе? Прочитай, что он тронул. Особенно — не залез ли в чужие файлы «заодно».
• Нет ли тихих спецэффектов? Удалённый код, «упрощённая» логика, закомментированные проверки.
• Тесты живы? Если были — прогони. Если не было — повод попросить их следующей задачей.

Звучит как много, но на понятной задаче это минуты. И ключевой момент: чем лучше ты нарезал задачу вначале, тем быстрее ревью в конце. Расплывчатая задача — долгая мучительная приёмка «а что ты вообще имел в виду». Замкнутая задача — взгляд, кивок, мерж.

Что делать, когда результат не тот

Не всегда приходит идеал. Нормальная реакция — не переделывать руками молча (так воркер ничему не научится на следующий раз) и не писать «всё не так, переделай» (он не поймёт, что именно). Работает конкретика: «форма отправляется, но не показывает ошибку при пустом email — добавь валидацию и сообщение». Это снова задача из левой колонки, просто маленькая. Итерация дешевле, чем перехват руками.

Про доверие и «а вдруг сгенерит ерунду»

Уровень доверия к воркеру не фиксированный — он растёт от задачи к задаче. С незнакомым куском кода или в новой для тебя области отдавай мелко и проверяй плотно. Там, где уже видел, что воркер справляется стабильно, — укрупняй куски и ослабляй хватку. Это как с новым сотрудником: сначала сверяешься часто, потом всё реже.

И честно про качество результата: оно сильно зависит от того, какая модель под капотом, и от того, насколько чисто у тебя в проекте. Умная модель на аккуратном репозитории с тестами тянет куда более крупные и мутные задачи, чем слабая на бардаке. Если чувствуешь, что воркер систематически не дотягивает, — это не всегда повод дробить задачи ещё мельче; иногда причина в выборе модели. Я разбирал, какую LLM выбрать под какие задачи — на сложной логике и большом контексте разница между моделями ощутимая.

Небольшая, но важная привычка: держи в проекте что-то вроде памятки для воркера — как у вас принято называть, где что лежит, каким стилем писать. Один раз описал — и каждая следующая задача уходит уже с этим контекстом, не приходится повторять одно и то же в каждой формулировке. Хороший проект «объясняет себя» новому исполнителю сам, будь то человек или агент.

Типичные грабли делегирования

Собрал то, на чём спотыкаются чаще всего — чтобы ты прошёл мимо.

• Задача-океан. «Сделай мне SaaS.» Воркер начнёт, но приведёт нечто неопределённое. Режь до кусков с проверяемым результатом.
• Немой контекст. Половина требований осталась у тебя в голове. Всё, что не в тексте задачи и не в коде, — не существует.
• Ревью «на доверии». «Написал готово — значит готово.» Нет. Запусти. Всегда запусти.
• Микроменеджмент. Вмешиваешься в процесс, диктуешь каждый шаг. Тогда проще было писать самому. Контролируй результат, не процесс.
• Отдал критичное без страховки. Миграция без бэкапа, деньги без ревью, доступы наугад. См. правую колонку выше и статью про безопасность.
• Нет отката. Всё через ветки и коммиты. Если результат не тот — откатил и переставил задачу, а не разгребаешь прод.

Коротко о главном

Делегирование задач AI — это навык не «попросить», а «нарезать и принять». Хорошая задача замкнута и проверяема; плохая прячет внутри нерешённое решение. Что отдавать, а что держать при себе, решает не сложность, а цена ошибки: рутину — воркеру, деньги-данные-архитектуру — под личный контроль. Канбан делает видимым, что сейчас в руках у машины, а что ждёт тебя. А контроль ты не теряешь, если держишь его там, где он реально работает, — на приёмке, а не над плечом. Начни с одной маленькой замкнутой задачи, доведи её до мержа — и дальше просто увеличивай куски по мере того, как растёт доверие.